- From: <lehors@us.ibm.com>
- Date: Fri, 09 May 2014 19:55:42 +0000
- To: Joe Ross <joeross@us.ibm.com>
- Cc: public-ldp-comments@w3.org
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. ----
Received on Friday, 9 May 2014 19:55:43 UTC