Binding injection proposals

Peter, all,

How do we go about deciding when the two proposals?

I'm not unbiased - I think the "deep" implementation is better because 
it is less intrusive to implement, and covers more cases including ones 
that seem natural to me (e.g. the GRAPH).

I have a prototype implement for the "deep" implementation [1].

Also -- some tests [2] (BNodes, FILTER in EXISTS and for GRAPH, 
including GRAPH+FILTER).

The prototype only requires changing the execution of the "exists" 
function.  To implement the "top-level" proposal, requires changes at 
the syntax level, presumably in the translation step. Then the 
"Initial(t)" is in-place before translation to the algebra because the 
"top-level" proposal requires it to happen before filters are processed 
for {}-groups.  This is both more complicated and would likely impact 
existing optimizers for the new element that can appear.

What they do share is how injection is described. The mechanism of a 
replaced token in the algebra works for both.  The "deep" proposal can 
be implemented that way, as a rewrite of each BGP with a join to a data 
table (the algebra for VALUES) or rewrite each BGP with surrounding 
appropriate FILTER(sameTerm&&sameTerm).

The reverse is not true - the "top-level" proposal can't be explained as 
algebra change at runtime because "initial" must be in-place in the syntax.

 Andy

[1] https://github.com/afs/jena/tree/exists
[2] https://github.com/w3c/sparql-exists/tree/gh-pages/tests

Received on Friday, 28 October 2016 10:09:00 UTC