- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Mon, 23 Nov 2009 11:44:57 -0500
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
One issue that I brought up at the teleconference that I think needs wider debate is the nature of SPARQL Update RDF datasets. I'm not sure how well the F2F minutes capture this, but I think the relevant section is: http://www.w3.org/2009/sparql/meeting/2009-11-03#line0344 we also created an issue for it - http://www.w3.org/2009/sparql/track/issues/51 I'd like to discuss this tomorrow. The short summary is: 1. SPARQL Query is based on the concept of queries executing over an RDF Dataset (default graph + zero or more named graphs). The RDF Dataset is pulled from an implicit universe of queryable graphs, but SPARQL Query doesn't say anything about this universe of potential graphs. 2. SPARQL Update is based on the concept of a Graph Store. As far as I can tell, the notion of Graph Store corresponds roughly to SPARQL Query's unstated notion of a universe of queryable graphs (with the main difference be that new graphs can be created in Graph Store). 3. As far as I can tell, pattern-matching in SPARQL Update statements is always against the full graph store. I don't see anyway to restrict it to a specific RDF Dataset, the way I can with SPARQL Query. I'd expect to be able to do something like: INSERT INTO <g1> { template } FROM g2 FROM g3 FROM NAMED g4 FROM NAMED g5 WHERE { GRAPH ?g { ?s ?p ?o } } where g1, g2, g3, g4, and g5 are all graphs in the graph store - g1 specifies where my inserts go, and the rest specifies an RDF Dataset for the WHERE part of the query, just the same as it would in SPARQL Query. SteveH and Dave Beckett expressed a contrary opinion at the F2F that it might be better to rethink the whole graph management approach for SPARQL Query, but I feel strongly that that would be very confusing for users and implementors alike. Anyway, I'd like to discuss that on-list and possibly in the teleconference as well. Lee
Received on Monday, 23 November 2009 16:45:44 UTC