Re: Materialize query

Well, ok. Indeed searching for it in publications is possible, but from my point of view this should be mentioned in the original question. Indeed, this is something like materialised views in SQL databases. But the question is still unclear, both are different layers - and don't see anything to

Re: Materialize query

Ok, I know this just as forward chaining resp. materialization in the context of reasoning. Which indeed needs to re-run it periodically for non static data. On 26.04.2017 14:39, Dick Murray wrote: > I've seen this type of statement in regard to Oracle whereby a materialized > query is disk

Last chance: ApacheCon is just three weeks away

ApacheCon is just three weeks away, in Miami, Florida, May 15th - 18th. http://apachecon.com/ There's still time to register and attend. ApacheCon is the best place to find out about tomorrow's software, today. ApacheCon is the official convention of The Apache Software Foundation, and includes

How do I customize remote SPARQL requests with RDFConnectionFactory?

Hi, We have written a Jena client application that uses RDFConnectionFactory, as specified in the Jena docs. Recently, we switched to a new remote triple store (MarkLogic) that uses digest auth. We would like to be able to handle the auth properly, and we would also like to send additional

Re: Materialize query

good afternoon; > On 2017-04-26, at 14:30, javed khan wrote: > > Lorenz, I have seen it in a statement like " Materialize queries are used > to reduce the number of necessary joins and processing time”. some of the publications even base their work on jena

Re: Materialize query

I've seen this type of statement in regard to Oracle whereby a materialized query is disk based and updated periodically based on the query. It's useful in BI where you don't require the latest data. As to RDF the closest I can parallel is persisting inference (think RDFS subclass of i.e. A -> B

Re: Materialize query

Lorenz, I have seen it in a statement like " Materialize queries are used to reduce the number of necessary joins and processing time". On Wed, Apr 26, 2017 at 8:52 AM, Lorenz B. < buehm...@informatik.uni-leipzig.de> wrote: > Please understand that the term "materialised SPARQL queries" is not a

Re: Jena native store indexes

good morning; > On 2017-04-26, at 10:33, baran...@gmail.com wrote: > > […] > > Is it so far fetched thinking to standardise 'only' the SPARQL 'syntax' for > text-indexing? that would not resolve your complaint. there are proposals which use facilities described in the recommendation to

Re: AW: ResponseProcessCookies warnings

On 26/04/17 07:33, Neubert, Joachim wrote: Hi Andy, Have you tried configuring the logging so that warnings from that class are turned off? Thanks for the hint! I've tried change the log level in tomcat/conf/logging.properties, but neither

Re: Jena native store indexes

Hello, you generelized the problem of standardisating suggesting to standardise first the extensions as an important step to the mean standardisation, i think. To formulate similar things are essentially important for all users and very stimulating. Since so many years the first eMail i

AW: ResponseProcessCookies warnings

Hi Andy, > Have you tried configuring the logging so that warnings from that class are > turned off? Thanks for the hint! I've tried change the log level in tomcat/conf/logging.properties, but neither org.apache.http.client.protocol.ResponseProcessCookies.level = SEVERE nor