A modest attempt to re-open ISSUE-20

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

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.

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

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