Add the semantics of slashes, which is shared by client and server

[RubenVerborgh]

[csarven]

"semantics of slashes"? Do you mean that 1) certain count of slashes 2) in particular locations of a URI should 3) have a special meaning and 4) handled in a particular way?

If so, I see that as an implementation detail and not something that should be prescribed in a spec.

[pmcb55]

@csarven No - I think this is about clients being able to rely on the semantic that a slash in an IRI explicitly means 'LDP containment', i.e. that an IRI of 'foo/bar/baz' means both 'foo' and 'foo/bar' are LDP containers, and that the container 'foo/bar' ldp:contains 'foo/bar/baz', and that the container 'foo' `ldp:contains' 'foo/bar'.

[csarven]

@pmcb55 I believe what I've raised covers that case.

What's the use case for a client application observing foo/bar/baz and needing to infer that foo or foo/bar are something in particular eg. LDP Containers? Note the subtle difference when encountering foo/bar/ ldp:contains foo/bar/baz where naturally foo/bar/ is a container ie. mostly likely described with rdf:type ldp:Container or at the very least can be inferred given the LDP vocab (as per ldp:contains rdfs:domain ldp:Container).

Clients should solely rely on the values provided in the HTTP headers or the message body for a given URI.

[csarven]

There are also potential issues for baking this sort of knowledge about URIs, if for example, LDP is no longer the primary or strictly the only platform. It effectively means that clients can work with non-LDP servers without major changes to their internal operations. So, while the Solid Ecosystem is for the time being specified around LDP, it doesn't need to go "all in" especially when we are not really forced to. It gives the ecosystem a chance to evolve in a simple manner.

[pmcb55]

Yep - I agree with you @csarven (and @RubenVerborgh) too! For the past two All-Hands I've wanted to discuss this very specific issue, but both times we didn't find the time to actively discuss it, unfortunately.
But @csarven - to your point about being locked into LDP, I probably overstated it above when I said slashes in IRI's explicitly mean ldp:contains. I think @timbl may just be saying the spec should state a slash in an IRI means 'contains' (although being more vague like that might hurt implementation interoperability!).
I believe the motivation behind it may have been to allow a Pod's IRI space map automatically to a file-system's folder and filename space.

[csarven]

Which is why such requirement needs to be rooted in use cases. What's the bottom line problem that's being addressed?

Even if something like this is given as a MAY or a Note, then there is still the risk of implementations dissecting URIs instead of looking at the headers or body.

It also raises the bar on making sure that the URI pattern is synchronised with the underlying semantics - another requirement.

Consequently, the spec will be handing out a URI Template reflecting LDP's semantics.

Hence, the reasons I've provided above (and I'm sure there are more) doesn't make me comfortable about this requirement.

Do the perceived benefits outweigh the issues?

[acoburn]

I also see this primarily as an implementation detail.

There is, however, one use case where a definition of the semantics of slashes could be especially useful, namely in the intersection of LDP and WebACL. LDP containment is strictly parent-to-child; for a given child resource, there is no specification-defined way (using HTTP headers or RDF statements) to find the parent resource. In WebACL, on the other hand, the inheritance algorithm requires knowledge of the child-to-parent relationship.

For an implementation, this means that it is necessary to have some mechanism to traverse from parent to child as well as from child to parent. Effectively, this means that an implementation needs some internal mechanism for exposing this information. This is easy if the LDP and WebACL components interact below the HTTP layer (this is the approach I have implemented); otherwise, if the two components are entirely separate and interact above the HTTP layer, there would need to be either (a) an assumption about the semantics of slashes or (b) some implementation-specific header (or other signifier) that indicates where the parent resource can be found.

[justinwb]

I agree with you @csarven.

However, @timbl wants to give slashes in URIs a shared meaning among servers and clients, and hence specify that.

For reference - see comment from @timbl here

[csarven]

As the ACL system already requires knowledge of child-parent relationship, then the pointer isn't particularly implementation-specific above and beyond what can work with a "file-based-solid-server". So the notion of .. (parent directory) like in Unix should suffice: ex:containedIn or acl:parent or whatever.

[kjetilk]

I'm not adding myself to the list of supporters just yet, but I do note that this could be used to resolve one of my itches with LDP-RSes, that POST doesn't mean "add some triples to the resource", which I think is a very important intuition for developers... :-) The key problem within LDP is that the client can't tell the difference between an LDP-C and an LDP-RS. With this, it can, just look for a slash.