Re: BIND tests

I'm revisiting this now, and I think I better understand what Andy is 
observing and suggesting.

First: I believe that the wording that Axel offers above does 'fix' the 
issue Andy identified without changing the semantics that the group 
decided upon previously. It is somewhat awkward though.

Next: If we stuck with a group always being { ... } and a BIND only ends 
a BGP but not the group, then I think that we can keep the existing "in 
place" semantics for BIND without losing the query that motivated that 
decision:

  {
    :S :P ?o
    BIND (?o+1 as AS ?o1)
    :S :Q ?o1
  }

The goal of making BIND "in place" was to allow this query, rather than 
have it be an error for binding to ?o1 which is bound in the same group. 
But if BIND ends the BGP and not the group, then the above is

Join(Bind(BGP(:S :P ?o), ?o+1, ?o1), BGP(:S :Q ?o1))

It's ok to bind ?o1 in the Bind(...) operation because ?o1 is not in 
scope there. Yet any filter would still float to outside the group 
(outside the Join(...)).

This would result in bind08 having the same result as bind05 -- since I 
think the bind08 that I committed was not a "desirable" result when we 
first discussed it but instead a side effect, I think this ought to be 
fine. Let's discuss tomorrow, and if we have agreement then I'll change 
the results of bind08 and we can entertain approval of the bind tests.

Lee

