Specify metadata mechanism for Containers, RDFResources, NonRDFResources

[dmitrizagidulin]

Parent issue: #102 - Specify approach for resource meta-data.

We currently have the (highly under-specified) .meta mechanism. As part of the 1.0 spec, we should:

• Re-confirm the use of describedBy link relation header, to point to the .meta file (if we're going to continue using that mechanism)
• Specify semantics of .meta for Containers. Current behavior/spec: a PATCH to an ldp:Container results in the triples going straight to the container's .meta resource. A GET to a container transparently includes the triples from the .meta resource.
• Clarify whether the presence of a .meta resource in a Container counts towards that container being empty or non-empty (which affects DELETE semantics). Currently: .meta is ignored / counts as empty.
• (n/a - no globbing going forward) If globbing still exists, clarify the semantics of .meta with respect to results of a glob operation.
• Specify the semantics of .meta for NonRDFResources. Currently, .meta is the recommended mechanism for adding metadata / RDF triples to arbitrary non-RDF resources. Original issue: How should we handle metadata of non-RDF sources (was Treatment of .meta files) solid-spec#197
• Specify the semantics of .meta for RDFResources. It is unclear whether RDF Resources are a) allowed to have their own .meta resources, or b) whether that's recommended behavior. There are some arguments that RDFResource are their own metadata (see also the approach taken by the Hydra community). But arguments can also be made to the contrary (especially when it comes to server-protected metadata, a separate topic.)
• Clarify the permission/.acl semantics of .meta resources. Currently: Unclear, but I believe a .meta resource can have its own .meta.acl resource, but defaults to the same permissions as the resource that it describes? (See solid/#130 - ACL for .meta resources)
• Clarify the lifecycle of the .meta resource (similar to issue Clarify the lifecycle of an ACL resource #58). See also issue solid-spec/#168 - How to delete meta file?
• Specify how .meta resources get serialized/exported to the filesystem, with regards to File system data portability
• Differentiate user-writeable metadata from Server-protected metadata

[jeff-zucker]

Ideally it would be possible to give access to a non-RDF resource but not it's metadata (e.g. private notation on a musical piece by its collaborators) or to the metadata but not the resource (e.g. users can see a catalog of the images and their properties but not the image). That level of control would require individual metadata files and would not be doable keeping the metadata solely in the container/.meta. OTOH container/.meta as it was in NSS is quite convenient and supports a very easy way to create media apps. I see the metadata issue as a critical piece that should be decided sooner rather than later because it is central to any sort of media-based app and we want to support people experimenting with those since it's a likely source of flashy apps that can attract users.

[kjetilk]

Document under current discussion:
https://github.com/solid/data-interoperability-panel/blob/resource-metadata/resource-metadata/hypothesis.md

[kjetilk]

Now with PR: solid/data-interoperability-panel#32

[phochste]

In academic libraries we have the inverse use-case where the metadata of a non-RDF resource might be public available, but the non-RDF resource itself can be protected. E.g. one is allowed to read the technical description of the non-RDF resources, but requires permission from the data owner to read the data.

The describedBy could clash with technologies such as FAIR Signposting that will point to another resource than the .meta.

[kjetilk]

Interesting! So, that's an argument for making it generally possible for these resources to have their own access control.

[csarven]

If we move in this direction:

Agent with Control on auxiliary resource can set/change its ACL resource.

When an auxiliary resource does not have its own ACL resource, agent with Control needs to have a way to set one. What's currently not specified in the Protocol is whether auxiliary resources should have their own Link rel=acl. Addressing that will open the possibility.

This allows the resource and its auxiliary resource to have different authorization rules.

So, then Description Resources and ACL Resources can have their own authorization rules. Enables different use cases. Noting that current WAC does not prohibit ACLs to have their own ACLs - it is being discussed as an update/extension - provided that server manages the association with resource and ACL resource.

[Potherca]

In the specifications we (as PDS Interop) are discussing for our Solid Migrator project¹ information regarding forwarding/redirecting URLs to other locations (based on user input) would be stored in metadata files.
We chose the .meta approach as we do not see any other mechanism in the Solid Specs that would allow doing this in both a portable, and user- (or app) and server-editable manner.

As this falls directly under "semantics of .meta for RDFResources", I felt it prudent to mention our project here, as a real-world problem (and hopefully solution) related to this issue.

¹ See the accompanying post on the Solid forum.