Re: GROUP question

I agree with your reading. Question to all: Is that what we want?
Case distinction on the implications of answering "Yes" and "No" to this question:

No: In case we *don't* want this, we'd need to adapt bullet 10 of [1]
    as follows: 
 "P = { P1 } GROUP BY E1 ... En such that either there is an Ei of the form ?v or (E AS ?v) 
                             *or ?v is potentially bound in P1*"
 but that would seem unnatural in terms of the intuitive meaning of "potentially bound".

Yes: However, thinking out loud, I am a bit worried that in case we *do* want this, it might become arguable 
     why - on the other hand - we disallow

 SELECT ?Item (?Price * 1.1 AS ?Price)
 WHERE { ?Item :hasPrice ?Price }

I am hesitant to  really reopen this... though just, in case we also wanted to allow the latter we'd consequently need to drop the restriction on "15.1.2 SELECT expressions" to potentially bound variables alltogether: "The new variable is introduced using the keyword AS; it must not already be potentially bound." 

Even if we did drop that restriction, the definition [1] still makes sense to disambiguate the meaning of "*" in Section "14.1.1 Projection"which now ambiguously says "The syntax SELECT * is an abbreviation that selects all of the variables that could be bound in a query." ... remarkably as opposed to what Step 7 in Section "17.2.3 Converting Solution Modifiers" says, i.e. "all named variables in the query if SELECT * used"
I'd assume we resort to "potentially bound" for the definition of "*"?



On 14 Oct 2010, at 07:06, Andy Seaborne wrote:

> Just checking - this going to be legal, isn't it?  It's an idiom that seems natural and people do use it:
> {
>  ... ?x ...
> } GROUP BY ?groupKey
> In other words, can I use ?x as a new variable because the inner one is hidden by the group.  It seems a natural thing to write in the SAMPLE case.
> From wiki/Potentially_bound it seems the answer is yes.  ?x is not potentially bound when used at the point "AS ?x"
> The ?x in SAMPLE(?x) is a different ?x because aggregates happen before select expressions in modifier order.
> The ordering is:
> # Grouping
> # Aggregates
> # Select expressions
> # Having
> ...
> and so
> # Aggregates
> ... at this point only GROUP BY vars + aggregates are visible. [1]
> # Select expressions
> [1] minor: and so the aggregates are assigned to temporary vars to be renamed in the select expressions?  Can't see how else it would work.
> 	Andy

Received on Thursday, 14 October 2010 10:34:11 UTC