Enable full use of relative URLs in Solid

Solid Containers are based on LDP Basic Containers. Those make it difficult to use relative urls reliably when publishing a document. Indeed the only relative URLs that can reliably be used in a document POSTed to an ldp:BasicContainer is the "this document" <> relative URL. The same is true with the current Solid spec, as it inherits that definition.

A bit of history will help to understand how ldp got to this compromise. It was an uphill battle at the time to get relative URLs (expressed in Turtle with <>) to be accepted at all, as various members of the LDP Working Group (WG) claimed that RDF documents with relative URLs were not bona fide RDF document at all. It took a while to overcome that inhibition. (The main argument is that POSTing is a speech/document act). Having finally reached consensus on the use of <> to refer to the newly created document, members of the WG did not want to go further for fear of loosing what they had achieved.

Over 7 years have passed and I think everyone is quite happy now with relative URLs. Indeed the Solid spec show a desire to go further (as shown below). We can make publishing documents a lot easier by also allowing URLs to be published containing any relative URL even ones linking up the hierarchy with `<../>. For people publishing HTML documents this would allow them to edit files locally and to publish those as they appear on their file system, with as little transformation as possible needed. It would also make it easier to publish new formats without the server or client needing to parse documents to absolutize relative URLs.

This would easily be feasible by creating a new type of Container. In a proposal from 2012 I called these intuitive Containers iContainers. Of course nothing in this argument hangs on the name. Here is what I wrote in issue 50: Intuitive Containers: better support for relative URIs in 2012:

Currently when creating a resource by POSTing a Turtle document to a container one cannot use the following relative URIs in the POSTed content:

<.> to refer to the creating container
<sibling> to refer to a sibling of the content created
<../other> to refer to a child of the parent of this container
<sister/child> to refer to a child of a sister content created in this container

The reason one cannot use any of these URIs that are allowed by Turtle and allowed by the URI spec, is that one cannot know what the URL of the resource created by a container will be given the current definition of an LDPC. Will it have any relation at all to the container URL? Since we are in the process of creating resources, it will help a lot to know when we are dealing with containers that have those properties.

Given that we accepted "ISSUE-29: Relative URIs are crucial" we therefore need to define a Container class that makes this guarantee to the client. This can be a subclass of an LDPC or it could be a new requirement on an LDPC.

So how does this apply to the current Solid Spec? Currently in §2.4.1 Shared slash semantics it is written 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.

The problem with this is that this is not guaranteed by any of the ldp Containers. In order to allow this behavior to be explicit and so for there not to be clashes with existing ldp implementations from IBM, Oracle, OpenLink or others, which could lead to errors in publications, Solid needs to define a subclass of ldp:Container with the desired properties.

Furthermore there are very good use cases for the less precisely specified Containers as defined by ldp. So it would be a pitty to loose those capabilities whilst also creating difficult to debug confusion in the wider community.

Start with the Solid specification's §2.4.1 “Shared slash semantics” and compare it with the referenced LDP Basic Container definition and issue 50. Define the intended container subclass and its relative-URL guarantees, while preserving the existing less-specific container behavior; done means the specification makes these semantics explicit without ambiguity for clients and servers.