Re: Open issues in HTTP/Update protocol (for discussion)

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