Abstract 'containers' as Link Set representations of arbitrary relational metadata

[termontwouter]

Hi all,

After last week's meeting (March 23rd), I looked into #86 again in more detail (as well as related issues #67, #69, #71, #77, #83, #90, #95). A more uniform treatment of resources and containers, in particular using Link Sets, is very similar to what we have been doing in A4DS (and its research implementation), which uses ODRL (also used in LWS's Access Requests and Grants ED) as policy layer for User-Managed Access (UMA). Moreover, both approaches practically re-invent LDP Direct Containers (cf. a comment I made 3y ago). In this issue, I therefore want to propose a unified model, based on Link Sets (RFC 9264), that addresses the issues listed above, as well as several concerns voiced in them by different people.

• The core idea is to treat all resources as opaque entities, with arbitrary representations (and any API), that can have zero or more relations of arbitrary types, maintained as zero or more Link Set representations of those resources.
• Basic containers (LWS/Solid/LDP) are then resources whose Link Set representation includes ldp:contains relations, and whose standard representation is (a serialization of) that Link Set.
• On top of that, however, resource servers would freely decide which relations to track between resources, and whether clients have direct control over these relations. This info can be declared in resource- or server-specific metadata (e.g., storage description).
• Operations on Link Sets can be supported via GET and PATCH, in two ways (accommodating for different concerns):
  • Resource servers may allow direct interaction at the resource itself, negotiated with media types application/linkset+json (for GET) and application/linkpatch+json (for PATCH; name TBD); this provides a performant method, but requires content negotiation.
  • Resource servers may add one or more Link headers in responses to HEAD/GET requests, deferring interaction to auxiliary URIs, which are the content location of a specific Link Set representation. This requires an extra hop, but can be generated on the fly, without content negotiation, and should thus not pose an additional burden on the server.

As indicated above, such a model would be very similar to the ones of LDP and A4DS. Considering a resource server, compliant with the points above, which serves a resource's Link Set representation as one auxiliary URI per different relation type; there exists a one-to-one mapping between the following:

• LDP's ldp:DirectContainer, A4DS's odrl:AssetCollection, and a Link Set representation;
• LDP's ldp:membershipResource, A4DS's odrl:source, and the Link Set's anchor;
• LDP's ldp:isMemberRelation, A4DS's a4ds:relation, and the Link Set's rev (or switching anchor and href);
• LDP's ldp:hasMemberRelation, A4DS's use of @reverse, and the Link Set's rel;
• LDP's ldp:contains, (the inverse of) A4DS's odrl:partOf, and the Link Set's href.

In each of these cases, the set/collection/(direct)container is an 'auxiliary resource' representing all resources related to the (membership) (re)source/anchor via the (member) relation. Conceptually, each resource server managing resources Ri and tracking relation types Pj has such an auxiliary for each pair (Rn,Pm). This abstraction of containment allows resource servers to track any hierarchy of relations they deem interesting, not limited to listing other resources (e.g., relations relevant to policy management, derivation, composition). In particular, resources can be related via multiple different relation types, both with one single resource as with different resources.

The actual interface providing this metadata to clients can be quite flexible: the Link Set representations could be provided on multiple auxiliary URIs, in line with their conceptual separation (as above); they could be bundled and served from single auxiliary URI; or the same bundle could be served through content negotiation on the URI of the resource itself (cf. above). Note that none of this limits the API of the resources themselves in any way. To the contrary, the model can be applied to any kind of API, and allows operations on that API (or even completely out-of-band) to indirectly affect relational metadata. For example, traditional LDP/Solid/LWS operations (POST to a container, DELETE a resource ...) affect the ldp:contains metadata of the (basic) container; interaction with UMA's resource registration endpoint in A4DS affects the odrl:partOf metadata of the asset collections.

In two follow-up comments, I will provide example requests and responses following this approach in general, and applying this approach to the concrete case of traditional LDP/Solid/LWS containers.

[termontwouter]

In this follow-up comment, I'll try to sketch the idea of how such a model would be used in practice.

By sending a GET/HEAD requests, clients can discover the content location of a resource's Link Set representation(s). Servers can declare a Link Set profile (server-wide or resource-specific), describing the possible relations and their semantics.

HEAD /docs/X.D-1234 HTTP/1.1
Host: pub.net

HTTP/1.1 200 OK
Link: <https://meta.pub.net/X.D-1234>
  ; rel="linkset" ; profile="https://voc.pub.net/links"

Such a Link Set profile could list the membership relations supported by the resource, as well as whether clients can directly PATCH those relations themselves.

GET /links HTTP/1.1
Host: voc.pub.net
Accept: application/ld+json

HTTP/1.1 200 OK
Content-Type: application/ld+json

{
  "@context": {...},
  "@id": "https://pub.net/",
  "lws:supportedLinks": [
    {
      "@id": "https://voc.pub.net/links/pub#hasVersion",
      "lws:patchSupported": "false"
    }, {
      "@id": "https://www.w3.org/ns/lws#contains",
      "lws:patchSupported": "true"
    }
  ]
}

Servers can provide the Link Set(s) as application/linkset+json on an auxiliary URI. Through a JSON-LD context, this media type can be interpreted as RDF (cf. RFC 7240).

GET /X.D-1234 HTTP/1.1
Host: meta.pub.net
Accept: application/linkset+json

HTTP/1.1 200 OK
Content-Type: application/linkset+json
Link: <...> ; rel="http://www.w3.org/ns/json-ld#context"

{
  "linkset": [{
    "anchor": "https://pub.net/docs/X.D-1234",
    "up": [{ "href": "https://pub.net/projects/X.P-0004" }],
    "hasVersion": [
      ...
      { "href": "https://pub.net/docs/X.D-1234/v/56" }
    ]
  }]
}

Alternatively, servers could support direct interaction through content negotiation.

GET /docs/X.D-1234 HTTP/1.1
Host: pub.net
Accept: application/linkset+json

HTTP/1.1 200 OK
Content-Type: application/linkset+json
  ; profile="https://voc.pub.net/links"
Content-Location: <https://meta.pub.net/X.D-1234>
Link: <...> ; rel="http://www.w3.org/ns/json-ld#context"

...

In both cases, clients could be allowed to include a Prefer header, to query for specific relation(s) they are interested in (cf. LDP's use of RFC 7240). Note how the server could also provide this (partial) representation content on another (dynamic) auxiliary location.

GET /docs/X.D-1234 HTTP/1.1
Host: pub.net
Accept: application/linkset+json
Prefer: rel="https://voc.pub.net/links/pub#hasVersion"

HTTP/1.1 200 OK
Content-Type: application/linkset+json
  ; profile="https://voc.pub.net/links"
Content-Location: <https://meta.pub.net/X.D-1234?rel=https%3A%2F%2Fvoc.pub.net%2Flinks%2Fpub%23hasVersion>
Link: <...> ; rel="http://www.w3.org/ns/json-ld#context"

{
  "linkset": [{
    "anchor": "https://pub.net/docs/X.D-1234",
    "hasVersion": [{ ... }]
  }]
}

Apart from (potentially) being affected by operations on a resource's API, servers can allow clients to update relational metadata directly with a Link Set PATCH request (through content negotiation or via an auxialiary URI). To facilitate bundling of changes, clients could PATCH both the subject resource and the object resource of a membership relation.

PATCH /docs/X.D-1234 HTTP/1.1
Host: pub.net
Content-Type: application/linkpatch+json
Link: <...> ; rel="http://www.w3.org/ns/json-ld#context"

{
  "remove": [{
    "anchor": "https://pub.net/projects/X.P-0004",
    "contains": [{ "href": "https://pub.net/docs/X.D-1234" }]
  }],
  "add": [{
    "anchor": "https://pub.net/projects/X.P-0010",
    "contains": [{ "href": "https://pub.net/docs/X.D-1234" }]
  }]
}

HTTP/1.1 204 NO CONTENT
Location: <https://pub.net/docs/X.D-1234>
Link: <https://meta.pub.net/X.D-1234>
  ; rel="linkset" ; profile="https://voc.pub.net/links"

[termontwouter]

In this follow-up comment, I'll apply the above to traditional LDP/Solid-style containers, which can be seen as one instance of the more general model above (with some added sugar); a first profile of the abstract model, as it were. As such, it also inherits the uniform and multiple containment aspects.

A POST request to any resource, with a Link header of which the relation type is an allowed membership relation of the target resource, adds the request body as initial representation of a new resource on the server, and adds the Link header's information to the relational metadata of the target resource. Adding a resource to a traditional container would thus become the following. (The specification could also hold ldp:contains to be the default relation for POST requests to basic containers, thus achieving full backwards compatibility.)

POST /docs HTTP/1.1
Host: pub.net
Content-Type: text/plain
Link: <https://pub.net/docs>
  ; rev="http://www.w3.org/ns/ldp#contains"

...

HTTP/1.1 201 CREATED
Location: <https://pub.net/docs/X.D-5678>
Link: <https://meta.pub.net/X.D-5678>
  ; rel="linkset"
  ; profile="https://voc.pub.net/links"

If the POST request has an empty body, and a Location header referring to an already existing resource, a relation of the referred resource with the target resource is added to relational metadata of the latter, without creating a new resource.

POST /archive HTTP/1.1
Host: pub.net
Content-Location: <https://pub.net/docs/X.D-5678>
Link: <https://pub.net/archive>
  ; rev="http://www.w3.org/ns/ldp#contains"

HTTP/1.1 204 NO CONTENT
Location: <https://pub.net/docs/X.D-5678>
Link: <https://meta.pub.net/X.D-5678>
  ; rel="linkset"
  ; profile="https://voc.pub.net/links"

Similarly, a DELETE request containing a Link header, of which the relation type is an allowed membership relation of the target resource, might merely remove the resource as member of the link target via the link relation. (The specification could also hold ldp:contains to be the default relation for DELETE requests to resources contained in basic containers; and/or define DELETE requests without a Link header to request the removal of all relations of the resource; again to achieve backward compatibility.)

DELETE /docs/X.D-5678 HTTP/1.1
Host: pub.net
Link: <https://pub.net/archive>
  ; rev="http://www.w3.org/ns/ldp#contains"

HTTP/1.1 204 NO CONTENT
Location: <https://pub.net/docs/X.D-5678>
Link: <https://meta.pub.net/X.D-5678>
  ; rel="linkset"
  ; profile="https://voc.pub.net/links"

Creating membership resources like containers can be done like any other resource, by including one or more Link headers in the POST/PUT request, with http://www.w3.org/ns/ldp#membershipRelation as relation, and the allowed membership relation(s) for that resource as target. In case of a traditional container, this would boil down to the following example (with no body or content type).

POST / HTTP/1.1
Host: pub.net
Slug: images
Link: <http://www.w3.org/ns/ldp#contains>
  ; rel="http://www.w3.org/ns/ldp#membershipRelation"

HTTP/1.1 201 CREATED
Location: <https://pub.net/images>
Link: <https://meta.pub.net/ldp/images>
  ; rel="linkset"
  ; profile="https://voc.pub.net/links"

[kaefer3000]

Are you referring to IETF RFC 9264 linksets?

[termontwouter]

Are you referring to IETF RFC 9264 linksets?

I am indeed. Should have made that clearer perhaps...

[elf-pavlik]

POST /docs HTTP/1.1
Host: pub.net
Content-Type: text/plain
Link: <https://pub.net/docs>
  ; rev="http://www.w3.org/ns/ldp#contains"

...

Besides rev having been deprecated. aren't anchor and target the same when Link is used this way? /cc @CxRes

[termontwouter]

Hi @elf-pavlik

Besides rev having been deprecated ...

I know it is; just used it to sketch the idea, since alternatives are a bit more verbose:

• add an anchor parameter; though semantically this would be difficult with POST; or
• register a new parameter to indicate the direction of the relation (e.g., inv).

... aren't anchor and target the same when Link is used this way?

For requests, the link context is not identified with the request URI. Unless indicated by a Content-Location header, the specification leaves it undefined. I.m.o., LWS could therefore specify that in such a situation it identifies the link context with the URI of the newly created resource (if successful).

[elf-pavlik]

Hi @termontwouter 👋

Thanks for the clarification. I agree that rev serves it's purpose to illustrate the idea and once it gets more traction in the WG all the details can be ironed out.

I will think how this approach compares to shapetree references used in SAI inherited grants to satisfy

• [UC] Context aware access policies lws-ucs#17