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

Re: Aggregate extensibility

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 30 Mar 2010 18:40:23 +0100
Message-Id: <C6D2312F-EDD9-4066-B330-026B0C8A49F9@garlik.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:42 GMT