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

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.


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


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

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