Ontology development has a reputation for being slow, and it's earned. Building a good ontology means getting a Domain Expert and a Knowledge Engineer to agree on what a "vehicle," a "process," or an "event" actually means in a specific context — then encoding that agreement precisely enough for a machine to reason over it. Every step of that has a bottleneck, and lately I've been thinking hard about which of those bottlenecks AI tools can genuinely help with, and which ones they can't.

The recurring bottlenecks

A few problems show up in almost every ontology project I've worked on, regardless of domain:

The knowledge acquisition gap. Domain Experts know the domain but not formal semantics; Knowledge Engineers know OWL and description logics but not the domain. A huge share of project time goes into just translating between the two, and a lot gets lost in that translation.

Reuse instead of reinvention. There's rarely a good reason to model "location" or "agent" from scratch when a dozen well-maintained ontologies already do it. But finding the right existing terms to reuse, and understanding whether their intended semantics actually match your use case, takes real effort — it's a search and comprehension problem before it's a modelling problem.

Ontology matching and alignment. The moment two systems need to interoperate, someone has to work out which classes and properties in one ontology correspond to which in the other — not just by label, but by actual meaning. Two ontologies can both have a class called Component that mean completely different things. This gets harder, not easier, as the number of participating systems grows, which is exactly the situation Data Spaces create.

Keeping it consistent as it grows. Ontologies are living artifacts. As new terms get added by different contributors over time, subtle inconsistencies creep in — overlapping classes, contradictory axioms, orphaned terms nobody uses. Catching these requires both logical validation and a working memory of everything already in the model.

Documentation nobody has time to write. Competency questions, term definitions, usage examples — the artifacts that make an ontology usable by someone other than its author are usually the first thing cut when a project runs out of time.

Where AI tools are actually useful

None of this is solved by throwing a language model at "generate me an ontology." But several of these bottlenecks are narrow enough that current AI tools give real, checkable leverage:

Drafting from domain text. Given a set of domain documents, an LLM can propose a first-pass list of candidate classes, properties, and relationships, along with the sentences that justify them. This doesn't replace the Domain Expert / Knowledge Engineer conversation, but it gives that conversation something concrete to react to instead of starting from a blank page. Reacting to a draft is a much easier task for a Domain Expert than authoring formal structure from scratch.

Surfacing candidates for reuse. Instead of manually searching ontology catalogues, you can point a model at your competency questions and a set of established ontologies and ask it to propose which existing terms are plausible matches, with its reasoning. A human still has to verify the semantics hold up, but the search space shrinks dramatically.

Assisting ontology matching. This is close to my own work on application profiles for the IDS Information Model: aligning independently developed models is fundamentally about comparing meaning, not just labels. Embedding-based similarity and LLM-assisted reasoning over definitions and context can propose candidate mappings between classes and properties across ontologies — again, as candidates for a human to confirm, not as ground truth.

Consistency and gap checking. Language models are decent at reading through a large set of axioms and flagging things that look off — a class defined two different ways, a property used inconsistently, a term that seems to duplicate another. Combined with a proper reasoner for the formal logic, this catches issues earlier and cheaper than a manual review pass.

Generating the boring-but-necessary documentation. Turning a formal ontology into plain-language definitions, usage examples, or a first draft of competency questions is exactly the kind of translation task language models are good at, and it's usually the artifact that got skipped for lack of time.

Where I'd stay cautious

The common thread in all of the above is that AI tools are good at proposing and summarizing, not at deciding. A model can suggest that two classes probably align, or that a term is missing, but it doesn't understand your domain's actual commitments — the reasons your team chose one modelling decision over another. Handing that decision to a model, rather than to the Domain Expert and Knowledge Engineer working together, is how you end up with an ontology that looks coherent and isn't.

This is also where I think a lot of the "AI will automate ontology engineering" framing gets it backwards. The bottleneck was never typing out axioms quickly. It was building shared, correct understanding between people who see the domain differently. AI tools can remove a lot of the friction around that process — drafting, searching, checking, documenting — but the understanding itself still has to be built by the people who need to trust the result.

We explored a related version of this question in a recent paper on using LLMs for biomarker knowledge graph construction, and I think the lesson generalizes well beyond biomedicine: treat the model as a fast, sometimes-wrong research assistant, keep the verification step non-negotiable, and you get a genuinely useful speed-up without giving up rigor.