Could this be a thing for support in Fuseki? IOW, we don't want to package every possible scripting language with Fuseki, but people will want to use this kind of facility with it, so we might want to have some instructions available as to how to add your JSR 223 lang of choice.
ajs6f On 2017-09-08 13:49, Andy Seaborne <a...@apache.org> wrote: > 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 > >> > > > > > > >
