Built with Tutify.io

    AIStudyLabs

    Ontology in Data and AI: A Practical Guide for Engineers

    Ontology in Data and AI: A Practical Guide for Engineers

    Two teams in the same company can both have a table called customer and still mean different things. Sales counts anyone who signed a contract. Support counts anyone who opened a ticket. Finance counts whoever pays the invoice. Every join between their data quietly mixes three definitions, and every dashboard built on top inherits the confusion. An ontology is the tool for fixing that kind of problem: a shared, written-down model of what the things in a domain are and how they relate, precise enough that software can use it.

    This guide is the starting point for a series on ontology in data and AI. By the end you should be able to tell whether your problem needs an ontology at all, and if it does, how to start one without a six-month modelling project. Each section links to a deeper article when you need the detail.

    What is an ontology?

    The word comes from philosophy, where it means the study of what exists. In computer science, Tom Gruber's 1993 paper in Knowledge Acquisition described an ontology as a specification of a representational vocabulary for a shared domain of discourse, and later authors, notably Borst (1997) and Studer and colleagues (1998), expanded that into the definition most people quote today: a formal, explicit specification of a shared conceptualization.

    Strip the academic phrasing away and you are left with four parts:

    The W3C's OWL 2 overview uses almost the same list when it describes what the language models: classes, properties, individuals and data values. The axioms are what separate this from a list of terms. They let a machine draw conclusions you never wrote down. If the model says every Instructor is a Person, and the data says Priya is an instructor, a reasoner knows Priya is a person without anyone storing that fact.

    Ontology vs schema

    A database schema describes how data is stored: tables, columns, types, keys. An ontology describes what the data means, independent of storage. The same model can sit over a Postgres table, a Parquet file and a REST API at once. That independence is the whole point. A schema is tied to one system; the shared model is a contract between systems.

    Ontologies, taxonomies and knowledge graphs

    These terms get used interchangeably in vendor material, which makes them hard to learn. They form a ladder of increasing formality:

    | Structure | What it holds | Example | |---|---|---| | Controlled vocabulary | An agreed list of terms | Allowed values for country | | Taxonomy | Terms arranged in a parent-child hierarchy | Electronics > Phones > Smartphones | | Thesaurus | Hierarchy plus synonyms and related terms | "Cell phone" as an alternative label for "Mobile phone" | | Ontology | Classes, properties, individuals and logical rules | "A smartphone is a phone with an operating system" | | Knowledge graph | Entities and facts, typed by that model | Pixel 9 madeBy Google, runsOS Android |

    The most useful distinction to hold on to: the ontology is the schema layer, and the knowledge graph is the instance data that follows it. A knowledge graph without an ontology is a pile of labelled edges with no agreed meaning. A model without instance data is one nobody uses. The full comparison, including when a taxonomy is all you need, is in ontology vs taxonomy vs knowledge graph.

    How an ontology is written down

    You can sketch a domain model on a whiteboard, but to be useful it has to be machine-readable. The W3C semantic web standards are the common choice:

    Here is a small fragment in Turtle, the most readable RDF syntax:

    @prefix edu:  <https://example.org/edu#> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

edu:Instructor a owl:Class ;
    rdfs:subClassOf edu:Person .

