Re: RDF datasets for SPARQL Update?

Andy Seaborne wrote:
> 
> 
> 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?

I'll let Steve speak, but I meant rethink it for SPARQL *Update* - no 
one was proposing changing SPARQL Query's model, since we need to ensure 
backwards compatibility. Sorry for any confusion.

Lee

> 
>     Andy
> 
>>
>> 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:37:13 UTC