W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > May 2011

Implementation details of SPARQL 1.1 Graph Store HTTP Protocol

From: Ivan Mikhailov <imikhailov@openlinksw.com>
Date: Mon, 23 May 2011 16:10:36 +0700
To: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
Message-ID: <1306141836.7024.1992.camel@octo.iv.dev.null>
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?

2. In case of HTTP PUT, what should happen if the submitted data are
syntactically wrong? Should DROP SILENT GRAPH <graph_uri> or DROP SILENT
DEFAULT be performed in any case? Should I keep the half-loaded data or
DROP the partial result? Or I have no "faster" variants than
- to parse everything and  cache in memory and change the storage only
after the resource is parsed from beginning to end (memory-consuming and
memory-limited)
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).

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.

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?

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.

Thanks in advance for any suggestions/recommendations,

Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com
Received on Monday, 23 May 2011 09:11:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 May 2011 09:11:02 GMT