- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Wed, 09 Jun 2010 10:23:46 +0100
- To: Steve Harris <steve.harris@garlik.com>
- CC: Lee Feigenbaum <lee@thefigtrees.net>, Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
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