Ambiguity about whether graphs are created or deleted

Please add this to the wish list for the next version of SPARQL Update.
I do not expect it to be addressed in the 1.1 version.

At present the spec allows SPARQL servers to automatically delete empty
graphs.  It also provides a CREATE operation for explicitly creating
graphs, though it does not require that the CREATE operation be used,
because graphs are created implicitly anyway.  Since I want my SPARQL
code to work properly on any SPARQL 1.1 compliant server, as a user this
ambiguity leads to a dilemma.  Consider the following sequence:

  DROP SILENT ALL ;
  CREATE GRAPH <one> ;
  CREATE GRAPH <two> ;
  ADD GRAPH <one> TO GRAPH <two>  ;

The naive interpretation is that the above ADD operation should always
succeed, since graph <one> was just created.  In implementations that
keep empty graphs, the ADD operation will succeed.  But if the
implementation automatically deletes empty graphs, then the CREATE
operations will have no effect, and the ADD operation will fail, even
though the graph *had* been "created", but merely happened to be empty.
So even though an empty graph is a perfectly normal thing to have
sometimes -- for example, the graph may be recording the sales of ice
cream cones on a day when none were sold -- the ADD operation causes a
failure. 

A workaround is to add the SILENT keyword to the ADD operation:

  ADD SILENT GRAPH <one> TO GRAPH <two>  ;

But this is not so great to do, because this will mask actual
programming errors like this misspelling of "one":

  ADD SILENT GRAPH <onnne> TO GRAPH <two>  ;

Another workaround is to not use CREATE.  But if it isn't needed or
helpful to some implementations, then why is it in the language?

In short, the ambiguity that was allowed is harmful to users.  Please
pick one style or the other and stick with it: either keeping empty
graphs and requiring explicit CREATEs and DELETEs, or eliminating CREATE
and DELETE from the language.

Thanks!

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Tuesday, 26 June 2012 16:38:27 UTC