Re: Implementation details of SPARQL 1.1 Graph Store HTTP Protocol

Ivan, thanks for the feedback, see the response (inline) below. 
> Dear all,
> I've implemented the protocol in its current form, and as a result I've
> got a list of questions re. dealing with errors [...] 
> 1. Could the protocol be slightly tweaked so that PUT with multipart form is permitted for current "PUT" and "POST" functionality, in order to allow graph manipulation via trivial web page with "upload file" button? More common, should all operations be made available in that style, as an addition to the current functionality?

The editor's draft [1] has been modified to accommodate this.

> 2. In case of HTTP PUT, what should happen if the submitted data are  DROP the partial result? Or I have no "faster" variants than
> syntactically wrong? Should DROP SILENT GRAPH <graph_uri> or DROP SILENT
> or - to make a "dry run" of the parser to check the syntax and then parse for the second time in order to make an actual job (2x slowdown). - to parse everything and cache in memory and change the storage only memory-limited) DEFAULT be performed in any case? Should I keep the half-loaded data orafter the resource is parsed from beginning to end (memory-consuming and
> 

Per 5.1 Status Codes, a 400 Bad Request response should be sent back.

> 3. What should I do if authentication is required and graph-level security exists in the system if PUT or POST mentions relative IRI and
> the document contains more than one xml:base attribute? As a funny example, let odd xml:base-s be read-only and even xml:base-s be writeable for the active user.



Support for base resolution was removed prior to a recent publication due to situations where resolution was ambiguous .
> 4. The spec says that "For operations involving an RDF payload (PUT and POST), the server MUST parse the RDF payload according to media type specified in the Content-Type header (if provided in the request). If this header is not provided, the server SHOULD attempt to parse the RDF payload as RDF/XML." If the Content-Type is not provided and I have a routine that guesses the type by the content of the resource and the routine reports that the resource is clearly Turtle and not RDF/XML in any way, should I load it as Turtle or blindly report an error?


A fallback heuristic for situations where content-type is not provided has been added to the second paragraph of "5 Graph Management Operations"

> 5. Are there any requirements re. isolation? What should I do with conflicting PUTs or a HEAD/GET during PUT? DAV offers locking and version-checking functionality for very similar authoring and retrieval of remote resources, and that functionality is neither useless nor redundant, but graphs adds even more complications because they can be accessed even while being written, unlike most of DAV implementations.
Concurrency management is beyond the scope of this protocol and implementations should be able to do what they see fit to support concurrent access etc.

[1] http://www.w3.org/2009/sparql/docs/http-rdf-update/

Chime, on behalf of the working group.Sent with Sparrow

Received on Wednesday, 16 November 2011 02:16:38 UTC