- From: Chimezie Ogbuji <ogbujic@ccf.org>
- Date: Mon, 16 Aug 2010 12:37:52 -0400
- To: "SPARQL Working Group WG" <public-rdf-dawg@w3.org>
In thinking about where there is ambiguity with the various protocols and how they bind to HTTP, it seems like if we separate along the following criteria, it is easier to clarify what are appropriate bindings to HTTP: 1. Languages v.s. Representations ( application/sparql v.s. application/xml+rdf ) 2. Operations that target service endpoints v.s. Operations that target named graphs (via their graph IRIs) 3. How clearly HTTP specifies the semantics of the verbs (PUT, DELETE, GET, etc..) For operations that directly identify named graphs, use representations, and make use of well-defined HTTP verbs (GET, PUT, and DELETE), even though the operations can be replicated with via the 'languages' there is no ambiguity because it is just two styles for doing the same thing: CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <http://example.com/rdf-graphs/employees> { ?s ?p ?o } } v.s GET /rdf-graphs/employees HTTP/1.1 Host: example.com Accept: application/rdf+xml You might might prefer to use the second if in your deployment scenario it was important to be able to leverage native HTTP capabilities (such as security, cacheability, etc.) For operations involving HTTP methods that are not so clearly defined (such as POST), it seems to be mostly a question of what are the common use cases for HTTP when the body is a representation: - Append triples to a named graph, or - Create a named graph whose graph IRI is determined by the server - .. Others? .. However, if the body is a language (SPARQL Update or SPARQL Query) *and* the request URI is associated with a named graph, then it is not so clear if there is any advantage in providing an HTTP mechanism for a controlled subset of the language. For example, in the case of SPARQL Query (as TimBL was suggesting), you can interpret the operation to be directing a query against the named graph alone but then you need a proviso for situations where the body doesn't match this intent such as where a GRAPH operator is used with a different graph IRI, for instance. It might be better off having such operations target services or endpoints instead where the request is fully defined by the language. However, PATCH would seem like an exception. Despite the fact that it may be less supported, the operation is well-defined and expects the request to include a set of instructions (presumably in a particular language) to determine how the identified resource is modified. So, it seems reasonable to interpret a PATCH message where the request URI is a graph IRI and the body is a SPARQL Update instruction as a request to modify the associated named graph and that graph only (so if the request has instructions that target a different graph, then a 400 - Bad Request - is returned). -- Chime =================================== 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 Monday, 16 August 2010 16:53:09 UTC