Re: Practical issues arising from the "null relative URIs"-hack

On 26 Mar 2014, at 10:29, Reto Gmür <reto@apache.org> wrote:

> 
> On Wed, Mar 26, 2014 at 2:17 AM, henry.story@bblfish.net <henry.story@bblfish.net> wrote:
> 
> On 25 Mar 2014, at 15:28, Reto Gmür <reto@apache.org> wrote:
> 
>> Hi,
>> 
>> 
>> More than one year has passed since Pierre-Antoine Champin explained why specifying LDP using the concept of "null relative URI" is problematic [1]. Unfortunately the concept of "null relative URI" is still in the latest version of the spec. This ties the LDP spec to some RDF serializations
>> and probably violates RFC3986 according to which the *sender* is responsible for making sure that a base URI for the relative references can be established.
> 
> You are probably refering to:
> 
> [[
> 5.1.4.  Default Base URI
> 
>    If none of the conditions described above apply, then the base URI is
>    defined by the context of the application.  As this definition is
>    necessarily application-dependent, failing to define a base URI by
>    using one of the other methods may result in the same content being
>    interpreted differently by different types of applications.
> 
>    A sender of a representation containing relative references is
>    responsible for ensuring that a base URI for those references can be
>    established.  Aside from fragment-only references, relative
>    references can only be used reliably in situations where the base URI
>    is well defined.
> ]]
> The key part is: "then the base URI is defined by the context of the application."
> The context here is the LDPC, and it clearly defines how to resolve the URI.
> 
> So in which context does the sentence
> 
> A sender of a representation containing relative references is responsible for ensuring that a base URI for those references can be established.
> 
> Makes any difference according to you? 

yes. IT is quite clear:
  - when a client POSTs a Representation of an RDF graph to an LDPC it knows that the LDPC will be able to establish a base uri for it
  - when a client does a PUT, the base URI is easy to establish - it is the URI of the PUT


> 
>> 
>> But the main point that LDP is no longer defined in terms of the abstract RDF syntax shows to be problematic when using higher level abstraction frameworks such as JAX-RS (the java standard for REST) to implement and LDP server or client.
>> 
>> A method that returns an RDF representation of a Resource would typically be defined like this:
>> 
>> @GET
>> public Graph getResourceDescription();
>> 
>> The JAX-RS runtime (more specifically so called MessageBodyWriters) will take care of serializing the returned graph into the format preferred by the client.
>> 
>> One would define a method that handles post requests with an RDF Graph as message body like this:
>> 
>> @POST
>> public Response postResourceDescritption(Graph graph);
>> 
>> Unfortunately this doesn't work to handle LDP POST requests as the message body cannot be converted to an RDF Graph until some application logic defined the URI for the new resource. All work around are quite horrible. One would be to have a type RelativeGraph to which text/turtle can be deserialized without a base URI, another one would be to take a String as argument and take care of the deserialization in the application code.
> 
> yes, you nailed the issue. You should not be transforming the data to a graph i, but receiving it as a string of chars ( or bytes with other data ) at that point. You would then be
> able to parse the graph with your newly minted base URI. So you should change your method signature to 
> 
> @POST
> public Response postResourceDescription(String rdfstring, Headers headers);
> 
> You realize you're forcing developers of clients and servers to operate at a much lower level of abstraction than if LDP would be designed in term of exchanging RDF?

You need to work at the appropriate level of abstraction.

I have implemented this, and so have others.

There are really a whole number of ways to get this done. 

>  
> 
> 
>> 
>> 
>> Pierre-Antoine original solution proposal included the usage of BNodes. As some people have strong feelings against BNodes this elegant approach might have been precociously discarded by some. 
>> 
>> A quick fix would be to simply define "null relative URI" (which is currently undefined both in LDP as well as in RFC 3986/3987) as http://www.w3.org/ns/ldp/null-relative/.
> 
> Both of those solutions are very much hacks.
> Mine is, Antoine's is not. In Antoine's relative URIs are optionally used to refer to a value known to the client. And BNodes are used exactly as per their semantics: to assert the existence of the resource without asserting their URIs.
>  
> It is clear that the usage of relative URIs is correct here and in the spirit of the web.
> Clearly not. If the RDF Data Model would support relative URIs then it would be an acceptable solution (Antoine's still being more elegant, imho). But as RDF has no relative URIs this is just an unnecessary hack.

The RDF data model is not defined in terms of relative URIs, but the syntaxes allow it.  We are passing RDF serialisations 
over the wire. And the ones we allow allow for relative URIs. Relative URIs are well defined, well known, and very useful.

> 
> Turtle is a textual syntax for RDF, according to the turtle spec: "A Turtle document serializes an RDF Graph". Here it is used as textual syntax for something that becomes RDF only when the base URI is added by the receiver.
 
When you GET a document with relative URIs it only becomes a graph after you deserialise it with the base uri. Same thing. It's just a question of who
sets the base uri. Since we are creating a document, it cannot be the client, but MUST be the server. You are surprised by this because no
protocol specified how to do this with POST before LDP.

> 
> The client cannot use a turtle serializer to create the request body. The client must generate the body by other means or modify the turtle created by a turtle serializer.

Jena, Sesame and most other serialisers I have seen allow you to take a graph, and serialise it to a relative graph, by specifying a base URL. 

> It is in the spirit of the web that resources can be represented in any format serializing the underlying data model. the "null relative URI"-hack breaks this principle.

If HTML is the most widely used format which defines the web, then I'd say that the fact that you can use relative URLs in HTML and that they would
work correctly in a POST on an LDPC shows that you are wrong. 

What you are discovering is the importance in pragmatics of indexicals - ie. relative URIs. 

>  
> I think you'll find that if you POST
> some html using this method to a server you'll get exactly the expected behavior. All <a href="">this</a> will refer to the document itself. 
> Things are quite different in HTML. In HTML the data model supports relative URIs. So we can create the above snipped using the DOM and serialize it to HTML or XHTML.

If I were to follow your argument above, I'd say the following: RDF can express the semantics of anything, so it must be possible for it to define the semantics of html too. Given that
an RDF model of HTML would not have relative URIs, it follows that the model of HTML cannot have relative URLs.  

But clearly that is wrong headed.

Relative URLs are indexicals that get their meaning from the context of utterance. So just as different people saying "I" , the "I" refers to different people
depending on who said what, so it does not follow that once you cannot replace the indexicals with determinate names to create sentences for which you
can do logical transformations without worrying about context. It is the function from syntax + context of utterance to model that gives you the model. Without
the context you cannot create the model. 


> 
> 
> Cheers,
> Reto
> 

Social Web Architect
http://bblfish.net/