Proposal: server-protected metadata

(Originally from the discussion at https://github.com/solid/solid/issues/130#issuecomment-287849451)

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.)

Start by reading parent issue #102 and the linked issues #34, #63, and #66, then review the original discussion in solid/solid#130. The issue is done when the storage, export or migration, and retrieval mechanism for server-only metadata is decided and specified, including how it relates to user-editable metadata.