- From: David Booth <david@dbooth.org>
- Date: Tue, 26 Jun 2012 12:37:58 -0400
- To: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
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