edu:teaches a owl:ObjectProperty ;
    rdfs:domain edu:Instructor ;
    rdfs:range  edu:Course .

    Every name is an IRI, so your edu:Course can never collide with someone else's Course. That global naming is what makes merging data from different sources practical. The trade-offs between these standards, and the classic traps such as expecting rdfs:range to reject bad data, are covered in ontology languages explained: RDF, RDFS, OWL and SHACL.

    You don't need a specialist tool to start. Protégé, a free editor from Stanford, is a common choice, but a Python library is enough for a first version, and it keeps the model in version control next to your pipelines. The hands-on walkthrough in how to build an ontology in Python with RDFLib goes from empty file to SPARQL queries and SHACL validation.

    Where an ontology helps in data engineering

    Integrating data that was never designed to fit

    The most common reason data teams reach for one is integration. You have a CRM, a billing system and a product database, each with its own idea of a customer. Instead of writing point-to-point mappings between every pair, you map each source to one shared model. Adding a new source then means one new mapping instead of one for every system you already have.

    This is called ontology-based data access (OBDA), also known as a virtual knowledge graph: the data stays in its source databases. The W3C standardized the mapping language, R2RML, in 2012, and tools such as Ontop translate SPARQL queries over the shared model into SQL that runs on the original tables. The architecture, the virtualize-or-materialize decision and the pitfalls are in ontology-based data integration with virtual knowledge graphs.

    Ontology and the semantic layer

    Analytics teams already know a lighter version of this idea. A semantic layer, such as the dbt Semantic Layer built on MetricFlow, defines metrics like revenue once so every dashboard computes them the same way. That is a narrow, analytics-focused cousin of an ontology. It defines entities, dimensions and measures for SQL aggregation, but it has no formal logic and no reasoning. In October 2025 dbt Labs released MetricFlow under the Apache 2.0 licence and joined the Open Semantic Interchange effort led by Snowflake. MetricFlow itself came to dbt Labs through its 2023 acquisition of Transform.

    If you already run a semantic layer, a full model is the next step when you need meaning that goes beyond metrics: what a customer is, which products belong together, which regulations apply to which accounts.

    Domain ontologies you can reuse

    Building from scratch is rarely the right call. Mature ontologies exist for many domains:

    | Ontology | Domain | Scale or status | |---|---|---| | schema.org | Web content, products, events | 826 types and 1,540 properties in version 30.1 (September 2026) | | SNOMED CT | Clinical terms | More than 360,000 concepts, released monthly | | Gene Ontology | Gene function | 38,560 terms in the March 2026 release | | FIBO | Financial business concepts | Maintained by the EDM Council, updated quarterly |

    Reusing one of these gives you definitions that other organizations already understand. The common mistake is importing the whole thing. Take the slice you need, link to the original IRIs, and extend only where your business differs.

    FAIR data

    In research data, the FAIR principles published in 2016 ask that data be Findable, Accessible, Interoperable and Reusable. Two of the interoperability principles are effectively a requirement for ontologies: metadata should use a formal, shared language for knowledge representation, and vocabularies that are themselves FAIR. The principles were set out by Wilkinson and colleagues in Scientific Data in March 2016. Metadata can only be interoperable across labs if everyone describes it with the same terms and the same relationships between them, and that shared model is what an ontology provides.

    Why do ontologies matter for AI?

    Large language models renewed interest in ontologies. A 2024 roadmap by Pan and colleagues in IEEE TKDE set out how knowledge graphs and LLMs can strengthen each other. An LLM is fluent but has no stable model of your domain. It will happily invent a product category, merge two customers with similar names, or describe a policy that doesn't exist. A curated domain model gives the system something fixed to check against.

    Grounding LLM answers

    There are three common ways to combine the two:

    1. Constrain extraction. Give the model the classes and properties it may use when it turns text into structured data. The SPIRES method from 2023 did exactly this, then grounded each extracted value to identifiers in existing ontologies.
    2. Link entities. Map every mention in a question or document to a canonical ID, so "IBM", "International Business Machines" and "Big Blue" become one entity.
    3. Validate outputs. Check generated facts against the model's rules and SHACL shapes before they reach a user or a database.

    The research also runs the other way. Projects such as LLMs4OL test how well LLMs can help build ontologies by suggesting terms, types and hierarchies. The LLMs4OL study tested nine LLM families zero-shot on term typing, taxonomy discovery and relation extraction. The details, with the limits and costs, are in ontologies and LLMs: grounding AI answers and agents.

    Knowledge graph retrieval for RAG

    Standard retrieval-augmented generation finds text chunks that look similar to the question. It struggles with questions about a whole corpus, such as "what are the main themes across these 2,000 reports?" Microsoft's GraphRAG work, published in April 2024, builds a knowledge graph from the documents with an LLM, groups related entities into communities and summarizes them, then answers from those summaries. On a podcast corpus of about 1 million tokens, its answers beat plain vector RAG on comprehensiveness in 72 to 83 percent of comparisons, judged by an LLM. The cost is in indexing: the project's own README warns that indexing can be expensive and advises starting small.

    Left alone, the LLM chooses its own entity types, and you get a graph with Company, Organisation, Firm and Business as four separate types. An ontology fixes the types and relationships up front, which makes the graph consistent enough to query. That approach, and the cost trade-offs against plain vector search, is covered in ontology-driven GraphRAG.

    Shared vocabulary for AI agents

    Agents need to know not just what exists but what they are allowed to do. Palantir's Foundry documentation describes its Ontology as an operational layer for the organization, with objects, properties and links on one side and actions on the other. In its AIP tooling, agent tools are object queries, functions and actions that execute ontology edits, either automatically or after a person confirms, so every agent step goes through a defined operation on a defined object.

    How to start your first ontology

    A common way for an ontology project to stall is trying to model the whole enterprise at once. Start with a question you can't answer today.

    1. Write competency questions. These are the questions the model must be able to answer, such as "which customers have an open support ticket and an overdue invoice?" They set the scope and become your tests.
    2. Reuse before you invent. Check schema.org and the domain ontologies above. Reuse their classes where the meaning matches.
    3. List the terms. Pull nouns and verbs from the competency questions, existing table names and business glossaries.
    4. Define a small class hierarchy. Five to fifteen classes is plenty for a first version.
    5. Add properties with domain and range. Keep them few and well named.
    6. Load real data and query it. If you can't answer a competency question with a SPARQL query, the model is missing something.
    7. Add SHACL shapes for the rules that must hold in production data.

    This follows the steps in Noy and McGuinness's Ontology Development 101, a guide first published around 2001 and still widely cited.

    Common mistakes

    When an ontology is not worth it

    An ontology costs real effort to design and maintain, and that cost is not always justified. If your data lives in one well-modelled warehouse, a clear dbt project and a semantic layer may give you everything you need. If your only problem is a messy picklist, a controlled vocabulary or a SKOS taxonomy is cheaper. The investment pays off when several systems or teams must agree on meaning, when the rules matter (regulated industries, healthcare, finance), or when AI systems need a fixed reference to check their output against.

    Articles in this series

    Key takeaways