Re: BIND tests

> > 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 Monday, 24 January 2011 20:47:10 UTC