- From: Steve Harris <steve.harris@garlik.com>
- Date: Tue, 30 Mar 2010 18:40:23 +0100
- To: Andy Seaborne <andy.seaborne@talis.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
On 30 Mar 2010, at 18:32, Andy Seaborne <andy.seaborne@talis.com> wrote: > > > On 30/03/2010 5:59 PM, Steve Harris wrote: >> On 2010-03-30, at 16:52, Andy Seaborne wrote: >>> >>> On 30/03/2010 3:26 PM, Ivan Mikhailov wrote: >>>> Hello Axel, >>> ... >>> >>>>> Would we also allow aggregates with arityy different to 1 (like >>>>> common in functions) e.g. agg-uri(?X ?Y) >>>> >>>> That's absolutely required for statistical calculations of all >>>> sorts, >>>> from regression to likelihood detection. >>>> >>>> Best Regards, >>>> >>>> Ivan. >>> >>> At F2F3, we decided to not restrict the arity to 1 for custom >>> aggregates (and they can have parameters to the aggregator as well >>> as arguments to aggregate over). >> >> We did? It sounds plausible, but I don't actually remember that. Is >> it a parser issue? > > Stats aggregates were the main argument for n-ary custom aggregates. > The whole multiset of tuples is based around it as well. > > Several of the built-ins are 1-ary ; some are n-ary. > (and some I'm not clear about). > > The parser will parse N-ary custom aggregates regardless because a > custom aggregate look, syntactically, exactly like a custom function. > > I don't see why we should not be able to write any built-in as a > custom aggregate. We should give URIs the aggregates we do define. Yeah, sorry I misread your previous post and got the "not" upside down. Custom aggregates are indeed the prime motivator for n-ary aggregates. Long day. >> - Steve
Received on Tuesday, 30 March 2010 17:41:43 UTC