Re: Comments on LDP spec (http://www.w3.org/TR/2014/WD-ldp-20140311/) ( LC-2926 LC-2927 LC-2928 LC-2929 LC-2930 LC-2931 LC-2932 LC-2933 LC-2935 LC-2934 LC-2936)

Sounds good. Thanks for the detailed response to all comments.

Joe

==================================
IBM Cloud & Smarter Infrastructure
Jazz for Service Management
joeross@us.ibm.com




From:	Arnaud Le Hors/Cupertino/IBM@IBMUS
To:	Joe Ross/Austin/IBM@IBMUS,
Cc:	public-ldp-comments@w3.org
Date:	05/09/2014 02:55 PM
Subject:	Re: Comments on LDP spec
            (http://www.w3.org/TR/2014/WD-ldp-20140311/) ( LC-2926 LC-2927
            LC-2928 LC-2929 LC-2930 LC-2931 LC-2932 LC-2933 LC-2935 LC-2934
            LC-2936)



 Dear Joe Ross ,

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.

Please review it carefully and let us know by email at
public-ldp-comments@w3.org if you agree with it or not before 14 May 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/OF5CE66CF6.126EF9DF-ON86257CBE.005507EF-86257CBE.0055101E@us.ibm.com

 2. http://www.w3.org/TR/2014/WD-ldp-20140311/


=====

Your comment on 4.2.1.4 LDP servers exposing LDPRs MUST advertise their
LDP...:
> Since an LDPR can be an LDP-NR, and the header must be included
> responses to HTTP requests for all LDPRs, the following statement seems
> incorrect:
> "The presence of this header asserts that the server complies with the
> LDP specification's constraints on HTTP interactions with LDPRs, that is
> it asserts that the resource has Etags, has an RDF representation, and
> so on, which is not true of all Web resources served as RDF media
> types."


Working Group Resolution (LC-2926):
Agreed.

----

Your comment on 4.2.1.6 LDP servers MUST publish any constraints on LDP
cli...:
> An example would be  useful here...


Working Group Resolution (LC-2927):
Agreed.

----

Your comment on 4.2.4.3 If an otherwise valid HTTP PUT request is
received...:
> Server-managed properties are non-modifiable, and these can be
> ignored, so this seems to contradict 4.2.4.1.  Perhaps this needs to be
> qualified to exclude ignored server-managed properties.


Working Group Resolution (LC-2928):
Agreed that it might seem to conflict but the following note clarifies the
intent:

Non-normative note: Clients might provide properties equivalent to those
already in the resource's state, e.g. as part of a GET/update
representation/PUT sequence, and those PUT requests are intended to work as
long as the server-controlled properties are identical on the GET response
and the subsequent PUT request.

----

Your comment on 4.2.4.4 If an otherwise valid HTTP PUT request is
received...:
> Does the PUT succeed in performing an update in this case? Should all
> requests with 4xx responses be assumed as having failed? Seems that it
> would be more consistent if info was returned using describedBy link
> header as mentioned previously for constraint violations.


Working Group Resolution (LC-2929):
Correct. A 4xx response does mean that the request has failed and it is
then subject to the requirement to have a describedby link.

----

Your comment on 4.3.1.3 The representation of an LDP-RS MAY have an
rdf:typ...:
> I don't understand this statement.  "... MAY have an rdf:type of
> only one of ldp:RDFSource ..." . Seems there is something wrong with
> this sentence.


Working Group Resolution (LC-2930):
This sentence was changed to the following:
The representation of a LDP-RS MAY have an rdf:type of ldp:RDFSource for
Linked Data Platform RDF Source.

----

Your comment on 4.3.1.14 LDP clients SHOULD be capable of processing
succes...:
> This seems like a good statement to make, and it should not be at
> risk.


Working Group Resolution (LC-2931):
It is the intent of the WG to incorporate this into the spec eventually but
the final decision will be made at the end of CR. This feedback will be
taken into account then.


----

Your comment on 4.3.2.1 LDP servers MUST provide a text/turtle
representation of the requested LDP-RS [turtle].:
> Shouldn't this say something like "... MUST provide a text/turtle
> representation of the requested LDP-RS, unless otherwise specified via
> the Accept Header"?


Working Group Resolution (LC-2932):
This is a requirement for servers to offer Turtle and in no way is meant to
say that content negotiation does not apply.
Hopefully, the addition about JSON-LD makes this more obvious:
LDP servers SHOULD provide a application/ld+json representation of the
requested LDP-RS [JSON-LD].


----

Your comment on 5.2.3.2 When a successful HTTP POST request to an LDPC
resu...:
> It appears that there is no requirement that ldp:contains be
> included in responses to GET requests, which is good, since in our case
> that would result in doubling the size of the container resource, and
> doesn't provide any useful information to clients.


Working Group Resolution (LC-2933):
This is indeed why the WG added the possibility for clients to express a
preference using the Prefer header.


----

Your comment on 5.2.8 HTTP OPTIONS:
> This doesn't seem to have anything to do with HTTP OPTIONS. Why is
> it a subsection under HTTP OPTIONS?


Working Group Resolution (LC-2935):
This paragraph is there because it is a requirement for responding to
options requests. We could add "when responding to OPTIONS requests on the
LDP-NR's request-URI" or similar, but the OPTIONS part of that is really
covered by the preceding paragraph.


----

Your comment on 5.2.8.1 When an LDPC server creates an LDP-NR (for
example,...:
> There is an indication of additional HTTP OPTIONS requirements for
> LDPC,
> but none seem to be described.


Working Group Resolution (LC-2934):
The additional requirement to HTTP is merely to support OPTIONS. This is
true on all LDPRs.

----

Your comment on 7.2 Preferences on the Prefer Request Header:
> Prefer header and return=representation
> I assume that the default representation could omit the containment
> triples, unless they are explicitly requested using Prefer header. That
> would avoid having to double the size of LDPC representations for legacy
> clients.
> There is a statement below example 11 that seems to say this: "A server
> that honors this hint would return (at least) the following response,
> and perhaps only this (it might well omit containment triples if they
> are not specifically requested)".


Working Group Resolution (LC-2936):
This is correct.


----