Thanks Rob, The temporary graph is a good idea. Much appreciated.
What is the best way to ensure that the temporary graph is stored in memory and not in the underlying TDB? It would be great to have a set of best practices where these examples are shown. Best regards, Niels -----Original Message----- From: Rob Vesse [mailto:[email protected]] Sent: Tuesday, November 15, 2016 02:15 To: [email protected] Subject: Re: How do I do a join between multiple model.listStatments calls? On 14/11/2016 19:10, "Niels Andersen" <[email protected]> wrote: Finally, regarding my list of concerns and questions. Let's start with a specific one: Is there a SPARQL equivalent to SQL views, functions and stored procedures? I believe that the answer is no, and if it is then what is the best practice to provide this functionality? For views you can use an INSERT {} WHERE {} update to create a new graph with the data of interest eg. INSERT { GRAPH <urn:temporary:example> { ?s ?p ?o } } WHERE { # Match ?s ?p ?o as desired } The WHERE clause can contain an arbitrarily complex query pattern and the INSERT clause defines a template for the new data to be created. You can then Direct subsequent queries against that temporary graph. Once you’re done with it every grass you can delete it with a DROP <urn:temporary:example> Note that there is not support for views in the traditional SQL sense in most implementations that I’m aware of. So if your data changes you would need to rerun insert updates to recreate your temporary graphs. In terms of functions the specifications define an extension mechanism based upon naming functions with URIs. The range of supported functions Will vary between implementations. You can find details on the extensions that ARQ supports at the following page: http://jena.apache.org/documentation/query/library-function.html It is also possible to define and register your own functions, the mechanism for this Will vary between vendors. Again the ARQ documentation for this can be found at the following page: http://jena.apache.org/documentation/query/writing_functions.html As for stored procedures there is no support in ARQ currently nor do I believe it is planned. Myself and Andy have discussed the idea of something similar in the past but neither of us have been in a position to implement it. I have seen some support for those from other vendors e.g. TopQuadrant’s SPIN but this is not widely supported. As Andy already implied most large applications use a business logic layer that generates queries and updates as necessary. Rob
