Re: Syntax for custom aggregates

Seaborne, Andy wrote:
> In the grammar [1], I didn’t put in syntax for custom aggregates.  I'm assuming that the ability to be able to specify a URI for an aggregate function is a useful extension point.

This is re: http://www.w3.org/2009/sparql/track/issues/15

Glitter supports this. I'd be surprised if we as a group did not want to 
do this.

> An aggregate in SPARQL is a function that takes a set of query solutions and produces one or more values query solutions which include the group by variables and any aggregate variable/values.  It's "or more" for the case of MIN() returning an answer for the MIN number, the MIN string, MIN dateTime - it would be one row for each possibility for each group.

...which is still an undecided issue from back when we first discussed 
it in May. (See http://www.w3.org/2009/sparql/track/issues/16)

> Two options occur to me for the syntax for aggregates:
> 
> 1/ They look just like function calls:
> 
> SELECT my:aggregate(arg1, arg2, ...) { ... } GROUP BY ?x
> 
> The catch is that the prohibition about aggregates not in the pattern filters can't determined merely by parsing.  The parser needs to know if a call is a function or an aggregate at parse time.
> 
> SELECT my:function(arg1, arg2, ...) { ... } GROUP BY ?x
> 
> The good news is that URI's only name one thing so it should not be a filter function and an aggregate.

This is what Glitter does.

> 2/ They are syntactically distinguished from functions by, for example, a keyword AGG(...)
> 
> SELECT AGG(my:aggregate,arg1, arg2,...)  { ... } GROUP BY ?x
> 
> Or just AGG my:aggregate(arg1, arg2, ....)
> 
> Not as nice looking (??) but aggregates are easily distinguished without needing to look up, or otherwise know, the definitions of the IRI.  An aggregate call is a built-in name COUNT etc or AGG(...)

Eww :-)

Lee

> 
>  Andy
> 
> [1] http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0237.html

Received on Monday, 31 August 2009 18:55:21 UTC