Re: Binding injection proposals

On 28/10/16 11:24, james anderson wrote:
>
>> On 2016-10-28, at 12:08, Andy Seaborne <andy@apache.org 
>> <mailto:andy@apache.org>> wrote:
>>
>> Peter, all,
>>
>
> -1, in general.
> any proposal which stipulates how to implement dynamic bindings in 
> terms of any specific mechanism will be an unnecessary burden on 
> implementations, to ensure that they produce the same side.effects and 
> the specified incidentals.
> it would be better to define the semantics for dynamic bindings in 
> general and then leave the implementation mechanism to the implementation.
I find that rather unhelpful. I hope it is a misunderstanding of my 
message where I report an practical investigation.

Nothing stipulates implementation.

The "deep" proposal says that binding values in BGPs are restricted to 
values in the current row. (I do not know what "dynamic bindings" are.)

To quote the original message:
/"This is done by restricting the variable to the value of the row at 
the point where the variable is being bound./"

You may not like the wording; if so - do you have a suggestion?

The "top level" proposal is restricting values by applying a join of 
fixed data inside the top-most syntax group. It taps into the syntax to 
algebra step that already exists; it is an important part of the 
proposal for filter interaction (see test exists-filter-1) as I 
understand it.

Neither has "side effects" - there are details which is why we need a 
precise definition.  At the same time, there have been requests to 
explain proposals in less abstract terms which I have tried to do.

Tests can provide useful help to implementers because they are 
implementation independent.

You asked for (22/09/16): "an exists definition which aims to be 
consistent with the remainder of the language." and went on to say:
"it is straight-forward to define and realize this goal, if the 
semantics is sited at the correct level of interpretation - that is in 
the abstract algebra,"

I think we're on the way to that - what am I missing here? How would you 
express each proposal? Do you have a different proposal?

     Andy

>
> best regards, from berlin,
>
>> 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
>>
>
> ---
> james anderson | james@dydra.com <mailto:james@dydra.com> | 
> http://dydra.com
>
>
>
>
>

Received on Friday, 28 October 2016 11:31:56 UTC