Re: datasets in update

I think that it would be useful feature and that, time permitting, we 
should consider it.

I do wonder if the pattern graphs description should be per-operation or 
whether there should be a way to specify it for more than one operation.

Possibilities include:

USING
FROM <g1>
FROM NAMED <g1>

(I have no strong attachment to USING - just a word that cam to mind 
writing this email).  Just FROM, FROM NAMED inline might work although 
as it is multiple clauses, an introducing word might make it easier on 
the eye.)

USING DATASET
OVER DATASET
PATTERN FROM ... FROM NAMED ...

It applies from that point in the request until the end, or another USING.

The same multi-operation need exists for WITH - I can imagine that if an 
app wants to modify one graph it might want to make several operations 
inside a request on that graph.

	Andy


On 19/01/2010 2:09 PM, Lee Feigenbaum wrote:
> 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
>>
>>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

Received on Friday, 22 January 2010 15:25:53 UTC