- From: Axel Polleres <axel.polleres@deri.org>
- Date: Mon, 29 Mar 2010 22:33:05 +0100
- To: Orri Erling <erling@xs4all.nl>, SPARQL Working Group <public-rdf-dawg@w3.org>
Hi Orri, could you give me an example of a non-commutative aggregate? At the moment, the definition of aggregates is based on ExpressionMulti*Sets* not sequences, so at this point I understand that only commutative aggregates would fit that definition. Axel On 29 Mar 2010, at 19:51, Orri Erling wrote: > > > Hi > > > Based on our experience of custom aggregates in SPARQL, it has proven useful > to also specify whether order should be preserved. That is, if the > aggregate is over a subquery with a top k order by, and the aggregate has > semantics of concatenation of results, then the aggregate should not lose > order of results even if it consolidated results from many partitions on a > cluster. Therefore the declaration of a custom aggregate should be able to > express whether the aggregation operation is commutative, i.e. whether it > cares about the order of incoming data. Of course most aggregates are > insensitive too this. On the SQL side there are order sensitive aggregates > that run over windows of consecutive values. So it will be informative to > look at Oracle or MS SQL Server manuals for how they support declaring > windowing and order sensitivity in user aggregates. If it is good for them > it is likely good for us. > > > > > Orri > > > -----Original Message----- > From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org] > On Behalf Of Axel Polleres > Sent: Friday, March 26, 2010 1:07 PM > To: SPARQL Working Group > Subject: Aggregate extensibility > > To close ISSUE-15 it looks to me like we probably should have a section > "Aggregator extensibility" analogous > to the existing "Operator Extensibility" section in the doc. Just a quick > list of what aggregate extensibility > seems to need to consider: > > Any new agregate should probably handle the following questions: > > * agg-uri(*) how/whether the aggregate treats rows? > * agg-uri(?X) i) how/whether to treat errors ii) how/whether to treat > unbounds? > * Would we also allow aggregates with arityy different to 1 (like common > in functions) e.g. agg-uri(?X ?Y) > * Is it necessary to define agg-uri( DISTINCT * ), agg-uri( DISTINCT > parameters ) separately, or do we asume this implicitly for ALL built-ins? > > Axel > >
Received on Monday, 29 March 2010 21:33:40 UTC