Re: Update protocol and dataset description

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:

"""
 > I'm not sure what &default-graph-uri= and &named-graph-uri= mean for 
 > an SPARQL Update request.

...

 > I can see this applying to the pattern part only (c.f. USING) for
 > Anzo/Glitter -- is that the intent?
"""

and I replied:

"""
On the protocol teleconference, we discussed that they would define the
RDF dataset against which graph patterns are evaluated -- a la USING and 
USING NAMED, as you say below.
"""

In response to that, you suggested:

http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JanMar/0003.html

"""
My other reading was a protocol argument for WITH.

Would better names be:

-- same as WITH
default-graph-uri
    or
with-graph-uri

-- same as USING
using-graph-uri

-- same as USING NAMED
using-named-graph-uri

Something to make it clear it is not the graph store being affected for
the "using" ones.

For what semantics, in a query request, there is only one query and only 
one possible dataset description.  But in an update request there can be 
several operations, some with WITH, some without, and some with USING 
some without.

Do the parameters override all the operations?  This makes more sense to 
me but it does seem like a choice point in the design - anther choice 
would be override if there were no USING etc and keeping if an explicit 
USING, despite that being different to query but query is different 
because it can't have mixed combinations in one request.
"""

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.

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

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

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

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 17:47:58 UTC