Re: Update protocol and dataset description

On 8/8/2011 2:57 PM, Andy Seaborne wrote:
> The question is what happens within one request when there are two
> operations.
>
> In your example, it's really a subset of the graph store (as I
> understand it).
>
> In my example, the dataset is unchanging. No updates from the first
> operation are visible to in the second operation (neither changes of a
> graphs triples, not the set of named graphs).
>
> It's different from query because of multiple operations in one request.

Maybe I need to see a more complete example. Are you saying that you'd 
pass something like http://example/web in the protocol parameter and 
then do:

INSERT DATA { GRAPH <http://example/web> { :a :b :c } }
;
INSERT {
   ...
} WHERE {
   GRAPH <http://example/web> { :a :b ?c }
}

and not expect the 2nd operation to see the triple from the first?

Lee

>
> Andy
>
> On 08/08/11 16:27, Lee Feigenbaum wrote:
>> This seems like it would be well-handled by the semantics I'm intending
>> here -- the dataset is given in the protocol request, which is basically
>> as if it were given in USING/USING NAMED, at which points it's up to the
>> implementation as to how to get at the graphs (via Web dereference or
>> via local lookup or via something else entirely).
>>
>> Lee
>>
>> On 8/8/2011 10:16 AM, Andy Seaborne wrote:
>>> I'll add a use case then:
>>>
>>> The ability to pull in data from the web and use as dataset in an update
>>> request.
>>>
>>> Here we have a temporary datasets for the update request, which creates
>>> and extracts the data from within the request dataset and adds/deletes
>>> it from the graph store.
>>>
>>> The dataset graphs do not exist in the local graph store before, during
>>> or after the request. The entire WHERE part has been retargetted.
>>>
>>> Andy
>>>
>>>
>>
>
>

Received on Monday, 8 August 2011 19:22:21 UTC