- From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
- Date: Fri, 21 Jan 2011 13:29:29 +0100
- To: public-rdf-dawg-comments@w3.org
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 UTC