Once the machinery for one language is there, adding other is easy if
the language has a javax.script.ScriptEngineManager (JSR 223). Groovy
does. That means the custom functions can be loaded and run without
the static compile/load steps for the customisations needed to get
stuff into the server jar. Just ensure the language is on the
classpath.
You can call java from javascript in nashorn; it does some nice
idiomatic stuff like "obj.getProp()" is "obj.prop". And being highly
dynamic with reflection, a bit difficult to trace mistakes!
It is only a bit more complicated to create java objects but you can
do that too.
Andy
On 8 September 2017 at 00:04, Bruno P. Kinoshita
<brunodepau...@yahoo.com.br.invalid> wrote:
> Maybe Groovy could be an option as well? I like the idea of being able to
> customize Jena with Groovy + Grape's.
> Whenever I use JavaScript I always rely on a few dependencies (e.g.
> moment.js). If we allowed users to grab extra dependencies with npm that
> would work as well I think.
>
> In Jenkins, you can customize the server behaviour, and automate pretty much
> everything with Groovy. There is a Groovy console, and a few extension points
> where you can plug in Groovy code. The main advantage being that there is no
> translation between Groovy/Java objects. You simply call the Java objects
> from within Groovy. Which means we could even call utility classes and
> methods I think.
>
> Bruno
>
> From: Andy Seaborne <a...@apache.org>
> To: users@jena.apache.org
> Sent: Friday, 8 September 2017 1:20 AM
> Subject: Re: SPIN support
>
> The nice things about JS functions it allows extension without java
> programming, whether writing the custom function in java or having to
> rebuild Fuseki to get the java code in. war files and jar+dependencies
> (run with -jar) are sealed. And it isn't as hard as embedded Java like
> JSPs.
>
> Just restricting the thoughts to SPARQL functions in JS - list of args
> in, single value out. (So not property functions, not modifying the
> graph data itself.)
>
> I came up with 3 different designs of the function calling model based
> on what is passed in.
>
> 1/ Pass in JS values - strings, numbers, booleans, null.
>
> Convert the function arguments as passed in from SPARQL into JS native
> things. Also, convert the return to an XSD values by inspection. The JS
> writer is insulated from RDF details.
>
> Works really nicely for strings.
> Everything could be a string, and the dynamic nature of JS will work
> (caveat the overheads for simple functions called many, many times).
> (Enough said about numbers in JS!)
>
> Other items (URIs, bNodes) can be some kind of object. If they have a
> "toString()", then it works in unaware JS code.
>
> I've mocked this up and got it working.
>
> 2/ Pass in JS-ish RDFterms - e.g. [A]
>
> This exposes the fact the arguments are RDF terms, with datatypes and
> differentiates between URIs and literals. The function writer is more
> aware of RDF, such as URIs (NamedNodes in the language of [A]).
>
> For custom functions, I think there is less usefulness per se because
> the function is not manipulating the RDF data, its working on values.
> On the other hand, one way to handle RDF terms in JS is better.
>
> 3/ Pass in Jena Nodes or NodeValues.
>
> This is the raw Jena-java-RDF view. The JS function writer is exposed
> to Jena details has full power. Probably not meeting the goals of ease
> of use for a non-Java writing person. NodeValue.toString means the JS
> writer can be semi-unaware of this.
>
>
> Another design point is whether the JS function can call back into Jena,
> if at all (well, it can't be stopped in Nashorn but that does not make
> it a good idea. The result if a good function is entire defined by its
> inputs. No side effects, no state.)
>
> For Fuseki:
>
> We need a library of functions to be loaded and ideally compiled once.
>
> We could get the JS scripts into the Context by reading from URL, or a
> literal string in the file. There is a Context that is server-wide, in
> the server section of a configuration file,and the one used for
> execution can be added to with dataset-specific Context settings.
>
> Andy
>
> [A] https://github.com/rdfjs/representation-task-force
>
> On 06/09/17 22:37, Holger Knublauch wrote:
>>
>>
>> On 6/09/2017 19:45, Adrian Gschwend wrote:
>>> On 06.09.17 00:21, Holger Knublauch wrote:
>>>
>>> Hi Holger,
>>>
>>>> Is this about SPARQL functions or functions called from Java? For SPARQL
>>>> functions written in JavaScript, see
>>>>
>>>> https://w3c.github.io/data-shapes/shacl-js/#js-functions
>>> ok but that still expects the SPARQL engine to support that right?
>>
>> This is implemented for Jena's SPARQL functions registry here
>>
>> https://github.com/TopQuadrant/shacl/blob/master/src/main/java/org/topbraid/shacl/arq/SHACLJSARQFunction.java
>>
>>
>> Holger
>>
>>
>>
>>>
>>> regards
>>>
>>> Adrian
>>
>
>
>
