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

Re: another aggregates test case...

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Tue, 08 Jun 2010 15:12:35 +0100
Message-ID: <4C0E4FD3.7040103@talis.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
CC: Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
An alternative model is "null aggregation" so GROUP BY exposes keys only 
which is consistent.

Either is possible as far as I can see - we have a choice we can make 
here because there isn't a specific need for it to be one way or the other.

Related question: do we want composite keys to apply any sort of 

GROUP BY ?v1 ?v2

yield all the same values of ?v1 in adjacent rows:


3 Y
3 X
1 A
1 B
2 C
2 A
2 B


On 08/06/2010 3:04 PM, Andy Seaborne wrote:
> I don't see why it needs to be an error - with no aggregation GROUP BY
> can be considered to be a a partial sort. Cardinality same as without
> GROUP BY. This also happens to be a requirement in some apps - results
> clustered by key but the same number of rows as without grouping.
> Sorting can make it so, but sorting is potentially more expensive.
> Andy
> On 08/06/2010 2:20 PM, Lee Feigenbaum wrote:
>> I would expect this query to be an error, yes.
>> I'd also be happy to define an aggregate query as any query in which:
>> 1. A GROUP BY clause is present, OR
>> 2. An aggregate is included in the query projection
>> Lee
>> On 6/8/2010 9:07 AM, Axel Polleres wrote:
>>> Student of mine pointed me to a somewhat corner test case:
>>> PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>>> PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
>>> PREFIX dcterms:<http://purl.org/dc/terms/>
>>> PREFIX foaf:<http://xmlns.com/foaf/0.1/>
>>> PREFIX mpp:<http://imp.deri.ie/ontology/moviePostProcessing#>
>>> SELECT *
>>> FROM NAMED<http://imp.deri.ie/vff/ppa/projects>
>>> FROM NAMED<http://imp.deri.ie/vff/ppa/people>
>>> WHERE {
>>> ?project rdf:type foaf:Project ;
>>> rdfs:label ?title .
>>> ?person rdf:type mpp:Person ;
>>> rdfs:label ?personName ;
>>> foaf:currentProject ?project .
>>> }
>>> GROUP BY ?project
>>> Actually, I *think* this should be syntactically invalid, as per:
>>> "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."
>>> interestingly, the formulation - strictly speaking - doesn't say what
>>> an aggregate query is, but GROUP BY without aggregtate doesn't make a
>>> lot of sense anyways, except that it should have the same effect as
>>> DISTINCT, right(?), but we still don't want to allow in the presence
>>> of GROUP BY some non-grouped/aggregated things to be projected, I
>>> assume.
>>> Axel
>> Please consider the environment before printing this email.
>> Find out more about Talis at http://www.talis.com/
>> shared innovation™
>> Any views or personal opinions expressed within this email may not be
>> those of Talis Information Ltd or its employees. The content of this
>> email message and any files that may be attached are confidential, and
>> for the usage of the intended recipient only. If you are not the
>> intended recipient, then please return this message to the sender and
>> delete it. Any use of this e-mail by an unauthorised recipient is
>> prohibited.
>> Talis Information Ltd is a member of the Talis Group of companies and is
>> registered in England No 3638278 with its registered office at Knights
>> Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
Received on Tuesday, 8 June 2010 14:20:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:00 UTC