Open Ontologies: A Rust MCP Server for Validating and Reasoning Over AI-Generated RDF/OWL

The problem Open Ontologies targets: LLM output that looks like an ontology

Language models produce RDF and OWL that parses. Whether it is consistent, whether the subclass axioms actually entail what the author intended, and whether the SHACL shapes still describe the class hierarchy after a revision is a separate question, and it is the one this project answers. The README frames the server as a "Terraforming MCP for Knowledge Graphs" and states the split plainly: the server provides validation and scaffolding, the connected LLM does the intelligence. There are no internal LLM clients, no API keys and no provider abstractions in the binary.

The audience is narrow on purpose. You need an MCP-capable client, typically Claude, and you need to care about description logic rather than about storing triples. Someone who wants a hosted knowledge graph with a query UI will find the tooling here oriented the wrong way: it is built to check a graph, not to serve one.

Inside the binary: Oxigraph, a tableaux reasoner and 70+ MCP tools

The engine is a single Rust binary built on Oxigraph 0.5 as an in-memory triple store. Cargo.toml describes the crate as an "AI-native ontology engine: an MCP server and CLI for building, validating, querying and reasoning over RDF and OWL, with a native SHIQ tableaux reasoner, SHACL validation and SPARQL." The transport layer is rmcp 1.4 with the server, transport-io and transport-streamable-http-server features, and axum handles HTTP.

The README describes a three-layer architecture. Dynamics ships an ActionSchema with four tools (onto_action_register, onto_action_applicable, onto_action_apply, onto_action_list) for concurrent atomic ticks with static causal laws and non-deterministic outcomes behind a reproducible seed. Causal centres on onto_certify_action, with PyWhy backdoor identification gated behind the causal-pywhy Cargo feature and a structural-proxy default when that feature is off. Planner compiles PDDL through onto_plan_compile_pddl and validates plans with onto_plan_validate against a sandbox simulation, while the solver itself stays client-side. That last decision is worth noting: the server compiles and validates, it does not solve, so a Fast Downward binary remains your responsibility.

Beyond those, the release notes for v1.3.0 list 13 primitives, including incremental SHACL co-evolution that uses dependency-graph routing so only shapes touching changed IRIs revalidate, OWL-EL classification through onto_classify_el, and a Mamdani fuzzy-logic alignment adjudicator in onto_align_fuzzy that demotes HNSW to a candidate generator.

Installing Open Ontologies and running a first reasoning pass

The README's Quick Start section points at pre-built binaries, with a macOS Apple Silicon entry visible in the truncated text, and the repository also publishes a container image on GHCR. The Dockerfile builds with cargo build --release --features embeddings,plugins,sql, copies the binary into a distroless cc-debian12 base, and sets the entrypoint to open-ontologies with a default command of serve. Running the image therefore starts the MCP server with no arguments.

FROM gcr.io/distroless/cc-debian12
COPY --from=builder /build/target/release/open-ontologies /usr/local/bin/open-ontologies
COPY --from=builder /deps/ /
ENTRYPOINT ["open-ontologies"]
CMD ["serve"]

Building from source follows the Makefile targets. The default release build is plain cargo, and the lint and test gates are separate targets, so you can run them independently.

make build
make test
make lint

The README also documents an end-to-end example that walks the whole three-layer stack without external dependencies. It registers a Dynamics action, compiles PDDL, parses a Fast-Downward-shaped sas_plan, binds IRIs, validates in the sandbox, certifies, applies with OWL-RL ramification and inspects the final state.

cargo run --example three_layer_pipeline

Expect the example to exercise each layer through its public API. The README states that no Python, DoWhy or Fast Downward installation is required for it.

Where Open Ontologies gets in the way

The reasoner is described as a native SHIQ tableaux implementation, not a full OWL 2 DL reasoner in the sense that HermiT or Konclude are. The README's own release notes separate OWL-EL classification (onto_classify_el, with a transitive subsumption table and trivial pairs excluded) from the tableaux path, which tells you the profiles are handled by different code with different complexity guarantees. If your ontology leans on datatype reasoning or on constructs outside SHIQ, the default path may not decide it, and the documentation does not promise a fallback.

The causal layer is opt-in in a way that matters. Without the causal-pywhy feature, onto_certify_action uses a structural proxy rather than do-calculus. That is a documented default, not a bug, but it means a certification result from a default build is weaker than the name suggests, and nothing in the README indicates the tool output distinguishes the two cases for a downstream reader.

The project is also not a database. There is no persistence story in the repository: Oxigraph is described as in-memory, and the versioning and lineage features sit on top of that. A long-running service that expects the graph to survive a restart has no documented answer here. Finally, the Planner layer stops at compilation and validation. If you have no solver, onto_plan_classical has nothing to call.

How it differs from Protégé and from JVM-based reasoners

Protégé is the reference desktop ontology editor, and the README positions against it directly: "No JVM. No Protégé." The difference is not cosmetic. Protégé is an interactive editor where a human clicks through a class hierarchy, and its reasoning is delegated to Java libraries such as HermiT or ELK. Open Ontologies inverts both halves. The interface is an MCP tool surface consumed by a model, and the reasoner is compiled into the same Rust binary as the store, so there is no JVM to install and no separate reasoner process to manage.

That inversion has a cost. Protégé gives you a mature plugin ecosystem and a graphical explanation of why an entailment holds. Open Ontologies gives you 70+ tools and a Studio desktop app that the README describes as having a virtualized ontology tree, breadcrumb navigation, an AI chat panel with /build and /sketch commands, and a Protégé-style property inspector. The word "style" is doing real work there: the Studio borrows the inspector's shape, not Protégé's plugin surface. If your workflow depends on a specific Protégé plugin, this is not a drop-in replacement, and the README does not claim otherwise.

Maintenance, licence and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-05. Releases are dense: v1.2.0 on 2026-08-15, v1.2.1 on 2026-09-02, v1.3.0 on 2026-09-04. That cadence means the tool surface moves, and the 13 primitives added in v1.3.0 landed as a single batch, so a client pinned to v1.2.0 sees a materially smaller tool list.

The licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are retained. Nothing in the repository suggests a dual-licence arrangement or a contributor licence agreement that would complicate that, but this is a description of the licence text, not legal advice, and your counsel should read LICENSE in the repository root.

Upgrade cost is dominated by feature flags rather than by breaking API changes. The default build excludes embeddings, plugins and sql, and the Dockerfile enables all three; causal-pywhy is separate again. A deployment that turns a feature on changes which tools the server exposes, so the practical upgrade question is whether your MCP client's tool allowlist still matches. The Makefile's check target runs lint, test and audit together, which is the cheapest way to see whether a version bump breaks your build before you ship it.

Editorial conclusion

Adopt Open Ontologies if you already drive Claude or another MCP client and you need machine-checkable validation of OWL and SHACL artifacts without a JVM in the loop. Skip it if you need a general-purpose triple store with a SPARQL 1.1 Update endpoint, or if your pipeline depends on a maintained external reasoner such as HermiT or ELK. Before committing, verify the pre-built binary path for your platform against the README install section, check that the OWL2-DL tableaux reasoner covers the profile your ontology actually uses, and confirm the Docker image tag on GHCR matches the version in Cargo.toml.

Frequently asked questions

Official sources

1. fabio-rovai/open-ontologies on GitHub
2. License: MIT
3. Project website
4. README
5. Releases