Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Database architecture #10

Closed
simongray opened this issue Jul 6, 2021 · 1 comment
Closed

Database architecture #10

simongray opened this issue Jul 6, 2021 · 1 comment

Comments

@simongray
Copy link
Member

simongray commented Jul 6, 2021

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.
@simongray
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant