Re: A modest attempt to re-open ISSUE-20

On 13 Mar 2013, at 08:10, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr> wrote:

> Henry,
> 
> On Wed, Mar 13, 2013 at 2:15 AM, Henry Story <henry.story@bblfish.net> wrote:
> On 12 Mar 2013, at 18:41, Henry Story <henry.story@bblfish.net> wrote:
> 
>> 
>> On 12 Mar 2013, at 17:25, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr> wrote:
>> 
>>> Hi all,
>>> 
>>> I have a serious concern regarding the resolution of ISSUE-20, and the spefication of POST for LDPCs.
>>> 
>>> I know that the group already discussed that, that TimBL advocated this solution, and that in general it would be counter-productive for the WG to come back to resolved issues over and over again.
>>> 
>>> However, I feel that a major argument has been neglected, so I decided to raise it anyway, and to propose an alternative. If a majority of people in the group thinks that my argument and my alternative are not good enough, then I will forever remain silent -- on that topic, at least :)
>>> 
>>> 
>>> ARGUMENT:
>>> 
>>> First, recall that RDF has two levels of syntax: the abstract syntax (a.k.a. graph model), and several concrete syntaxes (a.k.a serialization syntaxes, e.g. Turtle, RDF/XML, N-Triple...). What matters in RDF, IMHO, is the abstract syntax,
> 
> The abstract syntax  specificiation allows for relative URLs:
> http://www.w3.org/TR/rdf11-concepts/#rdf-documents
> 
> This section is about serialization; it explicitly says "concrete syntaxes".
> On the other hand, the definition of IRI for the graph model
> 
>   http://www.w3.org/TR/rdf11-concepts/#dfn-iri
> 
> explicitly says "IRIs in the RDF abstract syntax MUST be absolute".
> 
> 
> 
>>> because it is what RDF semantics is based on. LDP itself requires one particular syntax (for obvious interoperability reasons) but allows alternative one, and the behaviours described in the spec depend on the graphs, not on the way those graphs are encoded.
> 
> Turtle, RDF/XML and the abstract syntax all allow for relative URLs.
> 
> Not the abstract syntax (see above).
> And for the record, not all concrete syntaxes do either, see N-Triples:
> 
>   http://www.w3.org/TR/rdf-testcases/#ntriples
> 
> But granted, this is a very special case... so we should probably not focus too much on it.
>  
> The graphs that one can construct from them do not contain triples with relative URLs. So it is not because your syntax contains relative URLs that the graph you build from it does.
> 
> Yes, only "if a base IRI can be established" (see http://www.w3.org/TR/rdf11-concepts/#note-iris ).
> 
> The core of my problem is that, while the server can establish this base IRI, the client can not.
> So the current LDP spec asks the client to serialize a graph that it can not know completely.

This seems like a very theoretical problem. I have not had trouble implementing it, and there are a number of very plausible ways of explaining what is happening here that we discussed in the original thread that lead to the decision to allow this into the spec.

> 
> 
>>> 
>>> Now, Section 5.4.8 [1] specifies how to interpret the null relative URI in the content POSTed to an LPDC. What bothers me is that the notion of relative URI does not exist in the abstract syntax: URIs in an RDF graph are always absolute [2]. It is only concrete syntax that can use relative URIs, that will be absolutized at parsing.
>>> 
>>> Now, if I want to write a software POSTing data to an LDPC, I can not work at the graph level, as I don't know the absolute URI of the resource to be created. Section 5.4.8 hence forces me to work at the serialization level, which I think is a bad thing. Many people prefer to use a library working  at the graph level, and let it handle the serialization and parsing phases.
>>> 
>>> I know that some RDF libraries allow to create a URI node with a relative URI in it, but this is IMO a bug, and not a feature. It means that the graph is not anymore an RDF-graph complying with the RDF recommendation, so its behaviour is implementation dependant. Especially, what happens if you try to serialize it into N-Triple (which does not support relative URIs)? So really, section 5.4.8 forces me to do the serialization by hand -- or to rely on non-standard extensions of a particular RDF implementation.
>>> 
>>> To take an analogy, imagine an XML-based web API telling me that "the value of this attribute must be enclosed in single quotes and not double quotes". If I'm using a DOM library rather than serializing my XML by hand, this is something I can not do -- and should not be required to do.
>>> 
>>> [1] http://www.w3.org/TR/2013/WD-ldp-20130307/#ldpc-5_4_8
>>> [2] http://www.w3.org/TR/rdf-concepts/#dfn-URI-reference
>>> 
>>> 
>>> ALTERNATIVE:
>>> 
>>> I propose the following alternative (which is, modulo the LDP terminology, how I have implemented it in my own application):
>>> * the content of a POST query to an LDPC must be parsed with the URI of the LDPC as the base URI;
>>> * in the POSTed graph, the LDPR to create is represented by a blank node, linked to the LDPC by membershipProperty of the LDPC.
>> 
>> -1
>> 
>> Awful.
> 
> 
> Why?

Sorry, I had read your proposal yesterday too quickly. I was meant to travel back to Paris from
Amsterdam but the snow storm in Paris lead to the cancelling of all the trains there...

> 
>>> 
>>> For example, if I want to post a new bond to a NetWorth service, I can POST the following Turtle:
>>> 
>>>   <> rdfs:member [
>>>     a o:Bond ;
>>>     o:value 20000 ;
>>>   ].
>>> 
> 
> Would this 2nd alternative seem less awful?
> 
> * in the POSTed graph, the LDPR to create is represented by a blank node, with type ldp:New. Example:
> 
>   [ a ldp:New, o:Bond ;
>     o:value 20000 ;
>   ].


1)  What happens if someone POSTS a graph with more than one rdfs:member ?

  <> rdfs:member [ ... ], [ ... ] .

