Re: ( LC-2915)

Dear Arnaus, WG,

Thank you for reviewing my comment.

I read in the minutes that the idea of defining relative graphs and also
using a specific media-type (application/ld) have been discussed: these two
ideas are way to make the current working of the spec more clean, that is
not claiming to be sending around RDF hwne in fact it is not.

Also the variant with some placeholder URI has been discussed. As I write
in [1] I consider this idea to be a hack, unlike Pierre-Antoine's original
proposal (referenced in my original comment).

While the practical consequences are discussed (temporary URI, burden on
the server) the fundamental issue that the LDP WG should combine RDF and a
RESTful API is not. The discussed possible response "LDP uses Turtle, which
support rel URIs" brings it to the point: the LDP spec is not based on RDF
but on Turtle.

Because of this I think the LDP WG did not accomplish its mission.

In my opinion this completely unnecessary. With Pierre-Antoine's proposal
there is a way to solve things in RDF not only solving the practical issues
(including the also discussed separate "../" issue) but also fulfilling the
mission of the charter.

Surprisingly this proposal was not explicitly discussed. Possibly the
following

Sandro Hawke: it's not a bnode, it's a node uri ←
>

is referring to that proposal.

I see no conflict with the semantics of bnodes: the client tells the server
"There is something which is a <member> of <foo> and which is of type
<Stock> and has a value of  '1000'", receiving this information the server
assigns a URI to the existentially quantified resource (i.e. "grounds" the
node).

So to summarize: Without any significant disadvantage the WG could base the
spec on RDF rather than on a concrete serialization or some Relative RDF
graph model. With this change the WG would fulfill its mission. This would
also solve some practical issues as well as potential problems and missuses
of relative URIs. The specific solution has been provided by Pierre-Antoine
Champin in March 2013.

Best regard,
Reto




1. http://lists.w3.org/Archives/Public/public-ldp/2014Mar/0026.html



On Tue, Apr 29, 2014 at 8:40 PM, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi,
> Beside the fact that something went wrong with the W3C Last Call tracker
> and that your name got butchered, I meant for the deadline to be May 5th
> rather than April 5th as stated in the below message. The same goes with
> LC-2914.
> We have a WG call next Monday and I'd like to have your response before
> that.
> Thanks.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>
>
>
>
> From:        Arnaud Le Hors/Cupertino/IBM@IBMUS
> To:        Reto Gmür <reto@apache.org>,
> Cc:        public-ldp-comments@w3.org
> Date:        04/25/2014 03:28 PM
> Subject:        Re:  ( LC-2915)
> ------------------------------
>
>
>
>  Dear Reto Gmür ,
>
>
> The Linked Data Platform (LDP) Working Group has reviewed the comments you
> sent [1] on the Last Call Working Draft [2] of the Linked Data Platform 1.0
> published on 11 Mar 2014. Thank you for having taken the time to review the
> document and to send us comments!
>
> The Working Group's response to your comment is included below, and has
> been implemented in the new version of the document available at:
> http://www.w3.org/2012/ldp/hg/ldp.html.
>
> Please review it carefully and let us know by email at
> public-ldp-comments@w3.org if you agree with it or not before 5 April
> 2014.
> In case of disagreement, you are requested to provide a specific solution
> for or a path to a consensus with the Working Group. If such a consensus
> cannot be achieved, you will be given the opportunity to raise a formal
> objection which will then be reviewed by the Director during the transition
> of this document to the next stage in the W3C Recommendation Track.
>
> Thanks,
>
> For the Linked Data Platform (LDP) Working Group,
> Eric Prud'hommeaux
> Yves Lafon
> W3C Staff Contacts
>
> 1.
>
> http://www.w3.org/mid/http://lists.w3.org/Archives/Public/public-ldp-comments/2014Mar/0001.html
> 2. http://www.w3.org/TR/2014/WD-ldp-20140311/
>
>
>
> =====
>
> Your comment on 5.2.3.7 In RDF representations, LDP servers MUST interpret
> the null relative URI for the subject of triples in the LDPR representation
> in the request entity body as referring to the entity in the request body.
> Commonly, that entity is the model for the “t:
>
> > 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.
> >
> > 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.
> >
> >
> > 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/.
> >
> >
> > Cheers,
> > Reto
> >
> >
> >
> > 1. http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0077.html
>
>
>
> Working Group Resolution (LC-2915):
> Although the WG understands your concerns, having weighed the pros and
> cons, the WG decided to stick with the current null-relative design, and
> add a non-normative explanation of how that works, how to do it in some
> tools, etc, in a footnote, appendix, or (hopefully) Best Practices and
> Guidelines document.
> See http://www.w3.org/2013/meeting/ldp/2014-04-15#resolution_1
>
> ----
>
>
>
>
>