Re: datasets in update

Andy Seaborne wrote:
> 
> 
> On 18/01/2010 21:20, Lee Feigenbaum wrote:
>> Luke Wilson-Mawer wrote:
>>
>>> * If the INTO in the older update syntax of INSERT INTO <uri> {} is
>>> replaced by the user of GRAPH in the new syntax of INSERT {GRAPH
>>> <uri> {}}, does this mean that GRAPH is now taking the role of
>>> specifying the dataset? Does this matter, and should it be
>>> included here? Perhaps I've missed something in the dataset
>>> conversation.
> 
> GRAPH, in query, chooses the named graph to act upon within the dataset; 
> it's not specifying the dataset.

Right.

>>
>> We're going to remove the parts of the protocol that deal with the
>> dataset for now, but I believe that the dataset issue with Update is
>> still unresolved. (Paul, please correct me if you feel otherwise!)
>>
>> I've brought this up a couple of times (first at the F2F2 and a bit on
>> the mailing list since at
>>
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0503.html
>>
>> and at
>>
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0581.html
>>
>> The gist of my suggestion is that I would like the ability in SPARQL
>> Update to have my update commands act on a subset of the graphs in a
>> Graph Store in the same manner that I can (via FROM and FROM NAMED) in
>> SPARQL Query.
>>
>> The reasons I want to be able to do this are twofold:
>>
>> 1) My organization uses this capability in query all the time, and
>> SPARQL Update would be pretty much useless to us without this
>> capability. (We'd likely implement a non-standard version of SPARQL
>> Update that allowed us to do this.)
>>
>> 2) I think it's very odd (and therefore challenging to teach & learn) to
>> have two different graph/dataset models for SPARQL Query and SPARQL 
>> Update.
> 
> We can make "graph store" == "dataset".  The names were choosen 
> differently to avoid jumping to the conclusion they are the same.  They 
> are different in that the graph store is mutable and a dataset is not. 
> That distinction may no tbe enough to use different terminology.

OK, merging the two terms would be a first step, and then...

> Being about to select a subset may be useful here.  Is that what you 
> mean by whating to specify the dataset?  In your references messages, 
> the examples sugges to me it's limiting the pattern matching (WHERE) 
> only.  Have I missed something here?

No, you understand perfectly. I'd like the ability to restrict what 
graphs comprise the default graph and which graphs are available as 
named graphs for the WHERE part of an Update command.

> Specifically, the updates go to the whole graph store. The app can say
> 
> INSERT
> FROM ...
> FROM NAMED ...
> { GRAPH <g> { .... } }
> WHERE { }
> 
> and <g> is not in FROM / FROM NAMED
> 
> For example, in ARQ+TDB, multiple FROM in a query make the default graph 
> the dynamic union of the graphs identified.  That does not work for update.

Yes, precisely.

Lee

>     Andy
> 
>>
>> Lee
> 
>

Received on Tuesday, 19 January 2010 14:10:11 UTC