You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the Jena implementation can be persistent through TDB, but not when coupled with a reasoner doing inference. I am unsure whether if means that inference cannot realistically be coupled with TDB. Here are some options for database architecture:
A single, shared, fully in-memory graph (with inferencing)
This would require a serious backup solution running every time the graph is updated.
An in-memory graph for viewing (with inferencing) + a TDB database for editing (NO inferencing)
The editor can potentially be joined by another in-memory graph with inferencing to display results. Both TDB and in-memory graphs would then be manipulated.
The viewer graph would live entirely separate, only having occasional refreshes.
A single, shared, TDB graph with inferencing (likely as an in-memory layer)
Currently unsure whether this is possible.
Would be the the ideal solution as it ensures both persistence and instant updates.
A single, shared TDB graph with NO inferencing + occassional updates with data from an OntologyGraph.
This solution keeps the instant updates, but not of the inferred portions. These arrive at a later point once the graph is fully updated based on triples from an in-memory OntologyGraph.
The text was updated successfully, but these errors were encountered:
Reading the documentation once again, it seems like any kind of live system with inferencing is not ideal:
Having bound a Model into an InfModel by using a Reasoner its content can still be changed by the normal add and remove calls to the InfModel. Any such change the model will usually cause all current deductions and temporary rules to be discarded and inference will start again from scratch at the next query. Some reasoners, such as the RETE-based forward rule engine, can work incrementally.
Basically, if any changes are made to the graph, subsequent queries end up dog slow until inferencing has caught up. This is not ideal at all.
It seems like the only valid solution is to have two graphs:
A TDB-based graph for editing. This would have no inferencing capabilities. It would therefore only be a place to make edits to the dataset.
A graph for viewing which does contain inferred triples.
This can either be an in-memory graph or TDB graph.
I guess TDB is the best trade-off as it will allow the system to be restarted without having to rebuild the graph.
An in-memory graph would be preferable in cases where rebuilding the graph is not an issue (and memory is plentiful).
Furthermore, when it comes to exporting data, it seems like we will also need the capability to create adhoc InfModel graph containing e.g. the inferred opposite relations. Otherwise, the alternative is simply to only have the base dataset available as an export file.
Currently, the Jena implementation can be persistent through TDB, but not when coupled with a reasoner doing inference. I am unsure whether if means that inference cannot realistically be coupled with TDB. Here are some options for database architecture:
The text was updated successfully, but these errors were encountered: