Solid Resources needs a way to tell what their containers are

[bblfish]

The Web Access Control Spec has a section on how to calculate the Effective ACL Resource by following a resource up to its "container resource".
The Solid Protocol Spec specifies using 3.1 URI Slash Semantics. So it is clear what the intention is.

But how is a client to know it has landed on a Solid server that implements those intentions rather than one that has not? There will be many LDP servers implemented by the LDP consortium members. A client can't distinguish between those servers and those implementing Solid, potentially leading to many unnecessary requests.

There are a number of ways of doing this.

1. Compatible with LDP servers: every resource has a reverse link to the container, which in Solid would always be ../, but on other LDP containers could be something else.

Link: <../>; rev="http://www.w3.org/ns/ldp#contains"

2. Specify that a resource is not an ldp:BasicContainer or ldp:Resource but a subset of those, namely a solid:Container or solid:Resource. Note this was proposed in the 2013 to the LDP group and later became issue-50.

Clearly, if a resource specifies that it is a solid resource, then point 1 is unnecessary as the URL structure contains the information about the ldp:contains link. On the other hand, for more lax servers following LDP, then 1 is needed.

I don't think that having an "acl" link header is enough to distinguish the server as being a solid one, as that link could very well also be used by LDP servers.

[damooo]

See also:

• There is no way specified for upward navigation. #400
• Proposal: Containment chain auxiliary resource #399

[woutermont]

While I do agree with @kjetilk in #399 that we should refrain ourselves from all too eagerly providing special affordances to specific forms of knowledge organization, I find the proposal of @bblfish to use reverse containment triples as Link headers quite elegant (but only in the case of resources that fall into a hierarchical organization of course).

[See also my comment on #399]

[kjetilk]

Yes, this seems reasonable to me too.

However, could we do this use-case-driven? It seems like the main reason to do this is efficiency, to not need to traverse a tree upwards, but could we see actual situations where this would be important?

[elf-pavlik]

Link: <../>; rev="http://www.w3.org/ns/ldp#contains"

I also like it, sadly rev was deprecated

https://datatracker.ietf.org/doc/html/rfc8288#section-3.3

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.

[csarven]

No judgement on prettiness but by changing the link context, this should be equivalent:

Link: <... container/resource>; anchor="... container/"; rel="... ldp#contains"