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

Re: HTTP DELETE operation

From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
Date: Fri, 21 Jan 2011 13:29:29 +0100
To: public-rdf-dawg-comments@w3.org
Message-Id: <201101211329.29264.kjetil@kjernsmo.net>
Torsdag 20 januar 2011 10:25, skrev Gregg Reynolds:
> I think the language of the Update spec is a little broken.  The following
> language is used in the sections on CLEAR and DROP
>
> "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 graph does not exist."
>
> What does "the specified graph does not exist" mean, where the store allows
> empty graphs?  It could mean the graph name is not found, or it is found,
> but its graph is empty (or, it does not "point to a graph", or "has" no
> graph.)

Hmmm, I feel that is pretty clear. Consider this: In a typical quad store, you 
record triples and the graph name in the same row. Thus, when there are no 
triples in a graph, the graph itself doesn't exist since the graph has not 
been recorded independently. However, you *can* create a graph store that 
does record graph names separately from the triples, so it is my 
understanding that the above statement pertains to those cases. In those 
cases, a graph may be empty, as opposed to a quad store, where it doesn't 
exist if it is empty.

> I think the success/failure language should be reconsidered; it doesn't
> reflect the real semantics very well.  It would be better to talk in terms
> of exceptions; then you get language that works both for programming
> languages and for communications protocols, among other virtues.  

OK, I think we can leave that as a suggestion to the WG. I have no opinion 
either way, as long as the HTTP DELETE operation isn't overcomplicated :-)

> > 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.
>
> That would not help, since you cannot make ASK then DELETE atomic.

True, but it would be what I could do if I were attempting a pure SPARQL 
Update-based implementation of the REST spec.

Cheers,

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 Friday, 21 January 2011 12:29:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 January 2011 12:29:59 GMT