Re: Aggregate extensibility

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