W3C home > Mailing lists > Public > public-ldp@w3.org > March 2014

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

From: <henry.story@bblfish.net>
Date: Wed, 26 Mar 2014 02:17:35 +0100
Cc: "public-ldp@w3.org" <public-ldp@w3.org>
Message-Id: <35021751-0A8E-4014-9B44-014123F81392@bblfish.net>
To: Reto Gmür <reto@apache.org>

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.

> 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:
> 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 

public Response postResourceDescription(String rdfstring, Headers headers);

> 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. It is clear that the usage of relative URIs is correct here and in the spirit of the web. 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. 

> Cheers,
> Reto
> 1. http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0077.html

Social Web Architect

Received on Wednesday, 26 March 2014 01:18:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:16:37 UTC