Specification: Specify metadata mechanism for Containers, RDFResources, NonRDFResources

Created on 24 Sep 2019 · 3Comments · Source: solid/specification

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.
[x] (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: https://github.com/solid/solid-spec/issues/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 https://github.com/solid/specification/issues/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

Ecosystem DELETE resource life cycle

Source

dmitrizagidulin

👍2

Most helpful comment

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.