W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2011

Re: Update protocol and dataset description

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Mon, 08 Aug 2011 09:24:17 -0400
Message-ID: <4E3FE381.9080107@thefigtrees.net>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
CC: public-rdf-dawg@w3.org
On 8/8/2011 8:37 AM, Andy Seaborne wrote:
> I asked:
>
> """
> Could someone provide the use case for this feature and why it should
> override USING/USING NAMED?
> """
>
> What capability does having parameters at all for update give the client
> application?
>
> I really would like a concrete example we can discuss - the test cases
> tried to explore this.

Sorry, the test cases don't resonate with me at all.

I said:

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

Consider a SPARQL Update request that implements (rather naively) 
subclass reasoning:

INSERT {
   GRAPH ?g { ?s a ?super }
}
WHERE {
   GRAPH ?g { ?s a ?type }
   GRAPH ?ont { ?type rdfs:subClassOf ?super }
}

We would basically register this request with the system, and then use 
it repeatedly by pointing it at different data sets via parameters to 
the API or protocol.

> I see several interpretations of parameters:
>
> 1/ dataset is fixed at the start of the update request and the same is
> used for all WHERE clauses regardless of USING etc and of operations
> earlier in the request.
>
> 2/ The dataset structure is fixed, the contents of the graphs can change
> across operations within a request.
>
> 3/ The dataset for each operation is modified in some way by the params
> so it's the combination of the graph store and parameters that matters.
> Graph created by earlier operations in open request are visible in the
> dataset of a later operation.
>
> These are not independent and there are popssible variations.

So #2 is what I've always had in mind, and what is basically implemented 
in Anzo. I think that #2 falls pretty naturally out of working with 
graphs as g-boxes.

Lee

>
> Andy
>
Received on Monday, 8 August 2011 13:25:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT