- From: Polleres, Axel <axel.polleres@siemens.com>
- Date: Tue, 5 Jun 2012 17:06:59 +0200
- To: "birte.glimm@uni-ulm.de" <birte.glimm@uni-ulm.de>, "andy.seaborne@epimorphics.com" <andy.seaborne@epimorphics.com>
- CC: "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
FWIW, on a quick strawpoll on today's telco on the issue we got 4 x +1 to disallow nested aggregates and 2 x 0 (not sure/not swapped in) 1 x 0 no preference either way Best, Axel -- Dr. Axel Polleres Siemens AG Österreich Corporate Technology Central Eastern Europe Research & Technologies CT T CEE Tel.: +43 (0) 51707-36983 Mobile: +43 (0) 664 88550859 Fax: +43 (0) 51707-56682 mailto:axel.polleres@siemens.com > -----Original Message----- > From: Birte Glimm [mailto:birte.glimm@uni-ulm.de] > Sent: Tuesday, 5 June 2012 5:00 PM > To: Andy Seaborne > Cc: public-rdf-dawg@w3.org > Subject: Re: Nested Aggregate Expressions > > [snip] > >>> One line of argument is that the expression inside the > aggregate is > >>> applied to each row, so only row variables should be > considered in-scope. > >>> The aggregate AVG(max(?x)+1) is violating that as > max(?x) is not a > >>> per-row expression. > > > > (Birte) - yes this needs clarifying if we wish to rule it out, and > > possible even if we don't. > > > > As the spec stands, I *think* it says its not allowed: > > > > [[ > > Definition Group: > > > > Group evaluates a list of expressions against a solution > sequence ... > > ]] > > > > and the solution sequence is the grouped patterns, not after > > aggregation or select expressions. > > > > [[ > > Definition: Aggregation > > ]] > > talks about applying the aggregate to the solution > sequences collected > > into a map of key to multiset. > > > > i.e. the aggregate is evaluated over the pattern, not other > aggregates > > and not select expressions > > I think the definition just cannot handle the current case, > but it is not forbidden, just undefined. IMO, either the > definition has to be extended or the current case has to be > forbidden. Maybe it is illegal due to some hidden > constraints, but that should be made exlicit. > > Birte > > > Steve - opinion? > > > > > > > >>> > >>> > >>> What ARQ does is to calculate the aggregates of a group > as the group > >>> streams past; it does not wait until the end of evaluation of the > >>> whole block when all the elements of all the groups are known. > >>> > >>> > >>> Related to this is the interaction with select expressions: > >>> > >>> SELECT (max(?x) As ?M) (avg(?M+1) AS ?A) > >>> > >>> because the select expression rules say you can use ?M > inside AVG(). > >>> > >>> If we wish to forbid this, we can do it quite easily by having a > >>> parser rule that aggregates can't appear in expression for the > >>> aggregate, which is a simple static check. > >> > >> > >> Oh boy, it's certainly wacky. > >> > >> That parse rule wouldn't rule out the use of ?M above > though anyway, > >> would it? > > > > > > Complicated :-) > > > > As I read the spec, the ?Ms are different. > > > > (max(?x) As ?M) -- select expression > > > > avg(?M+1) -- undefined variable in the grouped pattern that > is never > > mentioned or bound. > > > > Like writing > > > > avg(?noSuchVariable+1) > > > > ----- > > > > Turning this round: > > > > Does any one have a use case that suggests it should be legal? > > > > Andy > > > >> > >> - Steve > >> > > > > > > -- > Jun. Prof. Dr. Birte Glimm Tel.: +49 731 50 > 24125 Inst. of Artificial Intelligence Secr: +49 731 > 50 24258 University of Ulm Fax: +49 > 731 50 24188 > D-89069 Ulm > birte.glimm@uni-ulm.de Germany > >
Received on Tuesday, 5 June 2012 15:07:31 UTC