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: Polleres, Axel <axel.polleres@siemens.com>
Date: Wed, 23 May 2012 11:40:50 +0200
To: Andy Seaborne <andy.seaborne@epimorphics.com>, "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-ID: <9DA51FFE5E84464082D7A089342DEEE80139B1052F38@ATVIES9917WMSX.ww300.siemens.net>
Thanks Andy,

Both options would have addressed my UNION use case and even if we'd go for Option 1, one could always 
add additional grouping to achieve the same, but I am totally fine to go with Option 2, and/or 
referring in item 12 to some respective text being added in Section 18.2.1. as you suggested.

If we go for that, I'd suggest the following syntax-use cases reflecting my understanding of Option 2:

Positive:
=========

BINDscope1
--------------------------------------
 PREFIX : <http://www.example.org>
 SELECT *
 WHERE {
    :s :p ?o .
    BIND((1+?o) AS ?o1)
    :s :q ?o1
 }
--------------------------------------

BINDscope2
--------------------------------------
 PREFIX : <http://www.example.org>
 SELECT *
 WHERE {
    :s :p ?o .
    :s :q ?o1
    { BIND((1+?o) AS ?o1) }
 }
--------------------------------------

BINDscope3
--------------------------------------
 PREFIX : <http://www.example.org>
 SELECT *
 WHERE {
    { 
    :s :p ?o .
    :s :q ?o1
    }
    { BIND((1+?o) AS ?o1) }
 }
--------------------------------------

BINDscope4
--------------------------------------
PREFIX : <http://www.example.org>
SELECT *
   {
    { BIND (1 AS ?Y) }
     UNION
    { :s :p ?Y }
  }
--------------------------------------

BINDscope5
--------------------------------------
PREFIX : <http://www.example.org>
SELECT *
   {
    { :s :p ?Y }
     UNION
    { BIND (1 AS ?Y) } 
   }
--------------------------------------

Negative:
=========

BINDscope6
--------------------------------------
 PREFIX : <http://www.example.org>
 SELECT *
 WHERE {
    :s :p ?o .
    :s :q ?o1 .
    BIND((1+?o) AS ?o1)
 }  
--------------------------------------

BINDscope7
--------------------------------------
 PREFIX : <http://www.example.org>
 SELECT *
 WHERE {
    {
    :s :p ?o .
    :s :q ?o1 .
    }
    BIND((1+?o) AS ?o1)
 }  
--------------------------------------

BINDscope8
--------------------------------------
PREFIX : <http://www.example.org>
SELECT *
   {
    {
    { :s :p ?Y }
     UNION
    { :s :p ?Z }
    }
    BIND (1 AS ?Y) 
   }
--------------------------------------

Haven't tested them yet with any implementation, but will do and add them on CSV as soon as I find time.

Cheers,
Axel



 
-- 
Dr. Axel Polleres 
Siemens AG Österreich 
Corporate Technology Central Eastern Europe Research & Technologies 
CT T CEE 
 
Tel.: +43 (0) 51707-36983 
Mobile: +43 (0) 664 88550859
Fax: +43 (0) 51707-56682 mailto:axel.polleres@siemens.com 
 

> -----Original Message-----
> From: Andy Seaborne [mailto:andy.seaborne@epimorphics.com] 
> Sent: Wednesday, 23 May 2012 11:13 AM
> To: public-rdf-dawg@w3.org
> Subject: Re: Attemt to tackle in-scope BIND issue (ACTION-618 
> - part 1)
> 
> 
> 
> 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.ht
> > ml
> >
> >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-s
> cope</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:41:24 GMT

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