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

Re: Attemt to tackle in-scope BIND issue (ACTION-618 - part 1)

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 23 May 2012 10:12:33 +0100
Message-ID: <4FBCAA01.4070902@epimorphics.com>
To: public-rdf-dawg@w3.org


On 23/05/12 08:04, Polleres, Axel wrote:
> Dear all,
>
>
> I'd like to first tackle the issue around BIND, I'll write some more
> suggestions on the definition of "in-scope" in a separate mail
>
> As per
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012AprJun/0120.html
>
>I think that there was some problem about the definition of in-scope > 
with BIND.
>
> item 12. in
> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#sparqlGrammar
> currently says:
>
> " *   The variable assigned in a BIND clause must not be already<a
> href="http://www.w3.org/TR/sparql11-query/#variableScope">in-scope</a>.
>
>
"
>
> which I think was a bit unclear, since the meaning of "already" in
> scope wasn't clear. I have two alternative suggestions to go forward
> here:
>
> --------------------------------------------------------------------
>
> Option 1: ---------
>
> Disallow variable being in-scope for the whole group where the BIND
> clause appears in:
>
> That could be addressed by changing item 12 as follows:
>
> *   The variable assigned in a BIND clause must not be already<a
> href="http://www.w3.org/TR/sparql11-query/#variableScope">in-scope</a>
> in the same group the BIND clause appears in if the BIND clause was
> dropped. That is, if BIND (Exp as V) appears in a pattern  {  P1 BIND
> (Exp as V) P2 }, then v must not be<a
> href="http://www.w3.org/TR/sparql11-query/#variableScope">in-scope</a<http://www.w3.org/TR/sparql11-query/#variableScope">in-scope</a>
> >  in { P1 P2 } .
>
> --------------------------------------------------------------------

-1

One of the use cases is this example of doing a calculation and reusing
it in a group:

SELECT *
WHERE {
   :s :p ?o .
   BIND((1+?o) AS ?o1)
   :s :q ?o1
}

>
> Option 2: ---------
>
> Disallow variable being in-scope in the semegroup, but only before
> the BIND clause appears: That could be addressed by changing item 12
> as follows:
>
> *   The variable assigned in a BIND clause must not be already<a
> href="http://www.w3.org/TR/sparql11-query/#variableScope">in-scope</a>
>
>
within the pattern in the same group before the BIND clause. That is, if 
BIND (Exp as V) appears in a pattern
> {  P1 BIND (Exp as V) P2 }, then v must not be<a
> href="http://www.w3.org/TR/sparql11-query/#variableScope">in-scope</a<http://www.w3.org/TR/sparql11-query/#variableScope">in-scope</a>
> >  P1.
>
>
> --------------------------------------------------------------------

+1 to this option.  This is the intention because of the use case above 
and the wording about "ends a BGP".

> It seems actually, that both versions resolve the issue and it seems
> that Option 1 and 2 are somewhat equivalent, since we also write that
> "BIND ends the basic graph pattern", right?

Not by your wording in option 1 because the definition is based on 
syntax: forbidding

{  P1 BIND (Exp as V) P2 }

is across the whole group, not the BGP ended at BIND, which is option 2, 
right?

I think we need to make the point in 18.2.1, and leave point 12 as 
mainly a link to the full text.

Suggestion:

add text to say that for:

{ P1 BIND (expr AS v) P2 }

v must not be in-scope in P1.


> (Although I couldn't
> really find where that was actually reflected in the semantics
> definition, or is this implicit in the algorithm in Section "18.2.2.6
> Translate Graph Patterns"?)
>
> Best, Axel

	Andy
Received on Wednesday, 23 May 2012 09:13:27 GMT

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