RE: Aggregate extensibility

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 18:51:41 UTC