You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by "Nouwt, B. (Barry)" <ba...@tno.nl.INVALID> on 2020/02/06 16:20:42 UTC

disable lazy infgraph

Hi all,

We are using Apache Jena in our project and noticed that the GenericRuleReasoner InfGraph is lazy. Namely, after a SPARQL INSERT query on the dataset, the matching rules do not get applied immediately. Only after performing a SPARQL SELECT query on the dataset, the matching rules will be applied.

We would like to disable this lazy behavior, because it conflicts with our use case, but we are not sure how to do it properly (and less brute force). Currently, we attach a GraphListener to that graph in which we force a prepare() each time one of GraphListener's update methods is called, but this has some side effects (among others the reapplying of rules that were already applied) that we would like to prevent. I assume there is a less brute force manner to kick the reasoner into action (similar to what a SPARQL SELECT query achieves), but I'm not sure what this is. If I look at the source code of Jena I see several candidates, like the BaseInfGraph.rebind() and BaseInfGraph.reset() method, are those better options?

Does anyone has an idea how to achieve non-laziness of the InfGraph some other way?

Thanks in advance!

Barry



This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

Re: disable lazy infgraph

Posted by Dave Reynolds <da...@gmail.com>.
Hi,

The prepare() call you are using is the right way to go. This is the 
closest to incremental processing the engine supports - the reset() and 
rebind() calls basically start over from scratch.

Triggering it on every update will be inefficient but the best you can 
do in most general case to achieve eager eval. Depending on your 
application you may be able to batch these (with count and/or time 
threshold) or trigger after some application specific batch of updates.

Dave


On 06/02/2020 16:20, Nouwt, B. (Barry) wrote:
> Hi all,
> 
> We are using Apache Jena in our project and noticed that the GenericRuleReasoner InfGraph is lazy. Namely, after a SPARQL INSERT query on the dataset, the matching rules do not get applied immediately. Only after performing a SPARQL SELECT query on the dataset, the matching rules will be applied.
> 
> We would like to disable this lazy behavior, because it conflicts with our use case, but we are not sure how to do it properly (and less brute force). Currently, we attach a GraphListener to that graph in which we force a prepare() each time one of GraphListener's update methods is called, but this has some side effects (among others the reapplying of rules that were already applied) that we would like to prevent. I assume there is a less brute force manner to kick the reasoner into action (similar to what a SPARQL SELECT query achieves), but I'm not sure what this is. If I look at the source code of Jena I see several candidates, like the BaseInfGraph.rebind() and BaseInfGraph.reset() method, are those better options?
> 
> Does anyone has an idea how to achieve non-laziness of the InfGraph some other way?
> 
> Thanks in advance!
> 
> Barry
> 
> 
> 
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>