RE: SPARQL Query - third last call

All fine, just one last thing:

[[
Variables introduced by <code>AS</code> in a <code>SELECT</code> clause must not already be <a href="#variableScope">in-scope</a>.
]]

I would prefer to make this more explicit, because "already be in-scope" isn't clear in terms to what  "aleady" refers to. Would the following work for you?

[[
Variables introduced by <code>AS</code> in a <code>SELECT</code> clause must not already be <a href="#variableScope">in-scope</a>, i.e., within SELECT clauses of the form
  '<code>SELECT ... (Expr AS v ) ...  { P }</code>'
the variable <code>v</code> must neither be in-scope within the SELECT clause before  '<code>(Expr AS v )</code>' nor within <code>P</code>.
]]


Thanks again for all your work!
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: Tuesday, 10 July 2012 3:06 PM
> To: public-rdf-dawg@w3.org
> Subject: Re: SPARQL Query - third last call
>
>
>
> On 10/07/12 12:48, Polleres, Axel wrote:
> > Hi Andy, all
> >
> > (this is in completion of ACTION-641)
> >
> > I'm finally - sorry sorry for the delay again - looking
> into the discussion we had around BIND-Scope, and have the
> following comments/questions:
> >
> > --------------------------------------------------------------------
> >
> > 1) This one is minor/editorial:
> >
> >
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012AprJun/0160.ht
> > ml doesn't seem to have a reply yet. (I had a minor final editorial
> > comment to the table in 18.2.1 There suggesting to leave out the
> > "Group" keyword (as it's really not a keyword), or, if you want to
> > leave "Group" at least shorten the describing text in
> accordance with
> > the other rows
> >
>
> I think the {} needs explaining.
>
> I have made the word group not in code font.
>
> Elsewhere the text says "in-scope in P" so I think the
> current wording is best.
>
> > --------------------------------------------------------------------
> >
> > 2) This one is a question for clarification only:
> >
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012AprJun/0159.ht
> > ml You seemed to agree on Option 2 here, but your text now reads
> > slightly different than my suggested text.
>
> BIND applies to the TriplesBlock, not the whole of the
> preceding group I did not find anything else that made sense.
>
> More below.
>
> >
> > ----------------------------------
> >>
> >> 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".
>
> but, on detailed work, it didn't work out.
>
> 1/ It's unnecessarily restrictive
> 2/ It's at odds with scoped bottom up evaluation (see next)
> 3/ join is not (syntactically) commutative ...
>
> >>
> >> ----------------------------------
> >
> > You now write:
> > "
> > The variable assigned in a BIND clause must not be already in-use
> > within the immediately preceeding TriplesBlock within a
> > GroupGraphPattern. "
> >
> > I suppose the small difference between my wording
> suggestion and yours
> > is the sema reason as the one why you disagreed with test-cases
> > bind-scope 7 and 8... If that is the reason (pls confirm),
>
> .. the tests involve subpattern (sub-group) nesting.
>
> The design makes scoping proper otherwise nested and flat
> queries behave differently (one is illegal) for no good
> reason whatsoever.
>
>  > then I also better understand why you disagreed with those
> test cases
> --> fine by me!
>
> >
> > --------------------------------------------------------------------
> >
> > 3) This one is IMO important: I have one last question about the
> > current item 12
> >
> > "
> > Expressions used in SELECT clauses must only use in-scope
> variables.
> > This only applies to expressions used on the left-hand side of AS.
> > "
> >
> > I am both unsure whether this is clearly defined, nnor
> whether we actually need to limit this? Wouldn't variables
> not in-scope within expressions just be unbound? E.g., what
> speaks against:
> >
> >     SELECT (bound(?X) AS ?B)
> >     WHERE {}
> >
> > Particularly, since it seems we could equally write
> >
> >     SELECT ?X (bound(?X) AS ?B)
> >     WHERE {}
> >
> > Where, according to the in-scope definition, ?X is in-scope.
>
> The text is merely pointing out that it SELECT expressions
> (not FILTER or BIND ones).
>
> Actually, it's unnecesary - removed and replaced by ...
>
> >
> > So, I have an alternative suggestion:
> >   Didn't we rather want to limit the variables on the
> *right-hand-side* of 'AS' to be *not* already in-scope? That
> is, wouldn't we rather want to limit the usage of variables
> in SELECT clauses as follows:
> >
>
> Separate issue - worth pointing out though.  Change made.
>
>
> > "
> > Within SELECT clauses of the form
> >      SELECT ... (Expr AS v ) ...  { P } the variable v must
> neither be
> > in-scope within the SELECT clause before  '(Expr AS v )'
> > nor within P
> > "
> >
> > ? If you agree, I suggest to change item 12 accordingly.
> >
>
> [[
> Variables introduced by <code>AS</code> in a
> <code>SELECT</code> clause must not already be <a
> href="#variableScope">in-scope</a>.
> ]]
>
> > --------------------------------------------------------------------
> >
> >
> > That is, in summary, I understood
> > we want to prohibit
> >
> >     SELECT ?X (Expr AS ?X) { ?P }
> >
> > or, respectively,
> >
> >      SELECT ?Y (Expr AS ?X) { ?Y :p ?X }
> >
> > but we don't want to prohibit
> >
> >      SELECT (Expr AS ?X) (?X AS ?Y) { P }
> >
> > Yes?
>
> Yes.
>
> Have you tried the validator?
>
>       Andy
>
> >
> > Sorry again for the late feedback.
> >
> > Axel
>
>

Received on Tuesday, 10 July 2012 13:15:29 UTC