Ontology

What is an ontology?

An ontology is a formal shared model of the concepts in a domain. It defines what kinds of things exist, which properties they have, which relationships are allowed, and what the terms mean.

In philosophy, ontology asks what exists. In data and IT, the meaning is more practical: an ontology is a machine-readable agreement about the language of a domain. It tells systems what a customer, product, order, dataset, policy, or organisation means and how those things connect.

You can think of it as the blueprint for meaning. It does not contain every real customer or product. It defines the kinds of things that can exist and the rules they follow.

The building blocks of an ontology

Classes. The categories in the domain, such as Customer, Product, Order, Supplier, Dataset, or Report. A class describes a type of thing, not one individual record.

Individuals. The real instances inside a class: Acme Ltd as a Customer, invoice 2026-001 as an Invoice, or the sales report as a Report.

Properties. Attributes such as name, price, date, email address, status, owner, or sensitivity level.

Relationships. Named connections between things: customer placed order, report uses dataset, supplier delivers product, employee owns data product.

Hierarchy. Classes can inherit from other classes. A VIP customer is a kind of customer, so rules that apply to customers also apply to VIP customers unless the ontology says otherwise.

Rules and constraints. Formal statements such as every order must belong to exactly one customer, or a cancelled order cannot also be open. Reasoning software can use these rules to infer facts or detect contradictions.

Example: a webshop ontology

A small webshop ontology might start with Customer, Product, Order, Payment, and Shipment.

It then defines relationships. A Customer places an Order. An Order contains Products. An Order has one or more Payments. A Shipment fulfils an Order. Those relationship names matter because they turn a pile of identifiers into a business model.

The ontology also defines properties. A Product has a name, SKU, price, category, and stock status. A Customer has an email address and delivery address. An Order has a date and status.

Once that model exists, different systems can disagree less. The ecommerce platform, warehouse system, reporting model, and AI assistant can all refer to the same concepts even if their internal tables look different.

Ontology, taxonomy, and database schema

Ontology versus taxonomy. A taxonomy is a hierarchy: product category, subcategory, product type. It mainly says this is a kind of that. An ontology can include a hierarchy, but it also defines relationships, properties, constraints, and rules. A taxonomy can say that a bicycle is a vehicle. An ontology can say that a bicycle has wheels, is used by a person, can be sold as a product, and may appear in an insurance claim.

Ontology versus database schema. A database schema describes storage: tables, columns, data types, primary keys, and foreign keys. It is tied to one system. An ontology describes meaning across systems. Two databases can use different schemas and still map to the same ontology.

Ontology versus semantic model. A semantic model usually serves analytics: tables, relationships, measures, and security in business language. An ontology is broader and more formal. It is often used for knowledge graphs, data catalogs, governance, and reasoning across domains.

RDFS and OWL

Ontologies are often written in standards from W3C, the standards organisation behind many web technologies.

RDFS, or RDF Schema, is the simpler layer. It lets you define classes, subclasses, properties, and the kinds of things those properties can connect.

OWL, the Web Ontology Language, adds richer logic. It can express constraints such as two classes being disjoint, a property having exactly one value, or one relationship implying another. Tools can use those statements to infer new facts and spot inconsistent data.

You do not always need a full OWL model. Many business projects start with a lighter vocabulary and a few strict rules, then formalise only the parts that need machine reasoning or cross-system exchange.

Ontology and knowledge graphs

A knowledge graph stores real entities and relationships: the actual customers, products, suppliers, datasets, reports, policies, and people. The ontology gives that graph its vocabulary and rules.

In simple terms, the ontology is the schema and dictionary. The knowledge graph is the populated network.

This is why ontologies matter for AI and data governance. A model or agent that sees a graph with clear definitions can understand that a report uses a dataset, that the dataset has an owner, that the owner belongs to a department, and that sensitive data must follow certain policies.

What to watch out for with ontologies

Do not model the universe. Start with the decisions or questions the ontology must support. Otherwise the model grows large and nobody uses it.

Business language comes first. If domain owners do not agree what a customer, product, or active contract means, OWL will not solve it.

Keep it connected to real data. An ontology that never maps to actual systems becomes a diagram exercise. Link it to metadata, catalogs, master data, or a knowledge graph.

Version it. Meaning changes. New product types, regulations, and reporting definitions need a controlled way into the ontology.