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 <[email protected]>
To: [email protected]
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
>
