Well in Leviathan (dotNetRDF's engine) I use the pure SPARQL 1.1 syntax approach and a central registry as I am proposing that we may want to add to ARQ
The syntactic extension makes sense and might be a more future-proof design because it allows for late binding of aggregates in the same way that functions are currently late bound. (Not that a central registry for aggregates necessarily precludes late binding a la the existing Function hierarchy) I don't believe there is a JIRA specifically for this so I shall go ahead and add one Rob On 20/10/2014 10:52, "Andy Seaborne" <[email protected]> wrote: >On 20/10/14 10:42, Rob Vesse wrote: >> Andy >> >> I recently put a comment on JENA-507 about this same issue >> >> It would be nice to have some means to be able to inject custom >>aggregates >> without needing to modify the grammar with new tokens (because that >> appears to be the only way to add custom aggregates right now). >> >> It would be nice to have some sort of central registry of custom >> aggregates which the parsers could then simply consult and either output >> an aggregate if explicitly registered as such and otherwise use the >> existing behaviour of assuming a custom function > >In fact, custom aggregates in pure SPARQL 1.1 syntax absolutely need a >registry and it must be available during parsing because whether a URI >is an aggregate or a function affects parsing itself (not the best >feature of SPARQL). It can't be left until execution time nor binding >to a dataset. > >If a syntactic extension is acceptable, AGG(<uri>, args ..) would break >that dependency but both ways are quite doable. > >Is there a JIRA? (from memory there is but I can't remember which and >just at the moment, I'm working semi-offline and search JIRA is >"impractical"). > > Andy > >> >> Rob >> >> On 17/10/2014 15:44, "Joshua TAYLOR" <[email protected]> wrote: >> >>> On Thu, Oct 16, 2014 at 10:39 PM, Ian Emmons <[email protected]> wrote: >>>> the example he gave is an aggregate that would compute the maximum >>>> score of a grouping of hotels based on multiple properties of the >>>>hotels. >>> >>> >>> Things like that are already possible, though. You can do, e.g., >>> >>> select ?hotel (max( (?price+?size)/?distance ) as ?ranking ) where { >>> ?hotel :price ?price ; :size ?size ; :distance ?distance . >>> } >>> group by ?hotel >>> >>> You can do a lot just with SPARQL 1.1., and if you add some custom >>> (non-aggregate) functions in there, you can do even more. Without >>> specifics, it's hard to say, but I wouldn't be entirely surprised if >>> the actual use case is already possible. >>> >>> //JT >>> >>> -- >>> Joshua Taylor, http://www.cs.rpi.edu/~tayloj/ >> >> >> >> >
