- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Mon, 08 Aug 2011 09:24:17 -0400
- 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 UTC