Proposal: server-protected metadata

[dmitrizagidulin]

(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:

• Storing the WebID of the user that created the resource. (This is especially crucial in the case of LDN notifications - determining who sent them.)
• Storing the ID of the app that created the resource
• Place to store various timestamps typically found on a file system (created, edited)
• Place to (optionally) store MIME types of the resource (for implementations with persistence backends, such as quad stores, who can't take advantage of storing the content type in the file extension.)
• Storing an (optional) access log (views/updates to a resource) - this should probably be its own topic.

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:

1. Specify a separate 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.
2. Return this server-only metadata as part of the regular (user-editable) .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.
3. Return the server-only metadata in (specified) HTTP headers. (Personally, I like this option the best, actually, since there isn't /that/ much server-only metadata, and it avoids a separate round-trip request.)

[acoburn]

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:

ldp:PreferContainment
ldp:PreferMembership
trellis:PreferServerManaged
trellis:PreferUserManaged
trellis:PreferAccessControl
trellis:PreferAudit

(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 headers:

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 acl:Control permission on the resource. It would be really important to consider the security implications of exposing a resource's audit log publicly.

[pmcb55]

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 .acl or .meta but a full blown IRI (allowing us more easily extend to more and more forms of meta-data). But we can also support @dmitrizagidulin's number 3) too (really just as an optimization to avoid 2 HTTP calls) by also returning certain properties as HTTP headers (i.e. the 'common' ones), which as @acoburn describes, Trellis does today.

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 .meta resource), as I think it's leads to .meta of .meta of .meta..., or trying to apply ACL's to .meta resources (which is the same thing I suppose). But perhaps there is real value I'm missing in it...

[kjetilk]

Just wanted to give my 👍 to the direction this is taking. There was some precedence in the serverSide.ttl that I introduced for quotas in NSS 4.4, but it really needs more careful elaboration.