Description
The notion of "creator" of a resource has been in discussions and in being implemented for some time now e.g. solid/solid#111 (in 2016), #66 , #197 (comment) , #265 (comment) ..
"Creator" is an important piece of information, with plethora of use cases involving resource management, audit trails, notification of changes, provenance records, subject rights, privacy, authorization... that can be used by both servers and applications for different purposes.
Creators of resources have some sense of right to control the lifecycle of their own creations. It is similar to the current definition of storage "owner" in the Protocol:
An owner is a person or a social entity that is considered to have the rights and responsibilities of a data storage. An owner is identified by a URI, and implicitly has control over all data in a storage. An owner is first set at storage provisioning time and can be changed.
but in fact it is closer to the existing definition of "owner" in http://www.w3.org/ns/auth/acl#owner :
The person or other agent which owns this.
For example, the owner of a file in a filesystem.
There is a sense of right to control. Typically defaults to the agent who craeted
something but can be changed.
with the exception of not being changeable. (The current solid:owner was informed by acl:owner).
The creator (as per authenticated agent or possibly a group) of a resource needs to persist somehow/where.
Looking at #227 (search for "creator" or "authoritative resource metadata") and #177 , it is acknowledged to be a data point that should be available in the Protocol and most likely made available through a server-managed resource, i.e., server reads and writes to it, and it is read-only by agents/clients that are properly authorized. The creator goes well together with other "information such as last modification, size, resource type etc." that's server managed.
Alternatively, for RDF documents, the information can be part of the resource, and any attempt to updating it can be rejected - similar to attempts to directly updating containment statements. For example, LDP also mentions dcterms:creator as a server-managed property e.g., in https://www.w3.org/TR/ldp/#ldpr-put-replaceall . That has the advantage of following best practice on self-describing documents.
To make it uniformly available for all resources, there are two options:
- HTTP Link header (with creator link relation type)
- Auxiliary resource (including authoritative resource metadata)
(I'd say that the auxiliary resource is the way to go.. as that is going to solve a bunch of other issues in one go. On a related note, we may want to consider making owner information available from there as well.)