From SPARQL Working Group
Link to comment
Thanks for your comments.
Below is an account of our response to your comments regarding the SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs first Working Draft:
Leigh Dodds wrote:
> * 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).
Unfortunately, the initial scope of the document was to cover the minimal behavior covered by an intuitive interpretation of the HTTP protocol specification. As a result the granularity is quite coarse and more fine-grained interactions were delegated to the SPARQL Update language.
Chimezie Ogbuji 20:13, 14 December 2009 (UTC) Some comments regarding where Changesets fall within the WG charter scope (from the chairs) would be useful
> * 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?
See the paragraph added to the 'Security Considerations' section to this effect.
> * Section 4.1. Is a PUT to a graph resource with an empty payload > allowed? i.e. can I create an empty graph?
See modifications to the end of section 4.1 (HTTP PUT) regarding the semantics of an empty PUT request
> * 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.
analogous use case (employee list) - end of Pick the operations step in REST recipe
See modifications to section 4.3 (HTTP POST) regarding this mechanism.
> * 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.
Note that the language regarding conditional requests was moved from the GET section into a general section that discusses the general use of conditioning headers to indicate a conditional request.
> * 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.
Chimezie Ogbuji 20:13, 14 December 2009 (UTC) Is the current SPARQL service description mechanism sufficient to for this purpose (i.e., describing the named graphs in a dataset for the purpose of discovery)?
on behalf of the SPARQL Working Group