AI Runs Better on Ontologies. Now Anyone Can Build Them. 

How Mobi 4.3 turns years of ontology engineering expertise into a collaborative AI workflow 

For years, knowledge graphs and ontologies lived on the fringes of enterprise data strategy. That has changed. Teams building AI agents, stitching together data across systems, or trying to make their data interoperable, keep landing on the same answer: they need an ontology underneath it all. 

A 2025 study in the Journal of Biomedical Informatics found that grounding LLM responses in ontology-based knowledge graphs cut hallucination rates by more than 61% compared with leading models working without that structure.¹ 

The catch is that ontology building has always demanded specialist knowledge: OWL, semantic modeling patterns, careful domain analysis. Hiring for it is hard and expensive. The organizations with the most to gain from knowledge graphs are often the ones with no realistic path to building them. 

That gap is where Mobi is aimed at driving value. 

________________________________________________________________________________________________________________________________________

1 “Ontology-grounded knowledge graphs for mitigating hallucinations in large language models for clinical question answering,” Journal of Biomedical Informatics, 2025. https://www.sciencedirect.com/science/article/abs/pii/S1532046426000171

We have spent years at RealmOne building ontologies to drive practical value for commercial enterprise customers across a lot of industries. After enough of those engagements, the shape of a successful one gets obvious. They follow the same methodology, almost regardless of domain. 

Instead of the work starting with classes and properties and complex classifications, it starts with questions. What questions are hard for you to answer today? What decisions will this data actually support? In ontology engineering these are called competency questions, and every good engagement begins with them. They force clarity about purpose before anyone types a single triple. 

Our actual takeaway, after doing this for a while: what makes a strong ontologist is not only OWL fluency. It is knowing how to ask the right questions, probe for unstated assumptions, and iterate on structure as the answers come in. That is a process. Processes can be taught, or, as it turns out, encoded. 

We are not alone in thinking this way. Recent work in the Web Semantics journal digs into how LLMs are speeding up knowledge graph and ontology engineering.² We are drafting off the same wave. What we are bringing to the equation, that the papers cannot, is a decade of enterprise delivery behind the methodology. 

Mobi 4.3 bakes that methodology into the product. The new AI Assistant (currently in alpha) lives inside the Ontology Editor and collaborates with you to build OWL-compliant ontologies. 

The experience maps closely to working with an experienced ontology consultant. It opens with competency questions, what should your model answer, and then settles into a back-and-forth. It asks about your use case, pokes at assumptions, and keeps pulling at threads until the structure of your domain starts to show itself. 

Once it has enough to work with, the assistant drafts an ontology: class hierarchies, properties, relationships, pulled from patterns that hold up in practice. Then it does the part that most one-shot tools skip. It evaluates what it generated against your original requirements and starts refining, adding missing classes, adjusting domains and ranges, cleaning up annotations, and fixing structural issues that would not survive a review. 

What comes out is a real OWL ontology encoded in Turtle format. An artifact you can inspect and natively import into Mobi, with the classes, properties, and structure laid out for you to review before you commit to any of it. 

In practice: someone who has never written a line of OWL can sit down, talk through their domain in plain English, and walk away with a structured, spec-compliant draft ontology. The conversation itself is the training. By the time you have worked through competency questions, cycled through an evaluation pass, and refined the model, you have absorbed the core of how this work is actually done. 

This does not replace the ontologist. It opens up the ontologist’s playbook to anyone on a team. Groups that used to need months of consulting just to get started can begin today. The bottleneck moves from “do we have someone who knows OWL” to “do we understand our domain,” and if you are serious enough to want a knowledge graph, you almost certainly understand your domain. 

For anyone eyeing knowledge graphs as the data layer for AI agents and internal systems, that is a real shift. 

A lot of products have bolted AI onto the UI and called it a day. The Mobi AI Assistant encodes a methodology that came out of years of real enterprise work, and it is built to collaborate instead of simply generating something and handing it off. 

That matters because in ontology work, the quality of the output is a function of the process. A generated ontology that does not match your actual requirements is worse than no ontology at all. It gives you the illusion of structure while quietly encoding the wrong assumptions. By walking users through the same rigor our consultants use, the assistant ends up with ontologies tied to actual requirements rather than generic shapes pulled from training data. 

The AI Assistant is in alpha in Mobi 4.3, and the team is shipping improvements steadily. Expect it to get sharper fast. 

We’ve been hearing it for years at academic conferences: semantic modeling should not require a PhD. It should require domain knowledge and good questions. Simply put, Mobi helps you ask them and translate them into meaningful structure with which to drive answers. 

If you are exploring knowledge graphs to power AI, improve data interoperability, or bring order to complicated information, we would like to show you what this looks like. More at mobi.solutions, or dig into the documentation to get started.