Re: ungrouped variables used in projections

BTW, that closes ACTION-302.

On 24 Aug 2010, at 18:09, Axel Polleres wrote:

> We couldn't really find consensus on the issue of ungrouped variables used in projections in aggregate queries in today's call. I volunteered to summarise my currnet understanding of the different positions:
> 
> The issue is exemplified by the following query:
> 
> SELECT ?N COUNT(?P1) WHERE { ?P name ?N; knows ?P1 } GROUP BY ?P
> 
> 1) The current spec seems to be clear about this case...
> 
> "In aggregate queries and sub-queries only expressions which have been used as GROUP BY 
> expressions, or aggregated expressions (i.e. expressions where all variables appear 
> inside an aggregate) can be projected."
> 
> ... suggesting that it is an error.
> 
> An alternative handling would be to 
> 2) treat the non-grouped variables as unbound (I think that's what Andy suggested)
> 3) or leave the behavior to the implementation (I think that would be least favorable, increasing 
>   ambiguity of the language and allowing to do anything)
> 
> 
> An argument raised against 1) in favor of 2) was that we'd raise an error on an - otherwise syntactically correct - query, which might be considered awkward, and hard to implement for parsing, essentially needing to respect the context for parsing.
> 
> Note that we have a similar behaviour (needing a context-aware parser) already in forbidding bnodes being shared among patterns:
> "When using blank nodes of the form _:abc,  labels for blank nodes are scoped to the basic graph pattern.  A label can be used in only a single basic graph pattern in any query."
> 
> If I understood correctly, Andy was arguing that checking reuse of bnodes was easier since the 
> scope doesn't play a role, as apposed to GROUP BY. (More detailed explanation here appreciated.)
> 
> We had a strawpoll which ended as follows:
> 
>  Should ungrouped variabled in project expressions generate an error?
>  +1: 6 0: 6 -1: 0
> 
> no objections, but when I asked whether among the supporters anyone would object against NOT flagging an error, Souri said he'd probably object.
> 
> Summarising, that lets me lean towards forbidding projection, unless we get new information. 
> 
> As a side remark, note that the current wording is not precise:
> 
> "In aggregate queries and sub-queries only expressions which have been used as GROUP BY 
> expressions, or aggregated expressions (i.e. expressions where all variables appear 
> inside an aggregate) can be projected."
> 
> Note that this does not cover the following case:
> 
> SELECT (?N AS ?New) COUNT(?P1) WHERE { ?P name ?N; knows ?P1 } GROUP BY ?P
> 
> Thus, in case we stick with the general understanding of 1) I would suggest to reword:
> 
> "In aggregate queries and sub-queries variables that appear in the query pattern, but are not grouped by 
> cannot be projected nor used in project expressions."
> 
> In case we adopt 2) we should probably still say something about this case, maybe illustrate it with an example:
> 
> "In aggregate queries and sub-queries variables that appear in the query pattern, but are not grouped by 
> are unbound outside the query pattern. For instance, (add an example)"
> 
> 
> Opinions welcome!
> 
> best,
> Axel
> 
> 
> 
> 
>

Received on Tuesday, 24 August 2010 17:14:51 UTC