W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > January 2011

Re: HTTP DELETE operation

From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
Date: Wed, 19 Jan 2011 16:26:54 +0100
To: public-rdf-dawg-comments@w3.org
Message-Id: <201101191626.55056.kjetil@kjernsmo.net>
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 

"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 

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 :-)


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:28 UTC