Re: ungrouped variables used in projections

On 8/24/2010 5:37 PM, Steve Harris wrote:
> On 2010-08-24, at 21:01, Lee Feigenbaum wrote:
>
>> On 8/24/2010 1:09 PM, 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:
>>
>> Hi everyone,
>>
>> I think that we resolved this question in favor of it being an error back on November when we closed ISSUE-11. (See http://www.w3.org/2009/sparql/meeting/2009-11-17#resolution_2 .)
>>
>> It's unclear from the minutes what prompted this conversation. Is there new information about this topic? If so, could someone please share it on the list or point to it in the minutes? (I looked but couldn't discern it.) Otherwise, I suggest we stick with our resolution and spend our time on other topics.
>
> That is also my understanding. I don't believe there's substantial new information.
>
> One thing that was unknown when that decision was taken (if I remember correctly), was whether we would allow grouping by expressions, or just variables. I don't think that has a significant bearing on the decision though.

Right. When we closed ISSUE-11, we referenced ISSUE-41 about whether 
expressions were allowed in GROUP BY and noted the 2 were closely 
related. So I still don't think this is anything new, as it's something 
we talked about and considered when resolving 11.

> I do think Axel's wording is less ambiguous though, I'll incorporate it into the text.

Cool.

Lee

>
> - Steve
>
>>> 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 Wednesday, 25 August 2010 00:42:23 UTC