Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In-progress draft of Resource metadata (FOR COLLABORATIVE EDITING) #32

Merged
merged 29 commits into from
Mar 22, 2020
Merged
Show file tree
Hide file tree
Changes from 15 commits
Commits
Show all changes
29 commits
Select commit Hold shift + click to select a range
c75cca6
initial commit of resource metadata hypothesis
justinwb Dec 4, 2019
edd6c70
added lifecycle
justinwb Dec 4, 2019
91f96d8
remove containment reference
justinwb Dec 4, 2019
74d04b8
adjust authz
justinwb Dec 4, 2019
d7debd2
update acl, shape, and resource description
justinwb Dec 31, 2019
1686364
grammer correction.
justinwb Jan 7, 2020
426fb06
link to w3 specs
justinwb Jan 7, 2020
1779004
add types and incorporate feedback
justinwb Jan 8, 2020
b740995
Update formatting
justinwb Jan 8, 2020
a311c5e
Grammar adjustments
justinwb Jan 9, 2020
885a8f8
server and client clarification
justinwb Jan 16, 2020
52673a3
move draft resources to readme
justinwb Jan 16, 2020
3b26f88
limit types to one metadata resource
justinwb Jan 16, 2020
9040ddb
Merge branch 'resource-metadata' of https://github.com/solid/data-int…
justinwb Jan 16, 2020
aeb0764
Apply suggestions from review
justinwb Jan 16, 2020
3a6e38c
use describes when linking back to annotated resource
justinwb Feb 28, 2020
9281253
Merge branch 'resource-metadata' of https://github.com/solid/data-int…
justinwb Feb 28, 2020
252dfce
incorporate csarven feedback - part1
justinwb Feb 28, 2020
c20dd84
add table with pointers to reserved types
justinwb Mar 16, 2020
2583e89
clarify metadata characteristics
justinwb Mar 16, 2020
b2a5593
clarify acl sanity check
justinwb Mar 16, 2020
c7ba28c
clarify metadata characteristics
justinwb Mar 16, 2020
49c8ef9
clarify server managed metadata
justinwb Mar 17, 2020
87453ac
clarify configuration and shape validation
justinwb Mar 17, 2020
ce3c263
clarify metadata extension
justinwb Mar 17, 2020
bc21ce9
add metadata lookup through rdf representation
justinwb Mar 20, 2020
8fc73e4
clarify acl deletion
justinwb Mar 20, 2020
fdf9ad1
clarify access modes needed for key operations
justinwb Mar 20, 2020
e3fdb92
clarify metadata resource association
justinwb Mar 20, 2020
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 54 additions & 0 deletions resource-metadata/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
# Resource Metadata in Solid

