Use of anchor= for linking back from metadata resources

[justinwb]

Should anchor= be used rather than rel= when linking back to the associated resource from the metadata resource? (see RFC 5988)

[TallTed]

No. I believe Link: rel=describes (RFC 6892) is far more appropriate than anchor=.

(The reverse relationship, from resource to metadata resource, gets Link: rel=describedby, from POWDER and RFC 5988)

[ericprud]

Related: https://github.com/solid/data-interoperability-panel/issues/33#issuecomment-573291108

I think these two constructs should have identical semantics:

1. Resource R's headers include Link: rel="describedby" href="R.meta.ttl"
2. R.meta's headers include Link: rev="describedby" anchor="R"

RFC5988 asserts that rev

often confuses authors and readers; in most cases, using a separate relation type is preferable

Lexically, it appear that describedby is intended to be the inverse of describes, but that's not stated anywhere. I also feel like RDF users are above average at handling link direction.

As a design principle, I prefer to avoid making programmers search for information across multiple expressions (e.g. X describes Y and Y describedby X). Yeah, you could have inference but most tool chains don't. In net I prefer Link: rev="describedby" anchor="R" over Link: rel="describes" href="R".

[TallTed]

Web Linking, RFC 5988, has been obsoleted by Web Linking, RFC 8288, which deprecated rev, stating --

   The "rev" parameter has been used in the past to indicate that the
   semantics of the relationship are in the reverse direction.  That is,
   a link from A to B with REL="X" expresses the same relationship as a
   link from B to A with REV="X". rev is deprecated by this
   specification because it often confuses authors and readers; in most
   cases, using a separate relation type is preferable.

---

[@ericprud] Lexically, it appear that describedby is intended to be the inverse of describes, but that's not stated anywhere. I also feel like RDF users are above average at handling link direction.

Actually, it is stated at IANA Link Relations, in the Notes for describes --

This link relation type is the inverse of the 'describedby' relation type. While 'describedby' establishes a relation from the described resource back to the resource that describes it, 'describes' established a relation from the describing resource to the resource it describes. If B is 'describedby' A, then A 'describes' B.

The 'describes' Link Relation Type, RFC 6892, says much the same, in several places, including --

   Since many scenarios using resource descriptions need to represent
   the fact that some resource describes another resource (the opposite
   of the 'describedby' relation), this document registers a 'describes'
   link relation type.  Establishing a link A 'describes' B asserts that
   the resource identified by A is a description of the resource
   identified by B, without constraining in any way the identifiers
   being used for A and B, and the media types for the representations
   being provided when those identifiers are dereferenced.
   Specifically, it is possible that identifiers A and/or B have no
   associated interaction method (they could be URNs, for example), but
   it still is valid to establish the A 'describes' B link.

---

The significant oddness I see here is that describedBy was cough described first; describes came later. I think it much more common that the relationship between a description (which is usually created second) and a thing is asserted in (or with) the description than that this relationship is asserted in (or with) the thing itself -- and this is borne out by virtually all descriptions now found either on the web or in physical documents.

[justinwb]

Great feedback @TallTed. Seems we're right to stick with rel=, though in the document we have been using rel=http://www.w3.org/ns/solid/terms#resource, rather than than a different term for each reverse relationship. The one example that could be argued isrel=describes, since we use rel=describedby for the resource description metadata type. However, it seemed right to be consistent rather than special case that one.

[TallTed]

@justinwb -

"using rel=http://www.w3.org/ns/solid/terms#resource [for all relationships]" is definitely problematic, as it leaves the typed-relationship world of RDF behind, and goes back to the untyped-relationship world of HTML, i.e., "this resource is somehow linked to that resource".

I also note that there is no http://www.w3.org/ns/solid/terms#resource in http://www.w3.org/ns/solid/terms.

I think the following covers my thinking...

• LDP-RS R.meta's headers SHOULD include --

  Link: rel="describes" href="R"
  

• LDP-RS R.meta itself SHOULD also include (adjusted for media type) --

  { <> iana-link-relations:describes <R> . }
  

• LDPR (both LDP-RS and LDP-NR) R's headers SHOULD include (when known) --

  Link: rel="describedby" href="R.meta.ttl"
  

• LDP-RS R itself SHOULD include (when known) (adjusted for media type) --

  { <> powder:describedby <R.meta.ttl> . }
  

• LDP-NR R itself MAY include (when media type allows AND when known) something like (depending on R's media type) --

  <link rel="describedby" type="text/ttl" href="R.meta.ttl" >
  

[ericprud]

@TallTed - thanks for making this all explicit.

This kinda illustrates my point about the cost of mandating the inclusion of inverse properties. If I use rdflib's generic HTTP-header-to-RDF translator, I get the assertions you suggest we include in the bodies of R and R.meta:

<R.meta> iana-link-relations:describes <R> .
<R> iana-link-relations:describedby <R.meta> . # or powder:describedby

It's a mild pain in the butt that every generic tool (e.g. a linter which reports who can edit R.meta but can't see R) will have to look for the links in both directions. The alternative being mild civil disobedience in the use of the deprecated rev.

