Further comments on SPARQL 1.1 Uniform HTTP Protocol

Hi 

Having looked over the document some more and started looking at how
I would implement support for the protocol in my own library I have some
further comments on the document. 

HTTP RESPONSES  

Currently the
document is quite vague on what response codes should be sent for different
results or what the server should do in the event of certain error
conditions etc. which for a document defining a RESTful interface is
unusual. I'd prefer the document to be much more specific particularly when
it comes to response codes as this makes it much easier for developers of
both servers and clients to create properly interoperable implementations.


Some of the things I'm not sure what the response code/behaviour of the
protocol should be are as follows. Where applicable I've put what response
seems most appropriate to me in italics - since this part of the comment is
subjective I've also CC'd this email to the SPARQL developers list: 

  *
Unsupported HTTP Verb used - _405 Method Not Allowed_
  * Unable to resolve
URI/invalid URI provided - _400 Bad Request_

 * A GET operation is
performed on a Graph that does not exist in the store - _Empty graph
returned, should a 404 Not Found be returned?_
  * Implementation does not
support an operation e.g. DELETE on a read-only store - _405 Method Not
Allowed_
  * Implementation does not implement an operation - _501 Not
Implemented_
  * Implementation cannot return an RDF graph in any of the
formats specified in Accept header - _406 Not Acceptable, alternatively
could default to RDF/XML?_
  * Implementation cannot understand the media
type of the RDF payload - _415 Unsupported Media Type_
  * Parsing of RDF
payload fails - _400 Bad Request_

 * A well defined error occurs while
processing a request e.g. attempting a DELETE on a non-existent Graph -
_400 Bad Request_
  * Implementation encounters an error - _500 Internal
Server Error_

BEHAVIOUR OF POST 

As it currently stands the behaviour of
POST seems unclear to me due to the section about what happens in the case
when the Graph URI provided identifies the store itself and the consequent
minting of new Graph URIs to which the POSTed payload is then added with
the newly minted URI being returned as a Location header. The document
could do with a more concrete example of such a request (perhaps even
examples of a HTTP request-response sequence) and clarifying this section.
Currently I have not attempted to implement this part of the specification
because I am not entirely sure what I should be doing. 

BEHAVIOUR OF GET


The document does not appear to state what should the behaviour of a GET
be in the event that there is no such Graph in the store? Should an empty
graph be returned or should a server respond with a 404 Not Found? 

ADDING
HEAD TO THE PROTOCOL 

Has the WG considered the possible use of the HEAD
verb in the protocol for the determining of whether a given Graph exists in
a store without retrieving it's entire contents? Possible use cases are
things like: 

  * Checking whether a Graph is already present before
attempting a PUT esp when the Graph to be uploaded is large
  * Checking
whether a common/required graph is already present e.g. copies of
schemas/ontologies

A HEAD request would be equivalent to doing an ASK
WHERE {GRAPH  { ?s ?p ?o } } 

Regards,
Rob Vesse  
-- 
PhD Student
IAM
Group
Bay 20, Room 4027, Building 32
Electronics & Computer
Science
University of Southampton