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

Re: Aggregate extensibility

From: Axel Polleres <axel.polleres@deri.org>
Date: Mon, 29 Mar 2010 22:33:05 +0100
Message-Id: <7F6266E9-DA02-481E-8F79-60AC90D3B523@deri.org>
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.


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

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