- From: Sandro Hawke <sandro@w3.org>
- Date: Mon, 19 Dec 2011 21:00:00 -0500
- To: Chime Ogbuji <chimezie@gmail.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
On Mon, 2011-12-19 at 16:09 -0500, Chime Ogbuji wrote: > So, per our conversation in today's teleconference regarding the graph store protocol, below is suggested text that would go into section 5.5 (HTTP Post) of the editor's draft immediately after the second pair of HTTP message and SPARQL Update examples for the POST = append scenario and right before the paragraph beginning "As mentioned earlier..": > > "Note that this behavior is only sanctioned for HTTP POST requests where the request URI identifies RDF graph content. Implementations of this protocol can interpret HTTP POST requests to other kinds of information resources in a manner that still provides a uniform method to cover the functions indicated in [RFC2616] (section 9.5 POST) but that is more appropriate for the kind of resource being targeted" > > In addition, we also tentatively agreed to change the first sentence in that section from "A request that uses the HTTP POST method SHOULD [..]" to "A request that uses the HTTP POST method MUST [..]" > Sorry, but "where the request URI identifies RDF graph content" does not make it clear enough which resources this rule applies to. If I had a graphstore that implemented my strawman collections interface or Eric's strawman trouble ticket interface, I would feel on *very* weak ground (really, no ground) pointing to this text and saying "no, really, I'm not violating the spec". The definition in this spec of "RDF graph content" is: An information resource identified by the graph IRI of a named graph and managed by a server that implements this protocol or identified by an indirect operation on the default graph. and I think that's what I'd have in my collections interface. In my strawman, everything looks just a "normal" graphstore, except some of the "graphs" are collections, and you can POST to them to make new resources in those collections (as per typical REST behavior). I'm not okay with this spec ruling out such systems. So, here's a minimal change that handles that: Note that this behavior is only sanctioned for HTTP POST requests where the request URI identifies only RDF graph content, with no special semantics or behavior. Implementations of this protocol MAY interpret HTTP POST requests to other kinds of information resources in a manner that still provides a uniform method to cover the functions indicated in [RFC2616] (section 9.5 POST) but that is more appropriate for the kind of resource being targeted. Given that we still haven't even talked about my other points, or closed the loop with Arnaud, I'm thinking we should keep working on this document, and not try to make the Last Call decision tomorrow. -- Sandro
Received on Tuesday, 20 December 2011 02:00:11 UTC