Re: Update protocol and dataset description

On 07/08/11 18:47, Lee Feigenbaum wrote:
> I went and tried to find the last time we discussed this. I believe it
> was here:
>
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JanMar/0001.html
>
> In which you asked:
>
...
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JanMar/0003.html
>
> """
... More questions ... no answers at the time.

> There wasn't any further discussion then. I agree this is confusing,
> because of the fact that it affects the RDF dataset but not the target
> graphs. And the interplay with WITH is unclear as well.

It doesn't?

>
> The use case is similar to query. For example, in Anzo we use SPARQL
> Update requests often either as manual ways to update the store or as
> automated rules. We retarget the update requests from one dataset (set
> of graphs) to another by changing these parameters (well, in our case,
> we have a named dataset extension, but it's the same idea).

Could you explain that further (or ref Anzo documentation)?  Is the 
named dataset the store for the update? Is it isolated from the store 
for the update? (both "yes" and "no" lead to useful but different designs)

> What do you think of your January suggestion to use different parameter
> names here -- using-graph-uri and using-named-graph-uri?

I think it is rather unclear what's happening: I asking then and didn't 
get answers.

Test case 1: Is the dataset description a dataset description or store 
description of some kind: both make sense but are different.  Datasets 
do not change, stores do:

If
named-graph-uri=http://example/g

Does

INSERT DATA { GRAPH <http://example/g> { :s :p :o } }

affect

DELETE { GRAPH <http://example/g> { ?s ?p ?o } }
WHERE
   { GRAPH <http://example/g> { ?s :p :o } }

In the formal semantic of update, the dataset is determined per 
operation so earlier changes are visible.


Tests case 2:
named-graph-uri does not contain http://example/g

INSERT DATA { GRAPH <http://example/g> { :s :p :o } }

DELETE { GRAPH ?g { ?s ?p ?o } }
WHERE
   { GRAPH ?g { ?s :p :o } }

does WHERE now see <http://example/g>?

>
> Finally, I don't understand your point #4 below. Could you explain?
>

The function TrDataset selects the dataset for the update operation. 
There is no option for it to come from the protocol and anything would 
be a change to SPARQL Update.

The interactions of protocol parameters and update do not look as if 
there is one natural interpretation.  Both fixed and mutating designs 
look plausible.

Not putting default-graph-uri/named-graph-uri in the spec might be the 
better course at this time.

 Andy


> thanks,
> Lee
>
>
> On 8/5/2011 3:58 AM, Andy Seaborne wrote:
>> The update protocol allows default-graph-uri and named-graph-uri in
>> update requests.
>>
>> I'm not sure this is a good idea:
>>
>> In query, it's used to retarget or set the target dataset of a single
>> query, overriding FROM/FROM NAMED. Typical use is in web forms to set
>> the target of the query for a general query processor, one that does not
>> have any implicit dataset.
>>
>> 1/ Update is not the same - an update request is several operations,
>> some of which might have USING/USING NAMED and others don't.
>>
>> Use default-graph-uri and named-graph-uri for the update dataset
>> collapses the USING/USING NAMED so changing the update request so that
>> different operations no longer see different datasets.
>>
>> It seemed to be to be better for USING/USING NAMED in update not to be
>> overridden as it looses something of the update structure.
>>
>> 2/ Query is stateless - update is state changing. Retargetting a query
>> (maybe for testing) causes no state change. Update is state change so
>> retargetting needs to be done by setting up a different service.
>>
>> 3/ When I first read it, I more naturally tended to see it as defining
>> the graph store. In query it defined the target (RDF dataset) and in
>> update it does not define the overall target.
>>
>> 4/ The Update Langauge doc does not have the facility to have a
>> different dataset for the WHERE clause to the graph store. [1]
>>
>>
>> Could someone provide the use case for this feature and why it should
>> override USING/USING NAMED?
>>
>> Andy
>>
>>
>>
>>
>> [1]
>> http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#mappingRequestsToOperations
>>
>>
>>
>>
>

Received on Sunday, 7 August 2011 19:05:29 UTC