- 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