Re: BIND Issue

(Answered during the call - here for the record)

On 21/08/12 14:23, Lee Feigenbaum wrote:
> I support the below proposal, with a couple of questions:
>
> 1. Are there any test cases that would be affected?

No
(Post-telecon - I reran the SPARQL test suite with a changed translation 
step and no tests started failing because of it)

>
> 2. Do we know if this change would satisfy the commenters?

I believe so.

 Andy

>
> thanks,
> Lee
>
> On 8/21/2012 7:45 AM, Andy Seaborne wrote:
>> This is a brief summary of the BIND comment from Holger and Jeremy.
>>
>> {
>>    GRAPH ?g { ?s ?p ?o }
>>    BIND(?o+1 AS ?o1)
>> }
>>
>> In Query/3LC, BIND operates on the proceeding basic graph pattern, and
>> there is always a BGP, although sometimes it's empty (and invisible in
>> the syntax).
>>
>> This design means the introduced variable is minimally constrained by
>> scope rules because the resulting expression is joined with the
>> overall group elements.  The scope restriction of the applies only to
>> the BGP.
>>
>> This use of ?o1 is OK:
>>
>> {
>>    ?s :p ?o1
>>    GRAPH ?g { ?s ?p ?o }
>>    BIND(?o+1 AS ?o1)
>> }
>>
>> But there is an impact on the expression side of BIND - the scope of
>> the ?o is reduced to the BGP as well.  So it is undef in the example.
>> The ?o is the GRAPH is not available until after the BIND is calculated.
>>
>> In 1LC and 2LC BIND was translated to the algebra in the group pattern
>> processing:
>>
>>     If E is of the form BIND(expr AS var)
>>         G := Extend(G, var, expr)
>>         End
>>
>> making the restriction scope of the var the whole of the preceding
>> group up to that point and the same scope for the expression.  The new
>> var and the expression scope will be the same in any design.
>>
>> Filters still apply to the group but otherwise this is like writing a
>> sub-SELECT (if we allowed * to be used like this:)
>>
>> {
>>   { SELECT * BIND(?o+1 AS ?o1)
>>     {
>>       ?s :p ?o1
>>       GRAPH ?g { ?s ?p ?o }
>>     }
>>   }
>> }
>>
>> In 3LC, it is handled before that where BGPs and property paths are
>> sorted out.
>>
>> Proposal:
>>
>> Restore the approach of the formal section of 1LC and 2LC.
>> Clarify in the description section.
>>
>>     Andy
>>
>> .
>>
>
>

Received on Tuesday, 21 August 2012 16:25:01 UTC