W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

Re: ungrouped variables used in projections - Further implications?

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Thu, 26 Aug 2010 15:29:46 +0100
Message-ID: <4C767A5A.8040802@epimorphics.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:43 GMT