Please try out the latest development build.
The JIRA is JENA-803
Example code:
https://github.com/apache/jena/blob/master/jena-arq/src-examples/arq/examples/aggregates/CustomAggregate.java
Andy
On 20/10/14 11:31, Rob Vesse wrote:
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)
Because whether a form is a custom function or an aggregate affects the
generated query syntax tree (a choice, sort of) and the algebra
generated (no choice), whether a form is a aggregate or a function call
must be known.
In theory, it is possible to differentiate if GROUP is used but this
example shows a case where it is simple not possible to tell from the
query alone.
// May be a custom aggregate - group is the whole result set
// May be a custom function - no grouping.
SELECT (<uri1>(?s) AS ?xs) { ... }
So they must be predeclared, or using the extended syntax
"AGG <uri>(...args...)" at the moment.
If not declared, the query will have a function call in it.
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/
