Re: Update protocol and dataset description

On 8/7/2011 3:04 PM, Andy Seaborne wrote:
>
>
> 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?

It doesn't. It only affects the RDF dataset. The RDF dataset (to my 
understanding) is what is (a) matched in the WHERE patterns and (b) 
manipulated by USING/USING NAMED. That was the intended design that 
emerged from last year's protocol teleconference.

>> 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)

I'd love to explain, but I don't understand the question :-)

The dataset is the set of graphs (1 default graph + N named graphs) that 
is matched by the WHERE clauses in any of the update request's 
operations. It's unrelated to the graphs in the store that are affected 
(have triples added/removed) by the operations.


>> 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.

I'm not sure what you mean -- I'm suggesting we do exactly what you 
wrote in that message of January -- use using-graph-uri and 
using-named-graph-uri as protocol overrides for USING and USING NAMED.

> 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.

I don't understand at all what this has to do with the current 
discussion. named-graph-uri would mean that the WHERE goes against an 
RDF dataset that contains <http://example/g> as a named graph, and so 
the DELETE operation would match the data and delete all the triples. 
(Actually, it wouldn't delete anything since ?p and ?o are unbound.)

> 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>?

This doesn't seem related to protocol at all. As I understand it, in 
this case the implementation matches the WHERE against the graph store.

>> 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.

Ah I see, that's unfortunate. We'd want the equivalent statement to 
what's in http://www.w3.org/TR/rdf-sparql-query/#specifyingDataset :

"""
The RDF dataset may also be specified in a SPARQL protocol request, in 
which case the protocol description overrides any description in the 
query itself.
"""

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

I'm not sure what you mean about fixed/mutating designs. Perhaps my 
mental model for what's happening in update differs from yours, because 
the design I'm suggesting feels very natural to me. :)

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

I think this would be unfortunate, but I'll just go ahead and continue 
to extend the specs as I do today, anyway. :)

Lee

>
> 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:53:04 UTC