- From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
- Date: Wed, 19 Jan 2011 16:26:54 +0100
- To: public-rdf-dawg-comments@w3.org
Fredag 14 januar 2011 16:52, skrev Gregg Reynolds: > To me, "Not found" does not mean failure. It says the operation has > successfully determined that the resource is not found. That's true, there could be many failure situations other than not found. However, about DROP the Update spec says: "If the store records the existence of empty graphs, then the SPARQL 1.1 Update service, by default, is expected to return failure if the specified named graph does not exist. ", which is the only failure situation it specifies, so that's what we have. My approach is pragmatic: I note that if I follow the current REST spec, I have to first do a ASK query to find out whether the graph exists. If this is really the intention, it should say so in the spec, since it lists which queries can be used. I think that doing this may not be what we want, since it adds complexity to all implementations and query execution time to all DELETE operations. That is, from my perspective a very high cost for very little gain: The user may simply send a HEAD request before doing the DELETE if they really need to know reliably whether a graph exists, and for the rest, I think a quote is in order: "You know, you come from nothing - you're going back to nothing What have you lost? Nothing!" If you delete something, often you will simply not care if it was there or not before you did. I suspect that many implementations will simply ignore the spec at this point, because the value of the 404 for the DELETE is so little. They would still be compliant, since it is a SHOULD, but I'd like this to be smoother. My suggestion is therefore that the DELETE response should be tied to response of a DROP query of the Update spec. As long as the DROP returns only success or failure, I think that if it returns success, the HTTP response should be a 20x-code and the DROP failure means a 404, but an implementation MAY try to do further forensics to provide more detailed errors to the user, both in the case of of success and failure. I think that it SHOULD do such forensics beyond what's given by DROP is too strict and should be avoided. > While I'm at it, I should ask: is this list supposed to serve as a forum > for discussion, or is it only intended as a means for registering public > comments on the drafts? I think we can discuss (on topic) unless somebody shouts :-) Best, Kjetil -- Kjetil Kjernsmo PhD Research Fellow, University of Oslo, Norway Semantic Web / SPARQL Query Federation kjetil@kjernsmo.net http://www.kjetil.kjernsmo.net/
Received on Wednesday, 19 January 2011 15:27:24 UTC