- From: Leigh Dodds <leigh.dodds@talis.com>
- Date: Sat, 24 Oct 2009 21:25:15 +0100
- To: public-rdf-dawg-comments@w3.org
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