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

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.

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

Another example that also returns 400 (but for a different reason - multiple
graphs are modified) is:

PATCH /rdf-graphs/service/?graph=http%3A//www.example.org/graph/1 HTTP/1.1
Host: example.org
INSERT { 
  GRAPH <http://www.example.org/graph/1> { x y z }
} 
DELETE { 
  GRAPH <http://www.example.org/graph/2> { a b c }
} USING <http://www.example.org/graph/1> WHERE { ... }



2. A 404 should be returned if the graph addressed in the Update request is
*not* the same graph identified in the PATCH request, etc [sic].

That should have read 'A 404 should be returned if the corresponding graph
addressed in the update request is not in the graph store'.  However, in
retrospect, extra text is not necessary since this is a general rule already
described.  An example is

PATCH /graph/1 HTTP/1.1
Host: www.example.org
WITH <http:///www.example.org/graph/1>
INSERT { x y z } 
DELETE { a b c } 
WHERE { ... }

Where there is not graph with URI <http:///www.example.org/graph/1> in the
graph store. 

> I don't think a SPARQL Update request ever addresses a graph - it's the
> graph store, right?

The PATCH semantics in this section is sanctioning an interpretation that
the request URI determines which graph is being targeted for modification by
the SPARQL Update payload.  So, a 400 is returned in the first example since
a modification of a different GRAPH or more than one graph breaks the
intuition that "REST uses a resource identifier to identify the particular
resource involved in an interaction between components."

In order to ensure this 'RESTful' behavior, it is effectively only allowing
the subset of the SPARQL Update language that manages a single graph for use
as a patch document.

> GET returns meta data about teh graph store, (303?)

Later in that email, my suggestion is that a GET on the graph store returns
405 (Method Not Allowed), since it is not clear what should be returned in
this case.  What would be the format of this metadata? Would it be an
arbitrary RDF graph that describes the store and how is this different from
the service description document that is returned from a GET request on the
service?
 
> But a change to a graph store by changing one of it's graphs is simply
> changing part of a resource which is what PATCH is about.

Yes.  A PATCH request via the HTTP Update protocol changes part of the
resource identified by the request URI (or embedded within using ?graph).
 
> RFC 5789 referrs to 404 for a non-existent resource in sec 2.2.

Yes, see my correction above.
> 
> 400 is badly formatted document (aka parse error), not about targetting.

The interpretation here is that a PATCH document used in this protocol which
doesn't modify a single graph or the graph it modifies is not the one
indicated in the request URI is not "not properly formatted" in the sense
that it is not using the restricted form of SPARQL Update that can be used
in a 'RESTful' manner.  A response of 422 (Unprocessable Entity) is probably
more appropriate since it is a case where "the server understands the patch
document and the syntax of the patch document appears to be valid, but the
server is incapable of processing the request."

 
> What am I missing here?

I hope my clarifications help.

> PATCH is part of HTTP and can be used where appropriate according to the
> PATCH spec - we don't need to do anything but informative text would be
> helpful. Informative text does not have "RECOMMENDED" in it.

Without recommending reasonable use it is not clear how PATCH can be used
with SPARQL Update, which is the point made by Rob Vesse in his comment [1]
 
> For SPARQL HTTP Update, PATCH only applies to append of triples like POST?

No, it can remove triples as well (as long as the modification is made
within a single graph)

[1] 
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Oct/0060.ht
ml


===================================

P Please consider the environment before printing this e-mail

Cleveland Clinic is ranked one of the top hospitals
in America by U.S.News & World Report (2009).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and
locations.


Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.

Received on Wednesday, 15 December 2010 22:21:51 UTC