On 1/24/2011 3:46 PM, Axel Polleres wrote:
>>> BIND can end a BGP, and that makes entailment work when it's just
>>> "outside the BGP". It can't end a group.
>>
>> Why can't it? Again, I'm not saying I prefer that it does (I advocated
>> the other semantics originally), but I don't understand why this isn't a
>> plausible design choice. SPARQL 1.0 has one way to end a (logical) group
>> - a right-curly brace. SPARQL 1.1 could have two ways (right-curly brace
>> and BIND). Again, i'm not saying I prefer this, but I don't see why it's
>> not an option.
>
>
> Hmmm, looking at Section 5.2 Group Graph Patterns ... Here it says:
>
> "In a SPARQL query string, a group graph pattern is delimited with braces:
> {}."
>
> i.e., if we'd consider that option (I have no preference either, but also no other proposal to resolve
> this problem), we would need to say here that BINDs actually implicitly "splits up" groups...
>
>
> Just as a concrete attempt to do so, could we implement this option by
>
>
>
> 1) adding a subsection right before "5.2.2 Scope of Filters"
> something along the lines of the following text:
>
> ==========================================
>    5.2.2 Group Graph Patterns and BIND
>
>    Note that BIND assignments (see Section 10.1 BIND: Assigning to variables) implicitly split up groups.
>    That is, any Group Graph Pattern that contains a BIND form
>
>      {  ... BIND ( Expr AS Var) ... }
>
>    where the 'BIND' keyword is not preceeded by a group graph pattern only within the same group
>    is to be treated as a shortcut for
>
>      {{ ... } BIND ( Expr AS Var) ... }
> ==========================================
>
> I admit the text is pretty ugly... the line
>
>    "where the 'BIND' keyword is not preceeded by a group graph pattern only within the same group"
>
> is basically needed to avoid that the definition of the shortcut applies "infinitely"
>
> 2) changing in section 10.1 BIND: Assigning to variables from
>
> ==========================================
> The BIND form allows an value to be assigned to a variable in a group graph pattern. Use of BIND
> is a separate element of a group graph pattern and it ends any basic graph pattern, including ending the
> scope of any filters.
> ==========================================
>
>   to
>
> ==========================================
> The BIND form allows a value to be assigned to a variable in a group graph pattern. Use of BIND
> is splits up the group graph pattern as described in Section<a href="...">5.2.2 Group Graph Patterns and BIND</a>  above.
> ==========================================
>
> would that do the trick?
>
> best,
> Axel
>
> On 24 Jan 2011, at 16:19, Lee Feigenbaum wrote:
>
>> On 1/24/2011 11:05 AM, Andy Seaborne wrote:
>>>
>>>
>>> On 24/01/11 15:20, Lee Feigenbaum wrote:
>>>> On 1/24/2011 4:33 AM, Andy Seaborne wrote:
>>>>>
>>>>>
>>>>> On 24/01/11 03:22, Lee Feigenbaum wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> This mail discharged my ACTION-371
>>>>>> (http://www.w3.org/2009/sparql/track/actions/371), to look at the bind
>>>>>> tests.
>>>>>>
>>>>>> I looked over the 7 tests in
>>>>>> http://www.w3.org/2009/sparql/docs/tests/data-sparql11/bind/ and
>>>>>> believed them to be accurate and reasonable coverage of the BIND
>>>>>> keyword.
>>>>>>
>>>>>> I added one new test, bind08, which I believe tests correctly the fact
>>>>>> that BIND occurs _after_ a group is ended, and hence a FILTER appearing
>>>>>> before BIND cannot act on the BINDed variables. This is the test:
>>>>>>
>>>>>> == query ==
>>>>>>
>>>>>> PREFIX :<http://example.org/>
>>>>>>
>>>>>> SELECT ?s ?p ?o ?z
>>>>>> {
>>>>>> ?s ?p ?o .
>>>>>> FILTER(?z = 3 )
>>>>>> BIND(?o+1 AS ?z)
>>>>>> }
>>>>>>
>>>>>> == results ==
>>>>>>
>>>>>> (no solutions)
>>>>>>
>>>>>> Can someone please check the truth of this test? I don't have a BIND
>>>>>> implementation to test this with at the moment. Also, if you feel that
>>>>>> this should not be the semantics of BIND as the WG agreed on a
>>>>>> couple of
>>>>>> months ago, please let us know.
>>>>>>
>>>>>> Once this test has been looked at, I'd like to propose that we approve
>>>>>> these 8 bind tests either this Tuesday or (more likely) one week from
>>>>>> Tuesday.
>>>>>>
>>>>>> Lee
>>>>>
>>>>> Unfortunately, we missed that the WG agreement is at odds with SPARQL
>>>>> 1.0 [1]
>>>>>
>>>>> In SPARQL 1.0, a filter applies to the whole group, where "group" means
>>>>> syntax units between the {}.
>>>>>
>>>>> Andy
>>>>>
>>>>> [1] http://www.w3.org/TR/rdf-sparql-query/#scopeFilters
>>>>>
>>>>> [[
>>>>> A constraint, expressed by the keyword FILTER, is a restriction on
>>>>> solutions over the whole group in which the filter appears.
>>>>> ]]
>>>>
>>>> Well, I think that it's less that it changes that part of SPARQL 1.0 and
>>>> more that it provides a new way to mark the end of the group. (BIND is
>>>> effectively the equivalent of "} {".) Still, it clearly makes for some
>>>> weirdness, which is what bind08 is showing.
>>>>
>>>> We discussed exactly bind08 at
>>>> http://www.w3.org/2009/sparql/meeting/2010-11-02#BIND_and_FILTER_order_execution,
>>>>
>>>> and there was consensus that this is the behavior that we want, so while
>>>> it is a strange new way to mark the end of the group (and start of a new
>>>> group), I don't think it's a decision we ought to revisit now...
>>>
>>> (meta: I'm not advocating a change because I think it's better - I'm
>>> bring this out because in working through the detailed design I came
>>> across this interaction with SPARQL 1.0.)
>>
>> (understood - my meta is that i'm not advocating staying the same
>> because i think it's better - i'm trying to understand what's different
>> from the conversation in october/november)
>>
>>> Group here is not a basic graph pattern. It is (from SPARQL 1.0), the
>>> elements between {}. [2] We did discuss whether it inside or outside a
>>> BGP, but I found another design constraint from SPARQL 1.0.
>>>
>>> The discussion I recall was all about BGPs, and the record seems to
>>> agree and show we were a bit mixed between BGP and syntax groups. We
>>> missed the further implication from SPARQL 1.0.
>>
>> Right, looking back at the minutes and the mailing list, the discussion
>> was pretty muddled.
>>
>>> BIND can end a BGP, and that makes entailment work when it's just
>>> "outside the BGP". It can't end a group.
>>
>> Why can't it? Again, I'm not saying I prefer that it does (I advocated
>> the other semantics originally), but I don't understand why this isn't a
>> plausible design choice. SPARQL 1.0 has one way to end a (logical) group
>> - a right-curly brace. SPARQL 1.1 could have two ways (right-curly brace
>> and BIND). Again, i'm not saying I prefer this, but I don't see why it's
>> not an option.
>>
>>> Test 5 and test 8 must give the same results - as must:
>>>
>>> SELECT ?s ?p ?o ?z
>>> {
>>> FILTER(?z = 3 )
>>> ?s ?p ?o .
>>> BIND(?o+1 AS ?z)
>>> }
>>
>> If we did make this change, I'm trying to figure out what other examples
>> / use cases that people preferred change/break, but I can't seem to
>> figure that out from the minutes and mailing list :(
>>
>> Lee
>>
>>>
>>> Andy
>>>
>>> [2] http://www.w3.org/TR/rdf-sparql-query/#GroupPatterns
>>>
>>>
>>>>
>>>> Lee
>>>>
>>>>
>>>
>>
>>
>
>

Received on Tuesday, 25 January 2011 03:26:53 UTC