- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Thu, 16 Dec 2010 10:46:46 +0000
- To: Chimezie Ogbuji <ogbujic@ccf.org>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
On 15/12/10 22:21, Chimezie Ogbuji wrote: > On 12/14/10 12:59 PM, "Andy Seaborne"<andy.seaborne@epimorphics.com> wrote: >>> * ISSUE-56 (PATCH HTTP/Update and SPARQL Update payload) [1] >>> >>> There is a comment explicitly asking that the specification is clearer on >>> the behavior of PATCH or at least if we intend for it to be normative. My >>> recommendation is to leave the behavior for PATCH as informative (given the >>> relative youth of the PATCH verb), however we should clarify the behavior. >>> In particular, SPARQL Update should be RECOMMENDED for use as a patch >>> document. A status code of 400 (Bad Request) should be RECOMMENDED as a >>> response to requests where the SPARQL Update request addresses a graph other >>> than the one targeted by the PATCH request, a 404 should be returned if the >>> graph addressed in the Update request is *not* the same graph identified in >>> the PATCH request, etc. So, the informative behavior would be to facilitate >>> the use of a subset of the SPARQL Update request (the subset that only >>> targets individual graphs) as a 'patch document' (with an appropriate media >>> type) to the extent that it matches the semantics of the HTTP request. >>> In particular, SPARQL Update ... >> >> I confess I don't quite understand this. The 400 and 404 text above >> seem to both talk about a graph other than the PATCH target. >> Could you give examples of the two cases? > > Sure. Thanks - the examples are very helpful. SPARQL Update (the language) is a language for manipulating graph stores. The protocol model is service-oriented. I'm not sure that adding an overlapping mechanism is helpful. *If* we wanted to use if for manipulating individual graphs, it would be better to define a subset that only applies to changes of one graph. I think this means excluding use of GRAPH in templates, WITH, and excluding the graph management operations. These are syntax restrictions that can be checked by a parser otherwise corner case arise that are only determinable by running the request: > > 1. A status code of 400 (Bad Request) should be RECOMMENDED as a > response to requests where the SPARQL Update request addresses a graph other > than the one targeted by the PATCH request > > PATCH /rdf-graphs/service/?graph=http%3A//www.example.org/other/graph > HTTP/1.1 > Host: example.org > WITH<http://www.example.org/graph/1> > INSERT { x y z } > DELETE { a b c } > WHERE { ... } > > This request should respond with a 400 since the graph indicated via WITH is > *not* http://www.example.org/other/graph > This could be seen as a request on the graph store with parameter "?graph=http%3A//www.example.org/other/graph". Viewed that way, any SPARQL Update request is valid. Other cases arise: WITH <http://www.example.org/graph/1> INSERT { GRAPH <http://www.example.org/other/graph> {x y z } } DELETE { <http://www.example.org/rdf-graphs/service/?graph=http%3A//www.example.org/other/graph> { a b c } } WHERE { ... } the WITH has no effect on the graph changed. Making a sub-language would be cleaner if we wanted to do it. or worse, this isn't deteminable without running the operation: INSERT { GRAPH ?g {x y z } } WHERE { ... } A profile of the language would avoid this. Andy
Received on Thursday, 16 December 2010 10:47:24 UTC