RE: BIND Issue

(Still trying to get my head around this...)

I am in principle in favor of Andy's proposal - sounds like more intuitive than at BGP only
Level - if I understand it correctly that the proposal is to extend the scope of BIND
to the group it is part of from only the BGP.

> But the 1LC and 2LC BIND definition had some other
> undesirable side effect, that was less of a corner case,
> IIRC. Didn't we change it because of a comment?

Unfortunately, I can't really remember the details of this change from the top of my head,
but isn't one problem rather that at the moment we haven't defined what
"the preceding group up to that point" means, i.e. we have to end the group
graph pattern there, right? Would this cause potential intereference with
FILTERs appearing in the same group?

Best,
Axel


> -----Original Message-----
> From: Steve Harris [mailto:steve.harris@garlik.com]
> Sent: Dienstag, 21. August 2012 13:50
> To: Andy Seaborne
> Cc: SPARQL Working Group
> Subject: Re: BIND Issue
>
> On 2012-08-21, at 12:45, 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.
>
> But the 1LC and 2LC BIND definition had some other
> undesirable side effect, that was less of a corner case,
> IIRC. Didn't we change it because of a comment?
>
> - Steve
>
> --
> Steve Harris, CTO
> Garlik, a part of Experian
> +44 7854 417 874  http://www.garlik.com/
> Registered in England and Wales 653331 VAT # 887 1335 93
> Registered office: Landmark House, Experian Way, Nottingham,
> Notts, NG80 1ZZ
>
>
>

Received on Tuesday, 21 August 2012 12:06:45 UTC