Thanks. That explains a lot. Like why the difference in the size variable of the graphs only includes the new statements and not implied ones.
Knowing this I have 2 options, run the listStatements command every time there’s changes or only use forward chaining, but that one is limiting. Do you think a 3rd option is viable where I create a new InfModel class that takes this into account and somehow traces throw and keeps a cache of those changes from the listStatement process, notifying the difference? Sent from my iPhone > On Sep 21, 2020, at 6:21 AM, Dave Reynolds <[email protected]> wrote: > > I don't believe there's a custom notification arrangement for InfModels so > indeed you'd have to attach the listener to both the base model and the > deductions model. > > For pure forward chaining rules that should be sufficient. > > If you are using backward chaining rules, or the hybrid rule system (as used > for the all the default configurations for RDFS and OWL), then it's not > possible to get notifications for everything. In those setups then some of > the triples you see from listStatements have been implicitly generated > on-demand prompted by the query pattern and are never materialized or stored > anywhere and so can't trigger a listener. > > Dave > >> On 20/09/2020 15:13, Jenson Joseph wrote: >> HI, >> I'm hoping I could get some help on this. I have an InfModel that I add a >> listener to where I'm looking for all changes to the model, whether it was >> inferred or not. On the model, I only get notified of changes that were >> directly added, inferred changes are not notified. I switched to listening >> to the deductions model and I don't get any notifications when I add new >> statements. >> I tried using combinations of the .rebind, .reset, .prepare functions with >> no luck and I searched the internet on this with no luck. >> I know the inferences are being made because they show up if I list the >> statements of the inference model. I would like to know if it is currently >> possible to have a listener that receives all changes made to n InfModel. >> The reason for this is I want to keep track of the incremental changes and >> perform queries on a small subset of the model. If I do the queries on the >> entire model it would be more expensive while returning redundant results >> that have already been seen and processed. >> If this is an expected use case in Jena, that's handled differently I'm open >> to hearing about that but I would love to have this meticulous listener >> within the InfModel if you can help me figure that out. >> Thanks, >> Jenson
