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

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?

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


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

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.

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.

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.



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


Cheers,
Reto