Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliding data and must-understand #3

Open
chrysn opened this issue Oct 11, 2021 · 2 comments
Open

Eliding data and must-understand #3

chrysn opened this issue Oct 11, 2021 · 2 comments

Comments

@chrysn
Copy link
Member

chrysn commented Oct 11, 2021

At some points we talk about eliding data -- be it when the RFC6690 conversion of #2 generously offers that terms that are not understood may be ignored, or during profiling, or when information is too hidden to be found by an application that can't go down the whole tree (because it has a depth limit). Also when we think about whether a CoRAL document can be processed in a streaming fashion, there is a hint that it should be possible to act on incomplete information.

As long as it's OK not see parts of the original statement, there can't be any must-understand fields. (Otherwise there'd be the "whoops, I didn't see that" excuse). We should add a statement somewhere on this -- but I have no clue where. (We don't have a "CoRAL patterns" section). Could be a bit like this:

CoRAL can be used to build both open world systems ("if something is not said, it may or may not be true") and closed world systems ("if something is not said, it is not true"). In constrained environments (and the web in general), partial representations are often used for efficiency, e.g. when a device queries another for particular statements (e.g. using a yet to be defined FETCH version of CoRAL). To support such cases, it is convenient to build applications on open world assumptions.

In practice, that means that there should not be any attributes that are mandatory to process; for example, a form that can only be submitted at some times should not be expressed like this:

[2, gr:feeding, null, [
    [2, coreapp:target, cri'/feed-gremlins'],
    [2, gr:deny-time, "after midnight"]
]

Instead, the presence of restrictions can be encoded in a component that is necessary for the application to use the form in the first place, and statements are added to relax the restrictions:

[2, gr:limited-feeding, null, [
    [2, coreapp:target, cri'/feed-gremlins'],
    [2, gr:allow-time, "before midnight"]
]

An application that understands "limited-feeding" term can be required to only submit this form if there is an "allow" property on the form which the application can understand and test for.

(On a personal note, at some point I'll need to write technical texts with examples that do without pop culture references, and that will be a very sad day).

@chrysn
Copy link
Member Author

chrysn commented Jan 19, 2022

It might also help to add that "some tools built on CoRAL are expected to make this a requirement"; for example, anything that acts on an LRU cache of information WOULD PROBABLY ask to be used only with open-world vocabularies.

Putting this as one item on todays' brief CoRAL agenda part to flush out any WG concerns before committing that to text.

@chrysn chrysn closed this as completed in cdd9bad Mar 7, 2022
@chrysn
Copy link
Member Author

chrysn commented Mar 11, 2022

The current text is not clear enough; might help to find existing guidance on open/closed world terminology -- or clarify otherwise.

@chrysn chrysn reopened this Mar 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant