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

----

Received on Friday, 25 April 2014 22:28:03 UTC