search

solid / specification

Solid Technical Reports
https://solidproject.org/TR/
MIT License
472 stars 42 forks source link

Solid Resources needs a way to tell what their containers are #528

Open bblfish opened 1 year ago

bblfish commented 1 year ago

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 commented 1 year ago

See also:

woutermont commented 1 year ago

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 commented 12 months ago

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 commented 12 months ago

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 commented 12 months ago

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

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