Does this create more than one resource? How does one find out about the resource's names?

2)  We then would need to understand the functioning of the "Location:" header returned by the created document. (§5.4.1) If more than one resource gets created what would that mean? How would one know what the URLs of the created resources are?

3) Your solution forces the server to make all naming decisions. For example it is now impossible to POST a foaf profile and for the client to specify that the agent URI is going to be <#me> or <#i> . In fact one can no longer use #URIs at all, because they can only be interpreted relative to the LDPC that one is POSTing to. Therefore your graph now can only be composed of bnodes! You then need your server to make decisions about which bnodes to name and which not to name. But then it has to be conscious of subtle things like OWL where bnodes for owl:Restrictions are in fact important! 

I hope that helps.

> 
> It does not rely on the LDPC being mentionned in the graph, which I'm assuming makes my first proposal look odd.
> On the other hand, it makes you insert a triple  ( [] a ldp:New ) that will obviously not be recorded by the server, which has some awfulness to it as well.
> 
> However, it can work for me, as I can easily built this graph on the client side. Also, it allows the same variants as my first alternative.
> 
>  best
> 
>   pa
>  
>>> Note that I, whenever I typed this by hand, I use a null relative URI (for the LDPC) which makes things more readable; you can read that URI as "you" or "here", and that makes sense.
>>> But I can also create this graph programmatically without caring about the serialization at all.
>>> 
>>> Note also this approach allows interesting variants (that may b
>>> 
>>> 1/ it is easy to create several resources in a single POST query :
>>> 
>>>   <> rdfs:member [
>>>     a o:Bond ;
>>>     o:value 20000 ;
>>>   ], [
>>>     a o:Stock ;
>>>     o:value 10000 ;
>>>   ].
>>> 
>>> 2/ if the client wants to specify the URI of the created resource, they can replace the blank node by a URI, and POST it that way
>>> 
>>>   <> rdfs:member <my-favourite-bond> .
>>>   <my-favourite-bond> a o:Bond ; o:value 20000 .
>>> 
>>> but the server is free to refuse it (if the URI is already in use, or does not follow its naming policy).
>>> 
>>> 
>>> Those variants are probably too complex to require them (MUST) of every LDP server, but I would propose that 1/ be a SHOULD and 2/ be a MAY.
>>> 
>>> 
>>> that's all, sorry for the long e-mail, but I think that's an important issue
>>> 
>>>   pa
>>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Social Web Architect
http://bblfish.net/