[jira] [Comment Edited] (JENA-507) Add support for Leviathan extension functions to ARQ

["Rob Vesse (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JENA-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165219#comment-14165219 ] 

Rob Vesse edited comment on JENA-507 at 10/9/14 3:03 PM:
---------------------------------------------------------

Finally had time to get back to this, I have all the extension functions now implemented though not necessarily tested.

One issue I ran into was that some of the Leviathan URIs have local name parts that aren't valid as Java class names so I implemented some simple escaping logic in the {{Loader}} class which deals with this.

For example when it encounters the {{<http://www.dotnetrdf.org/leviathan#degrees-to-radians>}} function it would be mapped to the Java class {{degreesToRadians}} within whatever Java package the Leviathan function namespace had been defined e.g.

{noformat}
http://example.org/ns#invalid-java-class => invalidJavaClass
{noformat}

Essentially the escaping scheme just examines each character and if it is not valid in a Java class name ignores it and instead upper cases the next valid character leading to a camel case style final class name.  In the case where the very first character of the name is invalid the prefix {{F_}} is used instead e.g.

{noformat}
http://example.org/ns#1foo => F_foo
{noformat}

One outstanding issue is if (and how) to also implement the extension aggregates that Leviathan defines, as far as I can tell there isn't a way to introduce custom aggregates at this time since they would just be treated as extension functions by ARQs parser.  I guess we could get around this by adding a registry for extension aggregates so that the parsers could detect the difference (or alternatively this could be done at the algebra compilation stage or by the query itself when calling {{getAggregators()}}).  Anyone else have any thoughts on this?


was (Author: rvesse):
Finally had time to get back to this, I have all the extension functions now implemented though not necessarily tested.

One issue I ran into was that some of the Leviathan URIs have local name parts that aren't valid as Java class names so I implemented some simple escaping logic in the {{Loader}} class which deals with this.

For example when it encounters the {{<http://www.dotnetrdf.org/leviathan#degrees-to-radians>}} function it would be mapped to the Java class {{degreesToRadians}} within whatever Java package the Leviathan function namespace had been defined e.g.

{noformat}
http://example.org/ns#invalid-java-class => invalidJavaClass
{noformat}

Essentially the escaping scheme just examines each character and if it is not valid in a Java class name ignores it and instead upper cases the next valid character leading to a camel case style final class name.  In the case where the very first character of the name is invalid the prefix {{F_}} is used instead

One outstanding issue is if (and how) to also implement the extension aggregates that Leviathan defines, as far as I can tell there isn't a way to introduce custom aggregates at this time since they would just be treated as extension functions by ARQs parser.  I guess we could get around this by adding a registry for extension aggregates so that the parsers could detect the difference (or alternatively this could be done at the algebra compilation stage or by the query itself when calling {{getAggregators()}}).  Anyone else have any thoughts on this?

> Add support for Leviathan extension functions to ARQ
> ----------------------------------------------------
>
>                 Key: JENA-507
>                 URL: https://issues.apache.org/jira/browse/JENA-507
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: ARQ
>            Reporter: Rob Vesse
>            Assignee: Rob Vesse
>              Labels: extension, functions, sparql
>   Original Estimate: 336h
>          Time Spent: 4h
>  Remaining Estimate: 332h
>
> The Leviathan Function library is a set of extension functions present in dotNetRDF's SPARQL engine.  It contains a useful set of numeric functions which would be useful to have available in core ARQ and would boost portability of queries between ARQ and dotNetRDF (note that dotNetRDF already supports ARQs extension functions).
> See https://bitbucket.org/dotnetrdf/dotnetrdf/wiki/DeveloperGuide/SPARQL/Leviathan%20Functions for definition of functions
> Note that some of these overlap with new XPath 3 functions but for portability purposes there is no reason not to support these as well since most are relatively trivial to implement.  I will file a separate issue for supporting XPath 3 functions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)