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

Re: HTTP DELETE operation

From: Gregg Reynolds <dev@mobileink.com>
Date: Fri, 21 Jan 2011 08:43:41 -0600
Message-ID: <AANLkTinjH0yopmLKK-rb587MVyGKY__pGOfC+S1JvwXe@mail.gmail.com>
To: Kjetil Kjernsmo <kjetil@kjernsmo.net>
Cc: public-rdf-dawg-comments@w3.org
On Fri, Jan 21, 2011 at 6:29 AM, Kjetil Kjernsmo <kjetil@kjernsmo.net>wrote:

> 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
Ok, but that's implementation stuff.  My point is that the term "graph" is
being used inconsistently.  There is only one "empty" graph, just as there
is only one null set; in fact it would probably better to use the term "the
null graph".  So a plural like "null sets"  or "empty graphs" is a
contradiction.  Thus "store records the existence of empty graphs" can only
mean "store that may map graph /names/ to the null graph".  After all, you
can hardly specify the null graph without using a name to refer to it.  Then
"if the specified graph does not exist" must mean that the name is
registered but it names the null graph.  But there is another possibility,
which is that the name is not registered in the store.  The current language
does not address this case.  I guess my message to the WG is that the
language needs to be extremely fastidious in this respect.

Received on Friday, 21 January 2011 14:44:14 UTC

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