Thank you for your comments. See our response inline below
> 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.
We'd appreciate if you could indicate whether this response adequately addresses your comment.
(On behalf of the SPARQL Working Group)