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

Re: RDF datasets for SPARQL Update?

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Mon, 23 Nov 2009 17:30:46 +0000
Message-ID: <4B0AC6C6.9000704@talis.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>

On 23/11/2009 16:44, Lee Feigenbaum wrote:
> 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.

I'd like to hear more about that - is there a description of an alternative?


> Anyway, I'd like to discuss that on-list and possibly in the
> teleconference as well.
> Lee
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
Received on Monday, 23 November 2009 17:31:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:58 UTC