Define creator

[csarven]

The notion of "creator" of a resource has been in discussions and in being implemented for some time now e.g. https://github.com/solid/solid/issues/111 (in 2016), https://github.com/solid/specification/issues/66 , https://github.com/solid/specification/issues/197#issuecomment-699942808 , https://github.com/solid/specification/issues/265#issuecomment-874704696 ..

"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 https://github.com/solid/specification/issues/227 (search for "creator" or "authoritative resource metadata") and https://github.com/solid/specification/issues/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.)

[elf-pavlik]

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:creato 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.

👎 given the direction of resource-level access control I believe this only complicates things. We have HTTP/2 available as well as content types that can represent datasets and include more than one graph. AFAIK only container currently has the quirk of mixing server-managed and client-managed triples and it brings all kinds of problems with it.

[bblfish]

I agree there are some pretty important use cases for having this. One use case is an access control rule that would give Write ability to everyone who created a resource. That is being discussed here: https://github.com/solid/authorization-panel/discussions/261

[dmitrizagidulin]

+1 to using dcterms:creator, in the server-managed auxiliary resource.

[justinwb]

+1 to using dcterms:creator, in the server-managed auxiliary resource.

+1 to the same.

[elf-pavlik]

Given the conversation in https://github.com/solid/web-access-control-spec/issues/97, it would be good to hear from @RubenVerborgh if access policies relying on information in server-managed auxiliary resource impact architecture discussed there. I would expect not, since server-managed auxiliary resource seems similar to ACL (WAC) / ACR (ACP), and both could be available to the authorization layer.

[matthieubosquet]

+1 to a clear separation of server managed and non server managed triples. No strong opinion on Link headers vs auxiliary resource. +1 to consistency of mechanism for advertising owner and creator.