Using AI to Accelerate Ontology Engineering

Introduction: The Paradigm Shift in Ontology Engineering

For decades, the primary bottleneck in semantic modeling has been knowledge acquisition. Extracting concepts from subject-matter experts and unstructured documentation, formalizing them into taxonomies, and strictly defining axioms is a labor-intensive, manual process. Today, Large Language Models (LLMs) are fundamentally shifting this dynamic, acting as “copilots” that can rapidly propose candidate classes, properties, and map complex relationships.

However, foundational LLMs are statistical engines, not formal reasoners. Left to their own devices, they hallucinate properties, conflate hierarchical (rdfs:subClassOf) and associative relationships, and routinely generate syntactically invalid RDF or OWL. To effectively use AI to accelerate ontology engineering, you must move beyond ad-hoc prompting and integrate LLMs into structured, programmatic pipelines.

This lesson explores how to operationalize generative AI for ontology creation, covering established frameworks, methodology-driven prompting, and the critical validation loops required to ensure semantic integrity.

The LLMs4OL Task Framework

To standardize how we apply AI to ontology generation, the International Semantic Web Conference (ISWC) established the LLMs4OL (LLMs for Ontology Learning) framework. This framework decomposes the monolithic task of “building an ontology” into four sequential, manageable tasks that an LLM pipeline can execute:

1. Task A (Text2Onto): The pipeline extracts raw ontological terminologies and candidate concepts from unstructured text (e.g., corporate policies, medical transcripts).
2. Task B (Term Typing): The LLM maps a specific lexical term to a generalized conceptual type (e.g., mapping “Aspirin” to the class Medication).
3. Task C (Taxonomy Discovery): The system establishes the hierarchical backbone by predicting rdfs:subClassOf relationships between type pairs (e.g., determining that RetailBanking is a subclass of FinancialService).
4. Task D (Non-Taxonomic Relation Extraction): The LLM identifies semantic object and datatype properties linking distinct classes (e.g., employs, hasJurisdiction).

By breaking the process down, knowledge engineers can evaluate and correct the LLM’s output at each stage, preventing early extraction errors from cascading into complex logical contradictions later in the pipeline.

Methodology-Driven Prompting: NeOn-GPT

Unstructured, zero-shot prompting (e.g., “Generate an OWL ontology for a hospital”) generally yields poor, shallow models. Research demonstrates that combining traditional ontology engineering methodologies with LLMs yields vastly superior results. One prominent approach is methodology-driven prompting, exemplified by the NeOn-GPT pattern.

Instead of asking for an ontology outright, a NeOn-GPT pipeline guides the LLM through a systematic, step-by-step process based on the NeOn methodology:

• Step 1: The LLM is fed a natural language domain description and prompted to generate a comprehensive list of Competency Questions (CQs) the ontology must answer.
• Step 2: The engineer reviews and refines the CQs.
• Step 3: The LLM is prompted to extract candidate classes and properties specifically required to answer those approved CQs.
• Step 4: The LLM translates these specific entities into formal axioms using valid Turtle syntax.

This constraint-based approach forces the AI to ground its formalization in explicit use cases, drastically reducing hallucinations and irrelevant class generation.

Going Meta S03E07 – Agent Skills For Creating and Using Ontologies

Structured Extraction with OntoGPT & SPIRES

When extracting ontologies from highly complex scientific or enterprise text, tools like OntoGPT (developed by the Monarch Initiative) provide a robust architectural pattern. OntoGPT utilizes a method called SPIRES (Structured Prompt Interrogation and Recursive Extraction of Semantics).

SPIRES takes a predefined schema (often written in LinkML) and a block of free text as inputs. It uses zero-shot learning to recursively extract nested semantic structures. Because the LLM is tightly constrained by the provided schema, its output can be deterministically serialized into conformant RDF, OWL, or JSON-LD.

For example, if you are building an ontology for agentic context, you can provide SPIRES with a schema defining Agent, Tool, and Action. The LLM reads execution logs and populates instances and relationships that strictly adhere to your schema, automating the creation of an operational knowledge graph.

End-to-End Taxonomic Generation (OLLM)

While breaking down tasks (like in LLMs4OL) is excellent for precision, piecemeal generation sometimes fails to capture the complex, holistic interactions of a domain. Modern approaches like OLLM (End-to-End Ontology Learning with LLMs) attempt to generate entire taxonomic backbones in a single, fine-tuned pass.

OLLM utilizes custom regularizers during the fine-tuning phase to prevent the LLM from overfitting on high-frequency, generic concepts (like Person or Organization). By penalizing the model for defaulting to overly common terms, OLLM forces the generation of deep, domain-specific hierarchies that represent true expert knowledge rather than surface-level generalizations.

Automated Multi-Stage Validation Pipelines

Because LLMs lack inherent logical reasoning, their output must never be committed to a production ontology without passing through an automated, multi-stage validation pipeline. A robust pipeline consists of three distinct gates:

1. Syntax Checking: The raw text output is parsed using standard libraries (like RDFLib or Apache Jena) to ensure the RDF/Turtle serialization is structurally valid. Syntax errors are fed back to the LLM for self-correction.
2. Logical Consistency: The parsed graph is evaluated by an OWL reasoner (such as HermiT or Pellet). The reasoner checks for unsatisfiable classes, disjointness violations, or logical contradictions (e.g., an entity being both a Human and a Machine if those classes are declared disjoint).
3. Structural Integrity: Finally, SHACL (Shapes Constraint Language) shapes are applied to validate that the generated graph conforms to required data shapes, cardinality constraints, and specific property paths.

Caveats, Trade-offs, and Common Mistakes

When incorporating AI into your ontology engineering workflow, be aware of several critical pitfalls:

The Context Window vs. Graph Scale Trade-off: A frequent mistake is attempting to feed an entire large-scale enterprise ontology into an LLM’s context window to ask for additions. This leads to high token costs, latency, and severe hallucinations as the model’s attention mechanism degrades over long contexts. Instead, use modular ontology parsers to extract only the relevant subgraph (the “neighborhood” of the concept in question) or point the LLM to resolvable SHACL/OWL schemas hosted online to establish context dynamically.

OWL 2 DL vs. OWL 2 Full Violations with SHACL: When using LLMs to generate mixed SHACL and OWL ontologies, models frequently violate OWL 2 DL rules. SHACL is defined using RDFS concepts (e.g., rdfs:Class). If an LLM mixes SHACL shapes directly with OWL without explicitly mapping SHACL targets to owl:Class and properties to owl:ObjectProperty or owl:DatatypeProperty, the ontology inadvertently falls into OWL 2 Full. This makes the ontology mathematically undecidable for standard DL reasoners. Engineers must explicitly prompt the LLM to respect DL constraints or apply post-processing scripts to enforce strict OWL 2 DL typing.

Reasoning Limitations: Empirical evaluations consistently show that while foundational LLMs excel at lexical extraction (Tasks A and B), they struggle with complex logical reasoning and axiom generation. Always treat the LLM as an accelerator for the “blank page” problem, relying on deterministic semantic standards (OWL, SHACL) and human-in-the-loop verification for final logical authority.