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

On Wed, Mar 26, 2014 at 12:23 PM, henry.story@bblfish.net <
henry.story@bblfish.net> wrote:

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

My question was when does the sentence that the sender is responsible (1)
makes any difference compared to the situation  in which the RFC would just
contain the previous paragraph stating that the base uri is defined in the
context of the application (2). I'm not denying that requirement 2 is met
but if 1 doesn't mean the same as 2 I don't see how 1 is met.


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

Working at higher level of abstraction has many advantages. For example in
JAX-RS one can add new MessageBodyReaders to support other RDF formats.
This is not possible if the resource method takes a String.

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

The introduction of the spec says it would use standard HTTP and RDF
technique. If standard technique would be used then any RDF serialization
could be used.

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

I don't think that creating the graph with a throwaway-URI and then rely on
the undocumented behavior of the serialzer not to include throwaway-URI in
the generated serialization when serializazing against this throwaway-URI
is a good design choice.

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

Wrong. If you describe an HTML DOM in RDF the relative URIs would be
modeled as literals (e.g. xsd:String) in RDF. Besides what would your
argument proof it it was correct? That RDF is broken and we must use turtle
instead?


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

It's interesting that your analogy only holds for the situation where the
sender or any observer of the communication could deference the indexicals,
which is not the case for the proposed "null relative URI"-hack.
Pierre-Antoine's proposal also uses indexicals:

  <> rdfs:member [
    a o:Bond ;
    o:value 20000 ;
  ].

But in this proposal the indexical is optional. The sender could use a URI
instead of the indexical. It translates to a "you": You [shall] have a
member, this member is a o:Bond with o:value 2000. The source of this
statement clearly knows who this "you" is and could also use the URI of the
LDPC instead.

You are confusing indexicals with existentially quantified variables, such
variables are supported in RDF with bnodes.

Reto