W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2012

BIND Issue

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 21 Aug 2012 12:45:58 +0100
Message-ID: <503374F6.5080808@epimorphics.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
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 11:46:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:49 GMT