In general, I'm all for respecting deprecation, but I think that deprecating rev will lead to a proliferation of defensive programming. A middle ground might be having the specs pick a favorite direction so that HTTP-header-to-RDF translators will normalize to that direction.

[csarven]

While rev+anchor can be treated as semantically identical to rel+href, I'm not sure if it is simpler in the end. Implementations may of course handle them as identical. Additional considerations:

rel requires two relation types whereas rev requires one relation type, however it introduces two additional attributes (rev, anchor) into the implementation.

It may be preferable to encourage having self-describing resources. If so, rel+href would be preferable.

[csarven]

I propose to include the following criteria for clients for discovering these resources (adapted from https://www.w3.org/TR/ldn/#discovery ): " Clients do the following to discover resources and their metadata:

• make an HTTP HEAD or GET request on the target URL, and use the Link header with a rel value of describedby or describes.
• make an HTTP GET request on the target URL to retrieve an RDF representation [RDF 1.1], whose encoded RDF graph contains a relation of type describedby or describes. The subject of that relation is the metadata resource and the object is the resource it is about.

These may be carried out in either order, but if the first fails to result in discovering the metadata resource or the resource the second MUST be tried. "

[elf-pavlik]

LDP-RS R.meta itself SHOULD also include (adjusted for media type) -- { <> iana-link-relations:describes <R> . }

If we want to make RDF statements matching link headers we should use full URIs, IANA registered link relations don't have official maping to URIs https://github.com/mnot/I-D/issues/140 (also mentioned in https://github.com/solid/data-interoperability-panel/issues/38 )

[csarven]

There is https://www.w3.org/ns/iana/link-relations/relation .

The relations are not tied to LDP-centric resource and Solid is not enforcing LDP's classification, so I'd suggest to define behaviour without mentioning LDP. See for example the proposed client behaviour in https://github.com/solid/data-interoperability-panel/issues/37#issuecomment-578548898 and more broadly in https://github.com/solid/data-interoperability-panel/pull/32#issuecomment-578549345 .

By the way, what's "full URI"? Do you mean "absolute URI"?

[elf-pavlik]

By the way, what's "full URI"? Do you mean "absolute URI"?

I meant just URI, not a registered link relation

There is https://www.w3.org/ns/iana/link-relations/relation - I thought I've mentioned this before (elsewhere).

Does some normative reference exist or solid spec would need to establish usage of that prefix for mapping IANA registered link relations to URIs in solid ecosystem?

[csarven]

There is no normative reference as far as I know - don't quote me ;) [Tim created it and maintains it. I use it as is.]

It is only necessary for RDF bearing documents ie. not necessary in Link header since the IANA term can be used as is at the very least. Solid specs could say that the rel URI is equivalent to the IANA term but I think that can be problematic. We should not do this!

Non-registered IANA terms have local scope. So, at the moment, because eg. "acl" is not registered, my use of rel=acl and your use of rel=acl are not necessarily the same - but yes, we could look the other way and in good faith say that they are - Solid spec can make some effort to declare the definition at least (even if not part of IANA). And, so, implementations prefixing a non-URI and non-IANA registered term (like "acl") with https://www.w3.org/ns/iana/link-relations/relation# wouldn't be a good idea. If we want to use "acl", I suggest to either register it at IANA or go with something like http://www.w3.org/ns/solid/terms#acl or http://www.w3.org/ns/auth/acl#acl or whatever. See also https://github.com/solid/specification/issues/54 , https://github.com/solid/web-access-control-spec/issues/21

[ericprud]

I don't think we want the body of the document to include references to the metadata. Picking on e.g. ACLs:

1. invites conflicts between server's notion of X's ACL and what's in X. Would the server look in every POST/PUT for possible ACLs references? What if the document were simply documenting WAC?
2. invites client to make edits that lose control or are inconsistent with policies or spec (off-site ACLs, multiple ACLs resources).
3. would conflict with servers that pick the identities for their ACLs resources.

Proposal: The response to a HEAD or GET on a LDPR R includes link headers for the different kinds of metadata: ACLs, Shape, Config, Server-managed.

Specifically, there is no mention of R's body.

[csarven]

@ericprud Nod. Ack. Etc. Background: IIRC, the intention started out of the possibility to have the relationships available from the RDF body because the client may not necessarily have the possibility - whether they should be able to or not may be orthogonal - to update the HTTP header information - the current design doesn't permit that eg. no LINK method or some other way to influence the headers. So, RDF body was the next possibility.

The points you raise are well grounded so it make sense to not bother with discovery through RDF body, especially for something like ACL and synchronisation challenges. If we just want to link Web resources, discovery of resource metadata through Link header will suffice. One thing that the alternate RDF body approach provided is to use the relations on URIs with fragments but perhaps that's an edge case any way?

I retract the proposal on discovery through RDF body. Link header should be the only required way for discovery.

Aside: we can look into the possibilities through LINK or whatever separately (and whether it is sensible)