-
Notifications
You must be signed in to change notification settings - Fork 42
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
Proposal: server-protected metadata #65
Comments
I can give some background on how much of this is implemented in Trellis. First, rather than thinking of this in terms of server-managed vs. user-managed data, I partition the triples of a resource across multiple named graphs, including:
(this is easily extensible: for example, a shape constraint graph could be added here). At present, nearly all server-managed properties are exposed to the user as headers: LDP interaction model, last modified, etc. Standard HTTP headers and/or Link headers make this very easy. Internally, these server-managed properties are stored in different ways, but they are not accessible as a separate resource. Some of what is described in this issue as server managed properties is, in Trellis, considered part of an audit trail. For example: the agent with this IRI created the resource at this time, this other agent updated the resource at this point, etc. In the low-level semantics of the interfaces, the audit trail is append-only and immutable; a user cannot tamper with those properties. Each resource has its own audit log, and that audit log is retrievable via Prefer: return=representation; include="http://www.trellisldp.org/ns/trellis#PreferAudit" An example of what an audit log might look like is available in the Trellis Wiki. Also, the audit log is only available to agents with |
Yep, so I think we can bring all these ideas together very nicely, basically using @acoburn's approach of Named Graphs for the various 'types' of meta-data. So yes, we would use Link headers as in @dmitrizagidulin's number 1) above, but the rel isn't just I think this is super-elegant and definitely the general direction we should go, but I have a big niggly concern that eating up the Named Graph to explicitly represent 'resource associated meta-data' means a user can't easily store their own quads within their Pod (i.e. they can't associate their own chosen semantic to that context component). Somehow I just don't like option 2) (i.e. having all the meta-data clumped into a separate |
Just wanted to give my 👍 to the direction this is taking. There was some precedence in the |
(Originally from the discussion at solid/solid#130 (comment))
Parent issue: #102 - Specify approach for resource meta-data.
We need some facility for protected / server-only metadata (as opposed to user-editable metadata) for resources.
This would be useful for:
Some questions to discuss:
Where will this server-only metadata be stored? Although each implementation can decide on a backend-appropriate mechanism for this metadata, we do need to consider how this data gets exported (during account export/migration).
More importantly, how will this server-only metadata be retrieved? We have a few options:
Link:
rel header for server-only metadata (a third one, in addition to the ACL link rel and the.meta
link rel). The main downside to this is that this sort of metadata (ie who created the resource) is frequently needed by the client, but requires a separate HTTP call to retrieve it. So we're essentially forcing 2 GET calls for each resource..meta
resource. And have the server be in charge of keeping the server-only statements separate from the user-added statements, but return both sets of statements on a GET to the.meta
resource. This has the same downside as above (needing 2 separate HTTP calls for each resource), with the additional complexity of the server having to keep the two sets of metadata separate.The text was updated successfully, but these errors were encountered: