Re: SPIN support

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

Re: Multiunion doubt

Yes, Chris - MultiUnion is linking with a distinguished that is updated. (Changing that would be a BIG change!) Datasets like TIM (transactions in memory) and TDB can provide the union graph of their named graphs and more efficiently than the general purpose MultiUnion. Andy On 8 September

Re: SPIN support

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

Re: Multiunion doubt

On 8 September 2017 at 10:11, George News wrote: > Hi, > > Is multiunion only linking the graphs or copying them in a new graph? > > I'm thinking on splitting a huge graph on many simple ones and them > making the union depending on the part of the main graph that has to be

Re: Multiunion doubt

On 2017-09-08 12:41, Claude Warren wrote: > try createing a multiunion graph and hen create model on that. > > The last time I looked the multiunion graph did not copy the data but > rather made calls across the graph implementations. Should then use transactions to read from them, shouldn't I?

Re: Multiunion doubt

Ups I have just noticed that MultiUnion is working with Graphs and not models :( Then, I'm using dataset.getNamedMode(name).getGraph(). But all my functions expect a Model as an input. How should I proceed? 1) ModelFactory.createUnion() in a kind of loop, adding one model, and then another, etc.

Multiunion doubt

Hi, Is multiunion only linking the graphs or copying them in a new graph? I'm thinking on splitting a huge graph on many simple ones and them making the union depending on the part of the main graph that has to be requested, therefore limiting the scope of the sparql and speeding things up. But