specification
specification copied to clipboard
solid
Solid Resources needs a way to tell what their containers are
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.
- 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"
- Specify that a resource is not an
ldp:BasicContainerorldp:Resourcebut a subset of those, namely asolid:Containerorsolid: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.
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]
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?
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.
No judgement on prettiness but by changing the link context, this should be equivalent:
Link: <... container/resource>; anchor="... container/"; rel="... ldp#contains"
