- From: <henry.story@bblfish.net>
- Date: Wed, 26 Mar 2014 02:17:35 +0100
- To: Reto Gmür <reto@apache.org>
- Cc: "public-ldp@w3.org" <public-ldp@w3.org>
- Message-Id: <35021751-0A8E-4014-9B44-014123F81392@bblfish.net>
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: > > @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); > > > 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 http://bblfish.net/
Received on Wednesday, 26 March 2014 01:18:10 UTC