Are URI semantics just necessary or sufficient to determine containment relation?

[damooo]

Spec says that:

The slash (/) character in the URI path indicates hierarchical relationship segments, and enables relative referencing [RFC3986]. The semantics of the slash character is shared by servers and clients. Paths ending with a slash denote a container resource.

If it is necessary:

If above statement is expressing a necessary condition, then if two resources are known to be in container-child relation, their uri MUST follow (neccessary) follow above condition.

But vice-versa may not be true. I.e, if uris of two resources share hierarchical relation ship, then they need not be in containment relation, as the condition is not sufficient.

This indeed seems the case, that resource with uri a/abc.acl, need not be child of resource with uri of a/, even though their uris are in hierarchical relation. But it instead may be aux of a/abc.

If it is also sufficient:

Let's assume, there are three resorces:

1. R1 with uri /path/to/r1/,
2. R2 with uri /path/to/r1/abc,
3. Rx with uri /path/to/r1/<slug>.

Then if condition is also sufficient, one can conclude that Rx MUST be child of R1`, for they satisfy suffient condition for containment.

But we see this is not the case. We can see that if <slug> in Rx is abc.acl, then it may be instead acl of R2 rather than child of R1.

Problem

We above saw that, uri-slash-semantics are actually necessary for containment to hold, but not sufficient to unambiguously infer containment between to resources.

But we have been seeing in many places, the slash semantics beeing inconsistently treated as sufficient, and being used to infer containment when that may not be guaranteed.

For example:

If a container resource R1 with uri /path/to/r1/ is known to exist, and resource Rx with uri /path/to/r1/<slug> is is known to not yet exist, and a GET is sent for Rx, then should we consult acl:default of R1's acl for determining status code to 403/404?

My sense says that, as resource Rx known to not exist yet, it is not child of any resource, as semantics are necessary but not sufficient. This is indeed the case if <slug> may be abc.acl, it can be slot for aux of other instead. But many places in the issues, it is taken for granted that R1's acl's acl:default will be applied to determine method access over Rx.

[elf-pavlik]

This indeed seems the case, that resource with uri a/abc.acl, need not be child of resource with uri of a/, even though their uris are in hierarchical relation. But it instead may be aux of a/abc.

I agree that this is a common practice in implementations and applies to different kinds of auxiliary resources a/abc.meta for rel="describedby" etc.

In #538 I proposed a non-normative note to clarify that it's necessary but not sufficient. I think this will be discussed during the next CG meeting. We could also consider adding it as a normative requirement. In lines of:

Clients MUST determine containment based on ldp:contains assertion and not infer containment based on URI Slash semantics.

/cc @csarven @woutermont

[woutermont]

This indeed seems the case, that resource with uri a/abc.acl, need not be child of resource with uri of a/, even though their uris are in hierarchical relation. But it instead may be aux of a/abc.

I agree that this is a common practice in implementations and applies to different kinds of auxiliary resources a/abc.meta for rel="describedby" etc.

While it seems to be common practice, this violates the strict letter of the current spec, which imposes a 1-1 correspondence between slashes and containment (ref).

Given the confusion this keeps causing, it is definitely a good idea to schedule this for another discussion in the CG meeting.

EDIT: added ref

[woutermont]

My two cents on which direction this could/should go:

The decision to deviate* from basic Web conventions on generic URI slash semantics and instead have a 1-1 correspondence between path hierarchy and container hierarchy was made a long time ago, for better or worse, to have some unix file-system familiarity in Solid URIs, affording the (i.m.o. minor) practicality of infering containment hierarchy from path hierarchy (for relative reference and offline parent discovery). While I would normally be the first to try and revert that decision, I have learned that sometimes it is best to leave settled things be settled.

Unless we want to do the whole discussion over, we therefore have to live with the (i.m.o. major) downside: we MAY NOT use URIs with a path component for non-hierarchical resources. All non-hierarchical resources must therefore have an URI consisting of the root of the Solid server and at most one (opaque) path segment (optionally followed by query and fragment components, of course); in @timbl's words: "You can build a flat non hierarchical system in solid - just don't use the slash/." In practice, this means, for example, that if we want to treat auxiliary resources as Solid resources, these will either have to follow the slash semantics rule, or have an identifier as described above.

Again, I think that, for now, it may be best to leave this decision as it is, and bring practice in line with it. Non-hierarchical URI's (max 1 path segment) are a viable, if somewhat convoluted, way to cope with the restriction:

• URIs of the form http://solid-server.net/path/to/resource can only be a resource contained a chain of parents, the server being the root. (Note that a Solid server can semantically not run on a non-empty path: http://ex.org/solid/server/resource would impose the server to be LDP-contained in http://ex.org/solid/, which must in turn be LDP-contained in http://ex.org/!)

• URIs of the form http://solid-server.net/flat-resource-1234567890 can still be used for any static non-hierarchical resource.

• URIs of the form http://solid-server.net/tpf?o=objectvalue can still be used to identify dynamic non-hierarchical resources. (This could be a solution for keeping auxiliary resources non-hierarchical: /acl?context=[url-enc-resource-uri].)

---

* The belief that the URI generic syntax spec itself informs such a correspondence, on which the original decision for the 1-1 correspondence is based (ref), is wrong. The URI spec only states that "[t]he path component contains data, usually organized in hierarchical form," and that "[u]se of the slash character to indicate hierarchy is only required when a URI will be used as the context for relative references" (my bold). In other words, as far as the generic syntax is concerned, URIs can perfectly contain a path that is not hierarchical, and thus consumers of them should not assume so.

[kjetilk]

I think I align with you here, @woutermont . Indeed, the aux resources and their consequences for containment hierarchy has not been done sufficiently clear, and we should have addressed that sooner.

However, I'll also note that

The belief that the URI generic syntax spec itself informs such a correspondence, on which the original decision for the 1-1 correspondence is based (#35 (comment)), is wrong.

one thing is the wording that went into the spec, another thing are the assumptions that was done with early Web architects, that wasn't written in MUSTs. The 1-1 correspondence was based on a the URI syntax, which was again informed by earlier hierarchical systems, but it was kept more flexible when it went into the specs.

[woutermont]

Thank you for adding that nuanced background, @kjetilk!

As action following on todays CG meeting, I hereby do a call specifically for Use Cases concerning the hierarchical nature of Solid Resource URIs:

1. What are Use Cases that need the 1-1 correspondence (currently in the spec) to hold?

   1. When do we need every hierarchical resource to definitely have a hierarchical URL,
      i.e. when do we count on [R is contained in P] implying [R's URI is P's URI slash some path segment]?

      • We want to follow RFC3986 (URI Generic Syntax) strictly. (URI Path Component)
      • When we want to have Solid define as little extra constraints as possible. (@woutermont, at time of writing)

   2. When do we need every hierarchical URL to identify a hierarchical resource,
      i.e. when do we count on [R's URI is the URI P slash some path segment] implying [R is contained in P]?

      • When we want to follow RFC3986 also in spirit of its authors. (@kjetilk's comment)
      • When we want to provide backward compatibility. (@timbl's comment on #35)
      • When we want intuitive affordances in line with unix file systems. (@timbl's comment on #35)
      • When we want to infer parent resources without network call. (@timbl's comment on #35)

2. What are Use Cases that need us to get rid of this 1-1 correspondence?

   1. When do we need a hierarchical resource to be able to have a non-hierarchical URL,
      i.e. when must it be possible that [R is contained in P] holds, but [R's URI is P's URI slash some path segment] not?

      • When we want to hide the hierarchy from the public eye for security/privacy reasons. (@woutermont, at time of writing)
      • When we want the ability to move the resource in the hierarchy without changing its URL. (@elf-pavlik's comment)

   2. When do we need a hierarchical URL to be able to identify a non-hierarchical resource,
      i.e. when do must it be possible that [R's URI is the URI P slash some path segment] holds, but [R is contained in P] not?

      • When we want auxiliary resources to have the same URI as their target resource plus a suffix (i.e. R -> R.acl, R.meta etc). (current common practice described in @elf-pavlik's comment)
      • When we need specs like Well-Known URIs (RFC 8615). (@elf-pavlik's comment)

I've added the Use Cases I've encountered up till now. I'll try to keep this list updated as people comment.

EDIT: Added use cases provided by @elf-pavlik.

[kjetilk]

OK, that sounds more like a full reopening of the issue. I wasn't quite thinking that would be worthwhile at this point, but if the CG wants that, OK.

I think it makes sense to accept the slash semantics at this point, but to explore the many important edge cases, like aux resources, the compound resource state (like having a HTML representation of it, should it be writeable by the client, etc), resource naming constraints in general (#368 , which I think would be very helpful in resolving the problem in this issue too).

I have reduced my engagement in Solid for the time being, but that would be my advice, but the CG is certainly free from my perspective to think otherwise.

[woutermont]

Like I have already indicated in an earlier comment, that would also be my preference at this point, but only under the condition that we have it for all resources (including auxiliaries).

In any case, we will end up with a better overview of the real pro's and con's.

[elf-pavlik]

When do we need a hierarchical resource to be able to have a non-hierarchical URL,

When we want the ability to move the resource in the hierarchy without changing its URL

When do we need a hierarchical URL to be able to identify a non-hierarchical resource,

There is a broader case besides auxiliary resources. For example /.well-known/ where the solid storage is deployed at the domain root /.

[woutermont]

Thanks for the valuable additions, @elf-pavlik! Could you elaborate on the following?

[W]e want the ability to move the resource in the hierarchy without changing its URL.

What would 'moving a resource' entail? On a semantic level, resources can't move (they can be copied to another URL though). On the level of implementation, some storage backends might have a notion of 'movement' (e.g. a file system), but the hierarchy of those backends is not necessarily coupled to the (LDP) hierarchy of resources with which the 1-1 correspondence with URLs is concerned.

[W]e need specs like Well-Known URIs.

Would it be semantically incorrect to say that a Solid storage contains it's Well-Known resources? For example a storage http://my.store/ could have

• a single (non-container) resource http://my.store/path/to/resource;
• a Well-Known Storage Description http://my.store/.well-known/storage-description;
• a Well-Known Container for ACLs http://my.store/.well-known/acl/, containing
  • a default ACL http://my.store/.well-known/acl/.acl, and
  • an ACL for the resource http://my.store/.well-known/acl/path/to/resource.acl,
  • with http://my.store/.well-known/acl/path/to/ intuitively containing the ACLs for resources contained in http://my.store/path/to/;
• a Well-Known Container for metadata descriptions http://my.store/.well-known/meta/, containing
  • metadata about a container http://my.store/.well-known/meta/path/to/.meta, and
  • metadata about the resource http://my.store/.well-known/meta/path/to/resource.meta,
  • with http://my.store/.well-known/meta/path/to/ intuitively containing the metadata for resources contained in http://my.store/path/to/;
• a Well-Known Container for index representations http://my.store/.well-known/index/, containing
  • an index for the root http://my.store/.well-known/index/.index, and
  • an index for a container http://my.store/.well-known/index/path/to/resource.index,
  • with http://my.store/.well-known/index/path/to/ intuitively containing the index representations for resources contained in http://my.store/path/to/;

[elf-pavlik]

Would it be semantically incorrect to say that a Solid storage contains it's Well-Known resources?

I don't think it is incorrect, I think Solid Protocol shouldn't force /.well-known/ to be managed as contained in the storage and conforming to the Solid Protocol.

What would 'moving a resource' entail?

Moving a resource from one container to another. If containment is only tracked in the description one could easily go

• from ex:A ldp:contains ex:Y
• to ex:B ldp:contains ex:Y

With hierarchical paths, once one organizes ex:A/Y it is forever stuck inside of ex:A/ and can't be simply moved to ex:B/ preventing pretty common sense re-organizing of hierarchies.

[woutermont]

Great points! Thanks for clarifying 👍

[woutermont]

@elf-pavlik, I want to come back on those two last points you made.

---

I think Solid Protocol shouldn't force /.well-known/ to be managed as contained in the storage and conforming to the Solid Protocol.

I don't agree that the 1-1 correspondence forces that: we can still decide to host the Solid server on a non-empty path of the domain, e.g. /pods; that way, the Solid resources are contained in the server according to the protocol's 1-1 correspondance, while the Well-Known resources are not.

---

[We need a hierarchical resource to be able to have a non-hierarchical URL] [when] we want the ability to move the resource in the hierarchy without changing its URL, [i.e.] [move] a resource from one container to another. If containment is only tracked in the description one could easily go from ex:A ldp:contains ex:Y to ex:B ldp:contains ex:Y. With hierarchical paths, once one organizes ex:A/Y it is forever stuck inside of ex:A/ and can't be simply moved to ex:B/, preventing pretty common sense re-organizing of hierarchies.

I wonder how you would go about doing that even without the 1-1 correspondence...

• How would you add a containment relation without POSTing or PUTing a resource to a container?
• How would one remove a containment relation without deleting the resource (and thus the URI)?

[woutermont]

Given the long history of this decision, the clear advantages, and few disadvantages, I believe we should really move this forward and close the issue, possibly creating new issues regarding the few issues we listed.

[elf-pavlik]

I believe we should really move this forward and close the issue, possibly creating new issues regarding the few issues we listed.

I think we should at least address the specific case of auxiliary resources. Currently, some implementations just add .acl or .meta suffix to the resource IRI. If URI semantics is sufficient that would mean that auxiliary resources are contained in the same container as the resource they are auxiliary of. I believe no one would want auxiliary resources to be related to the container of the resource with ldp:contains. I think we have two possible approaches here:

• Have separate containers for auxiliary resources which would ldp:contains those auxiliary resources but not have them mixed in the container with regular resources
• Have URI semantics only necessary but not sufficient to determine containment. This way auxiliary resources could be on the same path as the resource (a common practice) without implying that they are contained (ldp:contains) in the container.

---

I wonder how you would go about doing that even without the 1-1 correspondence...

• How would you add a containment relation without POSTing or PUTing a resource to a container?

I think POSTing to the container should be possible if the storage uses a flat IRI template /{uuid} it would just create the resource and add ldp:contains to the container description (keeping in mind possible resolutions of #525)

When it comes to PUTing new resources, the resource would not be PUT to the container but to the Storage, again it could advertise an IRI template like /{uuid} or have it defined for the storage type #377
There would need to be a dedicated way to express the intended parent container for the new resource. I think Link header on the request could take care of it.

• How would one remove a containment relation without deleting the resource (and thus the URI)?

I would like to evaluate LINK and UNLINK HTTP methods https://datatracker.ietf.org/doc/html/draft-snell-link-method-12#section-6

Example 5: Add an existing resource to a collection:

LINK /some-collection-resource HTTP/1.1
Host: example.org
Link: http://example.com/my-member-resource; rel="item"

Thinking further I think we should look at solid/data-interoperability-panel#174 and evaluate LDP Direct Containers and Indirect Containers to see if they can be used or adapted for SAI inherited access. Noting the similarity of st:viaPredicate (shapetrees/specification#66) and ldp:hasMemberRelation and some benefits of having it server managed like ldp:contains.

I agree that the broader discussion about URI semantics being necessary is better to be addressed outside of this issue. For this issue, we probably should assume it is necessary and only address the question of it being sufficient.

[damooo]

@elf-pavlik: I agree that the broader discussion about URI semantics being necessary is better to be addressed outside of this issue. For this issue, we probably should assume it is necessary and only address the question of it being sufficient.

Indeed. I agree confirming-to uri semantics as a necessary constrain, when there already exists a containment relation, is granted and agreed. It gives better affordances on web with proper relative uri support, matching with semantics.

The question is not about imposing that constrain on periphary. But about assuming/deducing a containment relation, just because uris of two resources are in accordance with slash semantics. For uris alone are not sufficient to deduce that.

The case is not limited to current practice of aux uris in CSS and NSS. But also any other. For example, one of the uri has no corresponding resource existing at all. Then there is obviously no containment relation with non existing resource. So we cannot deduce such thing as mentioned in OP.

For to authoritatively deduce containment relation between R1 and R2 is

• R1 must exists.
• R2 must exists.
• R1 must be container.
• R1's representation must contain <R1> ldp:contains <R2>. triple.

Those all of above rules must be satisfied, along with added uri-semantics constrain.

uri slash semantics are just a constrain to uphold.

[woutermont]

I would like to evaluate LINK and UNLINK HTTP methods

👀 looking that up ...

I think we should at least address the specific case of auxiliary resources.

Fully agree, the current practice is the most painful contrast with the correspondence our forward by the protocol.

As I commented earlier, I believe having Well-Known paths for auxiliary resources is the way to go. I really think it is a minor loss of current practice, compared to not following the URI generic syntax, and losing the intuitive, offline processable, unix-like hierarchical notion of paths. Moreover, going with separately contained auxiliary resources means only changing a little server code to actually conform with a long-standing piece of the protocol; letting go of the sufficiency means changing all existing client code that relies on that long-standing piece of the protocol.

uri slash semantics are just a constrain to uphold.

Yes, but they are a constraint held up by practically the entire web.

[damooo]

@woutermont , I think you are missing the point. No where in spec says it's sufficient. For they are not, and cannot be sufficient. It's not opinion.

For, say two uris are given to you, a/b/ and a/b/c, then one cannot say there is a containment relation exists, until one dereference those resources and check existence, 'type' and links of the resources, first. If resource with uri a/b/c doesn't exist at all, can it be child of any? uri-semantics are one-of-many necessary conditions. Not sufficient alone.

[elf-pavlik]

letting go of the sufficiency means changing all existing client code that relies on that long-standing piece of the protocol.

Could you please provide a few examples of what exactly implementations would have to change?

[woutermont]

@damooo, I did not misunderstand. As I pointed out in my very first comment, the Solid protocol does state that "[t]here is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy."

[damooo]

[t]here is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy."

That expresses necessary condition for uri semantics. That is, at any time, the resources existing in a solid storage space must necessarily satisfy the 1-1 correspondence between containment triples, and their path hierarchy.

• If a resource doesn't yet exist in a storage space, we cannot deduce containment. For it doesn't exist, and thus not a member of any. If one deduce such a relation, then it is evidently not true.
• If a resource a/b/ is a solid container, and there exists a resource a/b/c that doesn't belong to storage space at all, and not a solid resource(does n't send ldp:Resource type link on deref), and no triple exists in a/b/, then there is no containment. That resource is independent, and never linked anywhere as solid resource or child of something.

By just seeing two uris one cannot deduce any semantic relation, for one cannot be sure if they exist at all, or if any of them advertise their conformance to a protocol, etc.

[damooo]

[t]here is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy."

Also plz note that, it talks as containment-triples as matter of fact. That is, it is a post-constraint on proven containment. Not a tool to deduce containment, for that doesn't work as stated in prev comment.

[woutermont]

[t]here is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy."

That expresses necessary condition for uri semantics. That is, at any time, the resources existing in a solid storage space must necessarily satisfy the 1-1 correspondence between containment triples, and their path hierarchy.

I'm sorry, but that is simply not correct. Any logician will be able to tell you. A 1-1 correspondence is both a necessary and a sufficient relation, meaning

• for every containment triple, there is a slash, AND
• for every slash there is a containment triple.

If a resource doesn't yet exist in a storage space, we cannot deduce containment. For it doesn't exist, and thus not a member of any. If one deduce such a relation, then it is evidently not true.

Of course not, I agree: if a resource does not exist, the deduction would be incorrect. But applications don't get URIs from nothing: they start at a resource they know exists, and follow their nose from there.

If this is your main point, I concede that we might add a 'only if the resource exists' clause to the paragraph on the 1-1 correspondence.

If a resource a/b/ is a solid container, and there exists a resource a/b/c that doesn't belong to storage space at all, and not a solid resource(does n't send ldp:Resource type link on deref), and no triple exists in a/b/, then there is no containment. That resource is independent, and never linked anywhere as solid resource or child of something.

This example, if it would occur, is simply not conformant with the spec (neither with Solid, nor with LDP or URI generic syntax). The 1-1 correspondence means that if a/b/ is a solid container, a/b/c (if it exists) must be a a solid resource contained in that container. Since the resource URI is under the authority of a Solid server, it should follow the Solid protocol, and thus have the correct containment triples ans send the correct Link headers.

[damooo]

I'm sorry, but that is simply not correct. Any logician will be able to tell you. A 1-1 correspondence is both a necessary and a sufficient relation, meaning

That's on;y true if domain is total. The domain of the spec statement is resources existing in a solid storage space as i specified in my comment. Whereas that domain not equal to set of all resources.

Of course not, I agree: if a resource does not exist, the deduction would be incorrect. But applications don't get URIs from nothing:

Doesn't matter where they get a value of the domain from, a proposition must hold if it is true.

they start at a resource they know exists, and follow their nose from there.

When they followed their nose, that implies they have another necessary implicit param about existence and linkage for deduction which makes the deduction true. That means uri-semantics alone were not sufficient. If they were, then a random conformant string generator alone should have been sufficient.

This example, if it would occur, is simply not conformant with the spec (neither with Solid, nor with LDP or URI generic syntax).

That's simply incorrect. LDP doesn't force any semantics to uri. For any resource we include Link header with type = ldp:Resource to explicitly opt-in at resource level for ldp interaction model over individual resource. Same with solid. Until that link is present in it's headers, it is not considered a ldp/solid resource. And a server is well within it's right to serve both solid resources and non-solid resources.

A client must follow stated interaction model, and follow their nose, without arbitrary assumptions and deductions from resource names.

[woutermont]

As I already said, we are not disagreeing on the implicit premise of existence of the resource.

I merely claim that applications (at least those following the RESTful Way) always make good on that premise.

But if you think this implicature is dangerous, we could definitely make the premise explicit in the spec.

---

Aside, what I do not agree on, however, is your claim about LDP. LDP conforms to URI Generic Syntax, which conforms to slash semantics. Not as strong of a slash semantics as Solid (just generic hierarchy instead of LDP Containment), but still semantics that allow us to deduce hierarchy based on slashes.

[woutermont]

I must say I do like your thoroughness, @damooo.

Thinking a bit further on LDP/URI vs Solid slash semantics, I do think, however, that there is even no difference at all. The Containment relation that LDP defines is so utterly generic, that it is i.m.o. not less broad than the generic 'hierarchy' the URI Generic Syntax hangs on the slash. Therefore, the correspondence Solid makes explicit is i.m.o. one that is already implicit in LDP.

Fact remains, of course, that in none of those specs, the assumption that the contained resource must exist to deduce the hierarchy/containment is made explicit. So I'm all in favour of adding that at least to our Solid spec. 👍

[damooo]

URI generic syntax, doesn't say a thing about relations between the resources. The spec is only about string content of the uri, and how to encode different uri components in that string. Nothing about resources.

When it deals with dot segments, it essentially talks about hierarchical tree of names in it's own words not hierarchical tree of resources. That is to define convention to resolve dot segments in hierarchical names.

Aside from that, in it's words:

  This specification does not limit the scope of what might be a

  resource; rather, the term "resource" is used in a general sense
  for whatever might be identified by a URI.  Familiar examples
  include an electronic document, an image, a source of information
  with a consistent purpose (e.g., "today's weather report for Los
  Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a
  collection of other resources.  A resource is not necessarily
  accessible via the Internet; e.g., human beings, corporations, and
  bound books in a library can also be resources.  Likewise,
  abstract concepts can be resources,

If a resource identifies a real world entity, what hierarchical relation one infer?

Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax.

[woutermont]

URI generic syntax, doesn't say a thing about relations between the resources. The spec is only about string content of the uri, and how to encode different uri components in that string. Nothing about resources.

I quote: "The generic syntax uses the slash ("/"), question mark ("?"), and number sign ("#") characters to delimit components that are significant to the generic parser's hierarchical interpretation of an identifier. [...] This uniform representation of hierarchy across naming schemes allows scheme-independent references to be made relative to that hierarchy.

Since URI's represent resources, I interpret this as the hierarchy being about resources.

If a resource identifies a real world entity, what hierarchical relation one infer?

The kind of hierarchy is not the question, only the fact that there is one. That is exactly the difference between LDP Containment (there is hierarchy) and LDP Membership (what are the semantics of that hierarchy).

---

But we're not being constructive here. This kind of interpretation game was exactly what I was hoping to avoid by instead listing use cases for each of the constraints.

Even more, as I said in one of my first comments: I would personally also be in favor of dropping the explicit mention of slash semantics! I believed it to be nothing more than @timbl's pet-peeve. But I've grown to appreciate the value of it [1]; and it has been in the spec so long (and definitely in the necessary AND implicitly sufficient version; that is very clear from the issue from back then).

[1] I think what triggerd my change of mind was the realisation that we can do literally everything WITH the slash semantics that we can do without (non-hierarchical resources can stick with slash-less URIs), and get advantages as well: we gain strong two-way deduction that we even can perform offline.

I think the question then remains: do we really want to break this all open again, with only things to lose, and none to gain?