Re: another aggregates test case...

On 09/06/2010 10:08 AM, Steve Harris wrote:
>> which leads me to a fairly natural interpretation of
>> >
>> >  SELECT ?s ?p
>> >  {
>> >     ?s ?p ?p
>> >  } GROUP BY ?s ?p
>> >
>> >  as "null aggregation"
> I don't understand the term "null aggregation".

It is a term earlier in the thread to capture the idea that SELECT/GROUP 
with no aggregators mentioned fitted into the current framework with an 
implicit aggregator that did nothing.



>
>>>> >>>  Seems useful in developing queries and makes aggregation reasonably orthogonal to grouping.
>>>> >>>
>>>> >>>  SELECT * means all the keys (i.e. variables in scope after grouping)
>>> >>
>>> >>  That seems fairly rational/sensible, but a significant departure from the meaning of * in non-aggregated queries.
>> >
>> >  For me, it's the natural meaning of "*" in "SELECT *" is all visible variables.  That covers SPARQL 1.0, subqueries and grouping. It is also the same algorithm for a syntax check of scoping GROUP BY and SELECT as above but maybe I don't understand that properly.
> Sure, I think it's rational, it's just that * is defined differently in SPARQL 1.0: "SELECT * is an abbreviation that selects all of the variables in a query".
>
> We can define it in a way where it has the same behaviour as it did in 1.0 though, I'm sure.

In SPARQL 1.0, there isn't a way to hide variables.  There is in 1.1 
(projection in sub-queries, aggregation hides non-group variables, free 
variables in MINUS don't contribute, maybe others as well).

	Andy

Received on Wednesday, 9 June 2010 09:24:16 UTC