RE: BIND Issue

> It seems logical to me that whatever comes
> before the BIND is available for the BIND expression.

IIUC, what we are talking about is the details of
what "whatever comes before the BIND" implies, i.e.

A) whatever comes before the BIND *within the same BGP*
Or
B) whatever comes before the BIND *within the same Group*

Where the suggested change is to switch from A) to B), yes?

Axel


> -----Original Message-----
> From: Matthew Perry [mailto:matthew.perry@oracle.com]
> Sent: Dienstag, 21. August 2012 14:44
> To: public-rdf-dawg@w3.org
> Subject: Re: BIND Issue
>
> I would be strongly in favor of the 1LC and 2LC approach.
> That is what we do. I somehow missed that the semantics had
> changed in 3LC. It seems logical to me that whatever comes
> before the BIND is available for the BIND expression.
>
> Cheers,
> Matt
>
> On 8/21/2012 8:19 AM, Andy Seaborne wrote:
> >
> >
> > On 21/08/12 12:50, Steve Harris wrote:
> >> 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?
> >
> > 1LC and 2LC weren't very clear especially in the
> descriptive section. The idea was to be clear and with
> minimal impact.  3LC does not seem to have been "minimal
> impact" because of the expression scoping.
> >
> > The only formal comment I can find is about a different
> matter (DB-8).
> >
> > You might be remembering my "comments" that it was unclear,
> based on user feedback. It wasn't specifically about the
> design, just it was not clear.
> >
> > What do current implementations do?  We can usefully be
> guided by those given the widespread implementation of SPARQl
> 1.1 already.
> >
> >     Andy
> >
> >>
> >> - Steve
> >>
> >
>
>
>

Received on Tuesday, 21 August 2012 12:54:03 UTC