- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Tue, 08 Jun 2010 10:12:04 -0400
- To: Andy Seaborne <andy.seaborne@talis.com>
- CC: Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
On 6/8/2010 10:04 AM, 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. This sounds like a pretty different model of aggregation then we have now. (Actually sounds similar to the model that was proposed on the comments list a few months ago.) If we went this way, why not do this all the time, and just repeat the values for the aggregate calculations? I prefer to keep the existing aggregate model. Lee > > 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:41:49 UTC