A project undertaken by the [Data Interoperability Panel](https://github.com/solid/data-interoperability-panel).

## Goal

The aim of this project is to produce a candidate proposal to the [Solid Specification](https://github.com/solid/specification) that defines a mechanism for how metadata (such as access control or shape constraints) is associated and accessed for a given resource.

# Draft Resources

This section and the content inside it is meant to aid those contributing to or reviewing the [draft proposal](hypothesis.md).

## Additional References

[Solid Content Representation Spec](https://github.com/solid/solid-spec/blob/master/content-representation.md) - This is the original component specification document (circa 2016) that defined a metadata discovery mechanism using Link headers.

Notable issues:
- [Specify approach for resource metadata](https://github.com/solid/specification/issues/102)
- [Specify metadata mechanism for Containers, RDFResources, NonRDFResources](https://github.com/solid/specification/issues/63)
- [Clarify the lifecycle of an ACL resource](https://github.com/solid/specification/issues/58)
- [Proposal: server-protected metadata](https://github.com/solid/specification/issues/65)
- [Methods for ACL resource creation](https://github.com/solid/specification/issues/42)
- [How does the server determine whether a resource is an ACL resource](https://github.com/solid/specification/issues/31)
- [Atomicity of creating a resource and its ACL](https://github.com/solid/specification/issues/131)
- [ACL for meta resources](https://github.com/solid/solid/issues/130)
- [How should we handle metadata of non-RDF sources](https://github.com/solid/solid-spec/issues/197)
- [How to delete metadata file?](https://github.com/solid/solid-spec/issues/168)
- [When a resource is deleted, should the acl be deleted too?](https://github.com/solid/solid/issues/251)
- [When deleting a resources, should the corresponding ACL document be deleted?](https://github.com/solid/solid-spec/issues/187)
- [Explain the ACL inheritance algorithm for clients](https://github.com/solid/specification/issues/106)

Items/themes that are raised in the issues above and should be addressed in some form:

- Reconfirm use of describedby as a way to get to meta information (#63)
- Specify that metadata should be handled as regular RDF resources - probably should put this in the opening section.
- Specify the semantics of meta information for containers (#63)
- Take a look at current NSS use of .meta for containers
- Clarify whether metadata for a container counts towards it being empty or not (#63)
- Specify semantics of meta for NonRDFResources (#63)
- Specify semantics of meta for RDFResources (#63)
- Clarify permissioning of .meta resources (#63)
- Can a client always read metadata?
- Can a client always know the metadata is there (e.g. link headers are advertised)
- What if the user wants to provide access to the file but not the file metadata?
- Clarify the lifecycle of .meta resources (#63, #58)
- [Consensus](https://github.com/solid/specification/issues/31) that deleting a resource must remove associated ACL resource
- Specify how .meta resources get serialized (#63)
- Differentiate user-writeable metadata from server-protected metadata (#63, #65)
- For a given piece of metadata, it is
- only readable and writeable by the server (e.g. internal indexing)
- readable by any client subject to permissions on resource, but only written by the server (e.g. timestamps)
- readable and writeable by any client subject to permissions on resource (i can set the shape constraint, or read/write the acl)
- Determine whether we should point out the actual ACL resource in use in a new link header (timbl suggestion, ruben created issue). Discussed in #31, proposed in #106
- Can you create an ACL resource in advance, or at the time of creation of the resource itself? (#131)
139 changes: 139 additions & 0 deletions resource-metadata/hypothesis.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,139 @@
# Resource Metadata Model

## Background
justinwb marked this conversation as resolved.
Show resolved Hide resolved

*This section is non-normative*

This document introduces a mechanism for linking to metadata about resources in the Solid Ecosystem using HTTP Link headers. Examples of this linking mechanism include:

- A binary JPEG image with a Link header, pointing to a description that has an RDF representation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have created dedicated issue for media resources and multiple encodings of same creative work #33 . Here I would like to clarify if we talk about description of each of those encodings or description of the creative work which can have numerous encodings?

Copy link
Member

@elf-pavlik elf-pavlik Dec 31, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we just talk about different representation of the same resource, I think we could simply use rel="alternate" together with type="image/jpeg" http://microformats.org/wiki/rel-alternate#With_type

When used in combination with the type attribute (with a value other than that of the document itself; e.g. other than "text/html"), rel="alternate" means a link to a representation of the contents of the current document in a different format, as designated by the type attribute.

If we talk about relating a creative work to multiple different encodings, each of which can have their own encoding specific rdf representation, i think should discuss it in #33

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you say that the proposed approach we describe here gives us the basic capabilities needed to make these associations (for example in the content of the resource description metadata resource)?

- An LDP container with a Link header, pointing to an ACL resource that governs access controls for the contained resources.
justinwb marked this conversation as resolved.
Show resolved Hide resolved
- A resource whose shape is constrained by a ShEx document includes a Link header that points to that ShEx resource.
- A resource may keep an audit trail of modification events. A client could follow the URI in a Link header to access that audit trail.

A given resource might link to zero or more such related metadata representations. Having a unified model to describe how clients and Solid servers interact with and process these resources will help clarify expectations, while also providing a shared pattern for extending the features of Solid server implementations.

The metadata model described in this document makes it possible for clients to decorate resources with structured descriptive data. Those metadata may serve as supplementary descriptions or, when supported by a Solid server implementation, they may influence the behavior of the resources.

Some examples include:

- An ACL resource controls how a Solid server makes authorization decisions for a container and any child resources.
- A shape constraint resource may limit the RDF structures that can be added to a resource or container.
- A “configuration” resource may control how a resource is versioned, or which indexes are exposed for it.

Access to different categories of metadata may require different levels of privilege, which must be specified as part of the definition for a given metadata type.

## Metadata Discovery
justinwb marked this conversation as resolved.
Show resolved Hide resolved
Given the URL of a resource, a client can discover the metadata resources by issuing a `GET` (or `HEAD`) request and inspecting the `Link` headers in the response. The [`rel={attribute}`](https://tools.ietf.org/html/rfc8288) will define the relationship to the target URL.
justinwb marked this conversation as resolved.
Show resolved Hide resolved

For any defined metadata type available for a given resource, all representations of that resource MUST include a Link header pointing to the location of each metadata resource. For example, as defined by the Solid [Web Access Control specification](https://github.com/solid/web-access-control-spec), a client can use this mechanism to discover the location of an ACL resource:

Link: <https://example.com/resource?acl>; rel="acl"
justinwb marked this conversation as resolved.
Show resolved Hide resolved

Metadata discovered through a Link header for a given resource is considered to be *directly associated* with that resource.

### Discovery of Annotated Resource
justinwb marked this conversation as resolved.
Show resolved Hide resolved

Certain metadata resource types MAY require the Solid server to include a link back to the annotated resource using an appropriate link relation. For example, LDP defines a bidirectional discovery mechanism for RDF descriptions of NonRDF resources, via Link headers:
justinwb marked this conversation as resolved.
Show resolved Hide resolved

Link: <https://example.com/binary?description>; rel="description"
justinwb marked this conversation as resolved.
Show resolved Hide resolved

along with:

Link: <https://example.com/binary>; rel="describedby"

For cases where link relations are not defined by IANA, a URL can be used. For example:
justinwb marked this conversation as resolved.
Show resolved Hide resolved

Link: <https://example.com/resource?meta>;
rel="https://example.org/ns#hasMetadata"

and:

Link: <https://example.com/resource>;
rel="https://example.org/ns#isMetadataOf"

String-based link relations, such as in the examples above, must be registered with IANA. But it is also possible to use custom relation types by using a full IRI. The [Linked Data Platform](https://www.w3.org/TR/ldp/), the [Linked Data Notifications](https://www.w3.org/TR/ldn/), and the [Web Annotation Protocol](http://www.w3.org/TR/annotation-protocol/) specifications make use of full IRIs in the `rel` attribute.

## Metadata Characteristics

A given resource MAY Link to metadata on a different server.
justinwb marked this conversation as resolved.
Show resolved Hide resolved

Metadata resources on the same Solid server MUST adhere to the same interaction model used by standard Solid resources.
justinwb marked this conversation as resolved.
Show resolved Hide resolved

## Reserved Metadata Types
justinwb marked this conversation as resolved.
Show resolved Hide resolved

### Web Access Control

ACL resources as defined by [Web Access Control](https://github.com/solid/web-access-control-spec) MUST be supported as a resource metadata type by Solid servers.

ACL metadata resources are discoverable by the client via ```rel=acl```.

A given Solid resource MUST NOT be directly associated with more than one ACL metadata resource.

An ACL metadata resource MUST be deleted by the Solid server when the resource it is directly associated with is deleted and the Solid server is authoritative for both resources.
justinwb marked this conversation as resolved.
Show resolved Hide resolved

To access or manage an ACL metadata resource, an [acl:agent](https://github.com/solid/web-access-control-spec#describing-agents) MUST have [acl:Control](https://github.com/solid/web-access-control-spec#aclcontrol) privileges per the [ACL inheritance algorithm](https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm) on the resource directly associated with it.
justinwb marked this conversation as resolved.
Show resolved Hide resolved

A Solid server SHOULD sanity check ACL metadata resources upon creation or update to restrict invalid changes.
justinwb marked this conversation as resolved.
Show resolved Hide resolved

### Resource Description

Resource description is a general mechanism to provide descriptive metadata for a given resource. It MUST be supported as a resource metadata type by Solid servers.

The Descriptive metadata resource for a given resource is discovered by the client via ```rel=describedby```. Conversely, the resource being described by a Descriptive metadata resource is discovered by the client via ```rel=http://www.w3.org/ns/solid/terms#resource```.
justinwb marked this conversation as resolved.
Show resolved Hide resolved

A given Solid resource MUST NOT be directly associated with more than one Descriptive metadata resource.

A Descriptive metadata resource MUST be deleted by the Solid server when the resource it is directly associated with is deleted and the Solid server is authoritative for both resources.

Access or management of a Descriptive metadata resource by a given [acl:agent](https://github.com/solid/web-access-control-spec#describing-agents) is subject to the [modes of access](https://github.com/solid/web-access-control-spec#modes-of-access) granted per the [ACL inheritance algorithm](https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm) on the resource directly associated with it.

### Shape Validation
justinwb marked this conversation as resolved.
Show resolved Hide resolved

Shape Validation ensures that any data changes in a given resource conform to an associated [SHACL](https://www.w3.org/TR/shacl/) or [ShEx](https://shex.io/shex-semantics/index.html) data shape. It MUST be supported as a resource metadata type by Solid servers.

The Shape validation metadata resource for a given resource is discovered by the client via ```rel=http://www.w3.org/ns/solid/terms#shape```. Conversely, the resource being described by a Shape validation metadata resource is discovered by the client via ```rel=http://www.w3.org/ns/solid/terms#resource```.

A given Solid resource MUST NOT be directly associated with more than one Descriptive metadata resource.

A Shape validation metadata resource MUST be deleted by the Solid server when the resource it is directly associated with is deleted and the Solid server is authoritative for both resources.

To access or manage a Shape validation metadata resource, an [acl:agent](https://github.com/solid/web-access-control-spec#describing-agents) MUST have [acl:Control](https://github.com/solid/web-access-control-spec#aclcontrol) privileges per the [ACL inheritance algorithm](https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm) on the resource directly associated with it.

A Solid server SHOULD sanity check Shape validation metadata resources upon creation or update to restrict invalid changes.

### Server Managed

A Solid server stores information about a resource that clients can read but not change in Server Managed metadata. It MUST be supported as a resource metadata type by Solid servers.
justinwb marked this conversation as resolved.
Show resolved Hide resolved

A Server Managed metadata resource is discovered by the client via ```rel=http://www.w3.org/ns/solid/terms#servermanaged```. Conversely, the resource being described by a Server Managed metadata resource is discovered by the client via ```rel=http://www.w3.org/ns/solid/terms#resource```.
justinwb marked this conversation as resolved.
Show resolved Hide resolved

A given Solid resource MUST NOT be directly associated with more than one Server Managed metadata resource.

A Server Managed metadata resource MUST be deleted by the Solid server when the resource it is directly associated with is deleted and the Solid server is authoritative for both resources.

To access a Server Managed metadata resource, an [acl:agent](https://github.com/solid/web-access-control-spec#describing-agents) MUST have [acl:Read](https://github.com/solid/web-access-control-spec#aclread) privileges per the [ACL inheritance algorithm](https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm) on the resource directly associated with it.

### Configuration

Configuration metadata is used to store configurable parameters for a given resource. It MUST be supported as a resource metadata type by Solid servers.
justinwb marked this conversation as resolved.
Show resolved Hide resolved

A configuration metadata resource is discovered by the client via ```rel=http://www.w3.org/ns/solid/terms#configuration```. Conversely, the resource being described by a Configuration metadata resource is discovered by the client via ```rel=http://www.w3.org/ns/solid/terms#resource```.

A given Solid resource MUST NOT be directly associated with more than one Configuration metadata resource.

A Configuration metadata resource MUST be deleted by the Solid server when the resource it is directly associated with is deleted and the Solid server is authoritative for both resources.

To access or manage a Configuration metadata resource, an [acl:agent](https://github.com/solid/web-access-control-spec#describing-agents) MUST have [acl:Control](https://github.com/solid/web-access-control-spec#aclcontrol) privileges per the [ACL inheritance algorithm](https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm) on the resource directly associated with it.

## Non-Reserved Types
justinwb marked this conversation as resolved.
Show resolved Hide resolved

A Solid server may support other metadata types.

## Implementation Patterns
justinwb marked this conversation as resolved.
Show resolved Hide resolved

*This section is non-normative.*

There are many ways a Solid server could implement these features. A file-based Solid server could have a special naming scheme reserved for these metadata resources. Alternatively, a Solid server could represent every resource internally as a dataset, storing each separate type of metadata in its own named graph.

A Solid server needs to maintain a working knowledge of which resources are metadata, because it tells the clients where to find them. This means that it can similarly apply this knowledge to know when someone is writing to a known metadata resource, such as an ACL, and can apply the appropriate validation and sanity checks to ensure the changes are valid.