(Batch) Response to SPARQL WD comments

Hello, Kjetil

The responses below are in regards to a collection of your comments that were still outstanding.

On Wednesday 2. February 2011 Kjetil wrote:
> ..snip..
> [...]. I think all the definitions would only serve to confuse people, if it can't be defined in already familiar terms, we're doing something wrong. Sections that I find overly opaque include such things as I have pointed out earlier, such as that if a DELETE of a non- existant graph is attempted, it should say so explicitly, but also note that I dispute the usefulness of this approach. I posted a few comments in October and November about parts of the spec that I found too ambigious when I wrote an implementation, which makes it feel underspecified.
Amongst the edits that went into the last round of publication, there has been clarifications on expected behavior and the examples now have much more detail (for the benefit of developers) about the form of requests and responses. The introduction now describes the RESTful constraints are applied as well.

On 7. February 2011 Kjetil wrote:
> It is my opinion that the spec should be tied very strongly to concepts that those hords of developers would recognize immediately, as it fits with how they have always manipulated files on a web server. Any part of the protocol that cannot be specified on those terms should be dropped. We cannot afford the image that the Semantic Web is complicated. I truly believe it is the simplest thing that could possibly work and this protocol should have been really simple and familiar, but currently it isn't.
Please see the response above regarding changes made to improve the readability for developers.

On Friday 25. March 2011 Kjetil wrote:
> Another problem with the Dataset protocol: It seems to talk about direct and indirect graph identification in two different contexts. The first is to distinguish between direct (i.e. GET the request-URI) and indirect graph identification (i.e. use a graph query parameter). For want of a better term, I think this is OK. 
> However, in section 4.1, about direct graph identification, it says "However, in using a URI in this way, we are not directly identifying an RDF graph but rather the RDF graph content that is represented by an RDF document, which is a serialization of that graph." 
> I must admit that I cannot se how this usage is founded in Webarch. Quite to the contrary, when webarch talks about indirect identification, it is something quite different: http://www.w3.org/TR/webarch/#indirect-identification
Please see an earlier response to a similar question:

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Feb/0007.html

The term indirect identification is being used in the main (English) sense of the word to clarify that the request URI does not identify the resource that is modified as a result. 

On Friday 14. January 2011 Kjetil wrote:
> I've seen in SPARQL Update, section 3.2.2., a store that do not record empty > graphs will always return success.
> Also, in 3.1.3, it says "Deleting triples that are not present, or from a > graph that is not present will have no effect and will result in success." It then strikes me as odd that the HTTP DELETE operation SHOULD return a 404, > IMHO, it would be more natural, given the above and the overhead resulting from checking if a graph is present, to say that HTTP DELETE MAY result in a > 404 if a DROP would have resulted in a failure.
As Gregg mentioned in his followup to the thread, 404 is in reference to the identified resource and whether or not it exists rather than it being an indication of failure of the the operation as a whole (or of success of failure of a DROP operation). According to the semantics of the HTTP DELETE method:

"[...] the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location."

So, a response other than 404 would suggest that the resource identified does indeed exist and this would contradict the REST interface constraint regarding identification of resources and the general expected behavior of DELETE, notwithstanding whether or not the store records empty graphs.Changes have been made to the latest Working Draft to reflect many of the issues raised above:

http://www.w3.org/TR/2011/WD-sparql11-http-rdf-update-20110512/

We'd appreciate if you could indicate whether this response adequately addresses your comment.
Chime Ogbuji

(On behalf of the SPARQL Working Group)

Received on Tuesday, 17 May 2011 13:44:38 UTC