- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Thu, 26 Aug 2010 15:29:46 +0100
- To: Steve Harris <steve.harris@garlik.com>
- CC: Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>, Lee Feigenbaum <lee@thefigtrees.net>
>>> So, why not just doing just that and forbidding expressions in GROUP
>>> BY in the grammar already?
>>
>> We already made a decision to do that I believe.
>
> As I recall (and I can't find the record,maybe more an informal
> discussion with consensus), we agreed not to have AS in GROUP BY to name
> expressions used as grouping. There's no technical reason not to allow
> this:
>
> GROUP BY (?o1+?o2 AS ?o3) , ?x
>
> and gives a name to the expression value for the group. We could be
> consist with SELECT expressions and go so far as to require the AS is an
> expression is used.
>
> It would change the
> Group(ExprList, Ω)
> to be
> Group(VarList, Ω)
>
> We could be consistent with SELECT expressions and go so far as to
> require the AS is an expression is used.
Just for completeness:
I have seen users expecting this to work:
SELECT (count(*) AS ?c)
{
...
}
GROUP BY ?x
HAVING (?c>45)
that is, using a named expression from the SELECT expression in the
having. The modifiers to a SELECT put the filter for having after all
the project expressions, it works (and help avoid multiple calculations
of aggregates).
group + calc aggregates
select expressions
filter (for having)
order by
project
distinct/reduced
offset
limit
The use for
HAVING (count(*)>45)
is when you don't want to expose the value of count(*) as a binding.
Andy
Received on Thursday, 26 August 2010 14:30:35 UTC