Re: Binding injection proposals

good evening;

> On 2016-10-28, at 13:31, Andy Seaborne <andy.seaborne@topquadrant.com> wrote:
> 
> 
> 
> 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 text in https://lists.w3.org/Archives/Public/public-sparql-exists/2016Sep/0024.html reads as implementation for aspects of dynamic binding.

> 
> 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./“

that sentence does not stipulate implementation.
were that description to be amplified, to describe the scope of that binding, that would be valuable.
as the remainder of the message reads, if a text of that sort were to be made normative, in the sense which i described, above, it constitute an unnecessary burden.

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

i understand that aspect of the proposal to “stipulate[] implementation”.

> 
> Neither has "side effects" - there are details which is why we need a precise definition.

the meaning intended for “side-effect” is that it changes the processor’s behaviour, rather that there is any side-effect on the data model being processed.

>  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?

i welcome, and am participating in discussions to formulate those semantics.

> How would you express each proposal? Do you have a different proposal?

in general, that which i have referred to previously: clarify the scoping rules for the language, which process would clarify the role and semantics of dynamic bindings.

best regards, from berlin,
> 
>    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
>> 
>> 
>> 
>> 
>> 
> 
> 



---
james anderson | james@dydra.com | http://dydra.com

Received on Friday, 28 October 2016 16:54:39 UTC