DeepOnto: Ontology Engineering That Runs Through a Java Bridge

The gap DeepOnto fills between OWLAPI and a training loop

Ontology work and deep learning work tend to live in different runtimes. OWLAPI is Java. PyTorch is Python. If you want to prune an ontology, verbalise a complex class expression into a sentence, project a TBox into RDF triples and then feed the result to a language model, you normally write the glue yourself. DeepOnto is that glue, packaged. The README describes it as providing "building blocks for implementing deep learning models, constructing resources, and conducting evaluation for various ontology engineering purposes." The intended user is someone doing ontology engineering research who already writes Python: a PhD student building embeddings, a lab reproducing a completion benchmark, an engineer maintaining a large OWL ontology who wants scripted access to its axioms. It is not aimed at someone who just needs to parse a Turtle file. The project's own positioning, including an arXiv paper and a Semantic Web journal article, tells you the audience is academic and the expectations are those of a research codebase rather than a product.

OWLAPI 4.5.22 over JPype, and what that means for your process

The architectural decision that governs everything else is stated plainly in the installation section: DeepOnto relies on OWLAPI version 4.5.22, written in Java, and follows mOWL's approach of using JPype to bridge Python and the JVM. So a DeepOnto process is a Python process with a Java virtual machine embedded inside it. Ontology objects you create in Python are backed by Java objects. This is why the README points you at JPype's installation page for "successful JVM initialisation" rather than treating it as an implementation detail. It also explains the project's own topic list, which includes owlapi alongside deep-learning and language-model. The practical consequence is that anything that goes wrong at the JVM boundary, whether a missing Java runtime, a version mismatch, or a classpath problem, surfaces as a Python-side failure with a Java-side cause. The benefit is that you get OWLAPI's reasoning and axiom manipulation rather than a reimplementation, which is why the Ontology class can offer ancestor and descendant queries, entity deletion, axiom modification and annotation retrieval without the project maintaining its own OWL parser.

The Ontology class and the five sub-modules built on it

The base class is Ontology, described as the main entry point for OWLAPI features. Around it the README lists five sub-modules, and each one is a distinct piece of research code rather than a generic utility. OntologyReasoner is an attribute of every Ontology instance and handles inferred subsumers and subsumees, entailment checking and consistency checking. OntologyPruner extracts a sub-ontology, implementing an algorithm that introduces subsumption axioms between the asserted parents and children of the class targeted for removal. OntologyVerbaliser implements a recursive concept verbaliser that turns a complex logical expression into a textual sentence using entity names or labels from the ontology. OntologyProjector implements the projection used in OWL2Vec* embeddings, transforming a TBox into a set of RDF triples, with code modified from mOWL. OntologyNormaliser implements EL normalisation, also modified from mOWL, to put TBox axioms into normalised forms that support downstream geometric methods. The provenance matters: two of the five are adapted from another library, and the pruner and verbaliser correspond to specific cited papers. This is a curated set of algorithms, not a broad ontology toolkit, and the README does not claim otherwise.

Installing DeepOnto: PyTorch first, then the right extras

The README is explicit that PyTorch should be installed before DeepOnto, following the commands on the PyTorch site, and that you choose either the GPU or CPU build. For cases where the newest PyTorch causes incompatibility, it gives a command known to work with CUDA 11.6: pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu116. The core package then installs from PyPI with pip install deeponto, requiring Python 3.8 or later, with remaining dependencies specified in setup.cfg and requirements.txt. Two extras exist for reasons the README explains. openprompt conflicts with several other packages and is reported to be hard to resolve on MacOS with M1, so it is optional; it is the main dependency of the OntoLAMA code at deeponto.complete.ontolama, so use pip install deeponto[ontolama] if you need that module. Automatic ontology lookup and caching come from pip install deeponto[bioregistry]. For unreleased code, pip install git+https://github.com/KRR-Oxford/DeepOnto.git. Note the README's own qualification on hardware: basic usage does not need a GPU, but efficient model training does, and you should confirm torch.cuda.is_available() returns True.

Where the JVM and the release cadence get in the way

The first limitation is platform. The README reports that openprompt has conflicts that are hard to address on MacOS with M1, which is why it was made optional. That fix solves installation but not capability: if you are on that platform and you want OntoLAMA, you are installing a dependency the maintainers have already flagged as troublesome there. The second limitation is the JVM itself. JPype initialisation is a prerequisite, not a fallback, and the README links to JPype's install page rather than offering a pure-Python path. In a container or a serverless environment where you cannot ship a Java runtime, DeepOnto is the wrong tool, and no amount of Python packaging will change that. The third is API stability. The release history shows v0.9.3 fixing a missing axiom issue in normalisation, v0.9.2 as a minor update, and v0.9.1 as a hot-fix to dependency incompatibility. A correctness fix in normalisation is exactly the kind of change that can shift the output of a pipeline built on top of it, and a hot-fix release for dependency incompatibility indicates that the dependency graph is not fully pinned. Treat this as a research toolkit and pin your version.

mOWL as the alternative, and the difference that matters

mOWL is the obvious comparison, and DeepOnto's README names it twice: as the source of the JPype bridging pattern and as the origin of the projection and EL normalisation code. So the two share a runtime architecture and, for those two sub-modules, share lineage. The difference is scope. mOWL is a library for ontology machine learning and embeddings, and its documented focus is representation learning over ontologies. DeepOnto adds ontology engineering operations that sit before and beside the learning step: reasoning through OntologyReasoner, pruning a sub-ontology, verbalising class expressions into text, and a stated goal of constructing resources and conducting evaluation for ontology engineering tasks. If your job is to train embeddings from an ontology, mOWL covers that ground and you inherit the same Java bridge either way. If your job includes turning axioms into sentences for a language model, or extracting a sub-ontology around a class you plan to remove, that is the layer DeepOnto adds. The choice is about which operations you need, not which library is better maintained, and the README gives no comparison of the two on any other axis.

Licence, maintenance and the upgrade cost you are accepting

DeepOnto is Apache-2.0, and the README header carries the full Apache notice with a copyright line for Yuan He, KRR-Oxford, dated 2021. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices, but this is a description of the licence text, not legal advice; if you are redistributing DeepOnto inside a commercial product, read the licence and the notices in the source files yourself. On maintenance, the observable signals are the release tags and the repository state: v0.9.3 in March 2025, v0.9.2 in October 2024, v0.9.1 in March 2024, and a last push dated September 2026 with the repository not archived. The gaps between releases run to roughly seven months, which is normal for an academic project and worth planning around. The upgrade cost is concentrated in the Java and PyTorch layers rather than in DeepOnto's own API. OWLAPI is pinned at 4.5.22, so a change there is not something you can absorb by bumping a pip package, and the README's CUDA 11.6 command exists precisely because newer PyTorch builds have caused incompatibility. Budget for a test run of your normalisation and projection outputs whenever you move versions, since v0.9.3 shows that normalisation output can change between patch releases.

Editorial conclusion

Adopt DeepOnto if you need OWLAPI-grade reasoning and TBox manipulation from Python and you are willing to run a JVM alongside your training code. Do not adopt it if you want a pure-Python ontology stack, if your environment cannot initialise a JVM through JPype, or if you need a stable API surface across releases rather than a research toolkit that still ships breaking fixes, as v0.9.3 did for normalisation. Before committing, verify three things: that JPype initialises on your platform, that torch.cuda.is_available() returns True on the machine you intend to train on, and that the pinned OWLAPI 4.5.22 matches the ontologies you actually load.

Official sources

1. KRR-Oxford/DeepOnto on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases