Find a Data Registration from a Data Instance

[srosset81]

It would be very useful if, given a Data Instance, we could easily find the relative Data Registration.

For example with a simple Link header when we do a GET or a HEAD on a given resource:

Link: <https://mypod.store/alice/data/as/event>; rel="http://www.w3.org/ns/solid/interop#hasDataRegistration"

Solid already include such a link to find the storage linked with a given resource (source)

[srosset81]

Link: <https://mypod.store/alice/data/as/event>; rel="http://www.w3.org/ns/solid/interop#hasDataRegistration"

FYI I implemented exactly this in ActivityPods

[elf-pavlik]

I think it doesn't exactly fit how this predicate is defined
https://github.com/solid/data-interoperability-panel/blob/main/proposals/specification/interop.ttl#L104-L110

Currently we rely on ldp:contains to link data registration (container) with data instances (non-contianer resources). What do you think about simply using ldp:contains and anchor trick to get equivalent of rev like in https://solid.github.io/data-interoperability-panel/specification/#agent-registration-discovery

Link: <https://mypod.store/alice/data/as/event/bcf22534-0187-4ae4-b88f-fe0f9fa96659>;
    anchor="https://mypod.store/alice/data/as/event/";
    rel="http://www.w3.org/ns/ldp#contains"

[srosset81]

Sure, no problem to change that !

I'm wondering if the anchor is necessary though ? Because in your example above, the first link (<https://mypod.store/alice/data/as/event/bcf22534-0187-4ae4-b88f-fe0f9fa96659>) is the resource we are fetching, so this information is unnecessary.

Why not simply do:

Link: <https://mypod.store/alice/data/as/event>; rel="http://www.w3.org/ns/ldp#contains"

But then it would make more sense to use a containedBy predicate, which doesn't exist in the LDP ontology ?

[elf-pavlik]

HTTP Link header used to have rev but it was deprecated. Since we only have ldp:contains, and many ontology experts consider defining inverse properties in the vocab as bad practice, we can use anchor to set the subject and just use IRI denoting resource that is being requested inside of <> (url) which makes it an object in the statement.
subject predicte object ~= anchor rel url (without anchor it's request.url rel url)

https://www.rfc-editor.org/rfc/rfc8288.html#section-3.2

By default, the context of a link conveyed in the Link header field
is the URL of the representation it is associated with, as defined in
[RFC7231], Section 3.1.4.1, and is serialised as a URI.

When present, the anchor parameter overrides this with another URI,
such as a fragment of this resource, or a third resource (i.e., when
the anchor value is an absolute URI).

BTW

• parseLinkHeaders doesn't include anchor solid-contrib/specification-tests#119