Repository navigation
Specify metadata mechanism for Containers, RDFResources, NonRDFResources #63
Description
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
describedBylink relation header, to point to the.metafile (if we're going to continue using that mechanism) - Specify semantics of
.metafor Containers. Current behavior/spec: a PATCH to anldp:Containerresults in the triples going straight to the container's.metaresource. A GET to a container transparently includes the triples from the.metaresource. - Clarify whether the presence of a
.metaresource in a Container counts towards that container being empty or non-empty (which affects DELETE semantics). Currently:.metais ignored / counts as empty. - (n/a - no globbing going forward)
If globbing still exists, clarify the semantics of.metawith respect to results of a glob operation. - Specify the semantics of
.metafor NonRDFResources. Currently,.metais 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
.metafor RDFResources. It is unclear whether RDF Resources are a) allowed to have their own.metaresources, 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/
.aclsemantics of.metaresources. Currently: Unclear, but I believe a.metaresource can have its own.meta.aclresource, but defaults to the same permissions as the resource that it describes? (See solid/#130 - ACL for .meta resources) - Clarify the lifecycle of the
.metaresource (similar to issue Clarify the lifecycle of an ACL resource #58). See also issuesolid-spec/#168- How to delete meta file? - Specify how
.metaresources get serialized/exported to the filesystem, with regards to File system data portability - Differentiate user-writeable metadata from Server-protected metadata
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
jeff-zucker commentedon Sep 24, 2019
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.
2 remaining items
kjetilk commentedon Dec 4, 2019
Document under current discussion:
https://github.com/solid/data-interoperability-panel/blob/resource-metadata/resource-metadata/hypothesis.md
kjetilk commentedon Dec 18, 2019
Now with PR: solid/data-interoperability-panel#32
phochste commentedon Oct 16, 2021
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
describedBycould clash with technologies such as FAIR Signposting that will point to another resource than the.meta.kjetilk commentedon Oct 18, 2021
Interesting! So, that's an argument for making it generally possible for these resources to have their own access control.
csarven commentedon Oct 18, 2021
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 commentedon Dec 2, 2021
In the specifications we (as PDS Interop) are discussing for our Solid Migrator project1 information regarding forwarding/redirecting URLs to other locations (based on user input) would be stored in metadata files.
We chose the
.metaapproach 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
.metafor RDFResources", I felt it prudent to mention our project here, as a real-world problem (and hopefully solution) related to this issue.1 See the accompanying post on the Solid forum.