W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

RDF datasets for SPARQL Update?

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Mon, 23 Nov 2009 11:44:57 -0500
Message-ID: <4B0ABC09.2080002@thefigtrees.net>
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:


we also created an issue for it - 

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:

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.

Received on Monday, 23 November 2009 16:45:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:57 UTC