Comments on SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs WD 20091022

Hi,

Some personal comments on the SPARQL 1.1 Uniform HTTP Protocol for
Managing RDF Graphs, 22/10/2009.

* General question re: scope. The document at present describes a
mechanism for coarse grained graph updates, and does not attempt to
offer the fine-grained access that SPARQL 1.1 Update offers. But
there's a wide spectrum between those extras. For example the Talis
Changeset format and protocol provides a RESTful way to manage updates
to RDF graphs that is more expressive than the protocol described here
but less so that SPARQL Update. Are the WG likely to consider
something like Changesets too? (I note as an aside that there's at
least one completely independent implementation using Changesets).

* The main SPARQL protocol specification includes a wording on
scenarios where a SPARQL processor might refuse to carry out
operations. Perhaps this document should include similar wording to
note that implementations may be free to refuse to create, update, and
delete graphs for a variety of reasons?

* Section 4.1. Is a PUT to a graph resource with an empty payload
allowed? i.e. can I create an empty graph?

* Section 4.3. An HTTP POST is described as being mapped to a
inserting an RDF/XML payload into the target graph identified in the
Request-URI. This means that a client has full control over how the
URI space of the server is managed. Having the option for the server
to assign a graph URI, e.g. into which the payload is then stored,
would also be useful. Typically this would be treated as a POST to a
"container" resource, e.g. /graphs. The server would then deposit the
data into a newly assigned graph URI and return a 201 Created response
with a Location header to inform the client of its location.

* Section 4.3. Notes that conditional GETs should be supported
wherever possible. What about conditional updates and deletions? This
seems like a useful extension that could be documented perhaps as a
MAY or a SHOULD.

* Finally I think that the specification should discuss some of the
different strategies for managing graphs, not to constrain
implementations but to at least tease out some of the related issues.
I think this relates particularly to the second editorial note
relating to use of aliases, but also to how the graphs described in
this document relate to the URIs of the dataset(s) exposed through the
SPARQL service description mechanism.

Cheers,

L.

-- 
Leigh Dodds
Programme Manager, Talis Platform
Talis
leigh.dodds@talis.com
http://www.talis.com

Received on Saturday, 24 October 2009 20:25:48 UTC