(Note: This is a crosspost from the depreciated List@ http://tech.groups.yahoo.com/group/jena-dev/)
Hi there, currently, my Spring MVC project creates a in-memory ontology (ModelFactory.createOntologyModel(OntModelSpec.OWL_DL_MEM)) with round about 19.000 Statements before reasoning, and 350.000 Statements after reasoning (demo data set, the actual data set will probabably some multipliers larger). I am using the latest Jena libs and the GenericRuleReasoner with a couple of custom rules (http://pastebin.com/i96sM1W3). Until know, I didn't care about the lifecycle of the Ontology: It is initialized at server start-up (takes 150-200s) and everything is fine. However, for actual future operational readiness, there are two upcoming changes I am brainstorming right now: (T1) Persistence using TDB or SDB (TDB shopuld be sufficient) (T2) The ontology should be updateable at server run-time The reasoning process, given the current set of rules (http://pastebin.com/i96sM1W3), is pretty slow: At least one minute on my machine. So my main target in is to not trigger a whole new reasoning process if the ontology is modified (added, removed statements that are related to the reasoning rules). My investigations of the jena documentation revealed, that using the Model/InfModel API I don't have to care about these update operations, since the Jena API methods itself will keep care about that. Additionally, there are for special cases the InfModel methods rebind() and reset(). (right?) (P1) Okay so far. But in my understanding, there is the following problem: What if the information, which reasoner did the inferencing, is lost? Then the model cannot be able to do additional inferencing when the the ontology is modified, right? I.e. the TDB persistence method (as seen here http://goo.gl/qZMYW) does store Model, but not the InfModel (which includes the reasoner which did the reasoning). So assuming I would persist my ontology in the manner of http://goo.gl/qZMYW, I would have to fetch the TDB stored model first and then create the InfModel again by adding the Reasoner -- but then the persisting would be pointless, since the inferencing takes nearly the same time as creating the ontology from scratch. (P2) Another problem is related using multiple layers of reasoners: It _might_ be, that I need more than one reasoner, since my rules are interdependent. So in order to ensure that some forward rules are finished, I divide the set of rules into two distinct sets (as proposed here http://tech.groups.yahoo.com/group/jena-dev/message/46682). The reason for that is, that I am using build-in functions as noValue(). Assuming that I need a multi-layer-reasoning: Then, the InfModel would only store the last reasoner. So, updating the Ontology (adding, removing statements) would not trigger the correct update processes related to the reasoning. * * * My main questions are: (Q1) What is the best-practice to persist InfModels without losing the update-functionality and without triggering a whole new inference-process on load? Is this possible with TDB? (Q2) How to maintain the update-functionality when using mutliple layer of reasoners? (Q3) And first of all: Does the InfModel update-functionality work the way I am assuming? Will updateing the Ontology (adding, removing a Statement) correctly regarded respective related reasoning actions? (Q4) Are there other related technologies, that I should consider for my application? (owlapi, other reasoners*, Joseki/Fuseki, ...) I would appreciate any hints! -- Weizen * I think I am bound to the GenericRulesReasoner since I am using the noValue()-Built-in for my Closed World Assumption.
