You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To take one step back, part of this data shape depends on what should be provided by the sender, and if at all, what should be modified by the receiver.
As a general rule of thumb, it is better to let the receiver set the datetime to prevent misinformation altogether. If LORC commits to using CC0 license, then the sender doesn't need to provide that either. In the case that both are set, the server should probably override them. This information needs to be stated in the documentation so that senders are well-aware before sending.
As for the actor (the agent that's sending it), this could be left as a SHOULD instead of a MUST. It is nice to have this information, but I can't of anything malfunctioning if it is not set. Second of all, there is no way to verify the value without authenticating the sender or having them sign the notification.
Whatever the server decides to do (modify or not) is orthogonal in any case.
Perhaps there is no need to expect a set of statements that should be in the notification. The only ones would be the generic parts like:
@prefix oa: <http://www.w3.org/ns/oa#> .
<> a as:Announce .
Aside: <> a as:Announce is presumably required for all notifications. The remainder of the shape under <> will be case dependent. Eventually the base URL will be the notification URL.
In any case, since there is nothing significant here, better to punt the problem to specific data shapes. No need to add a layer of requirement here.
Leaving this issue open for awhile to get feedback.
Provenance level data eg actors, datetime, license, are good candidates.
The text was updated successfully, but these errors were encountered: