Ontology vs. Data Model: A Practical Distinction

The Schema Everyone Knows

A team needs to model suppliers. They open pgAdmin, create a suppliers table with columns like id, name, country, payment_terms, and is_active. They add a foreign key to purchase_orders. They write an API on top. Done.

This works. It works for a long time. It works right up until the moment three other teams build their own suppliers tables with slightly different columns, different definitions of "active," and different assumptions about what a supplier actually is. Now you have four sources of truth, and none of them agree.

The relational schema did its job. It stored data. But it never captured meaning. That is the gap an ontology fills.

Same Supplier, Different Universe

Let us walk through a concrete example. We want to model a Supplier — the same concept, represented two different ways.

The Relational Version

In a relational database, a Supplier is a table. It might look like this:

CREATE TABLE suppliers (
  id          SERIAL PRIMARY KEY,
  name        VARCHAR(255) NOT NULL,
  country     VARCHAR(2),
  rating      DECIMAL(3,2),
  is_active   BOOLEAN DEFAULT true,
  created_at  TIMESTAMP DEFAULT NOW()
);

CREATE TABLE supplier_contracts (
  id           SERIAL PRIMARY KEY,
  supplier_id  INT REFERENCES suppliers(id),
  start_date   DATE,
  end_date     DATE,
  max_value    DECIMAL(15,2)
);

This schema tells PostgreSQL how to store supplier data. It enforces basic integrity — you cannot create a contract for a supplier that does not exist. But it says nothing about what "active" means in a business context, whether a supplier with an expired contract is still considered active, or how a supplier relates to the raw materials it provides, the certifications it holds, or the geopolitical risks in its operating region.

The schema is a container. The meaning lives in the heads of the developers who built it, and in Confluence pages that no one reads.

The Ontology Version

In an ontology — expressed in OWL (Web Ontology Language) or a similar formalism — a Supplier is a class in a hierarchy:

Supplier ⊑ Organization
Supplier ⊑ ∃ hasCapability.ManufacturingCapability
Supplier ⊑ ∃ locatedIn.GeopoliticalRegion
Supplier ⊑ ∃ holdsContract.SupplyContract

ActiveSupplier ≡ Supplier ⊓ ∃ holdsContract.(SupplyContract ⊓ ∃ hasStatus.Active)

SupplyContract ⊑ ∃ coversCategory.MaterialCategory
SupplyContract ⊑ ∃ hasComplianceCert.Certification

This is not documentation. It is a formal specification that machines can process. Supplier is a subclass of Organization — it inherits every property of organizations (address, legal entity, tax jurisdiction) without redeclaring them. An ActiveSupplier is not a boolean flag — it is a defined class: a Supplier that holds at least one SupplyContract with Active status. If the last contract expires, the supplier is automatically reclassified. No cron job needed.

What the Ontology Can Do That the Schema Cannot

Reasoning Over Indirect Relationships

Suppose you need to answer: "Which of our suppliers operate in regions affected by new EU import restrictions?"

With a relational schema, this requires a developer to write a custom query joining suppliers to countries to regulatory databases, assuming someone built those joins. If the regulatory data lives in a different system — and it always does — you are writing integration code.

With an ontology, the answer is a query over the knowledge graph. Supplier locatedIn GeopoliticalRegion; GeopoliticalRegion subjectTo RegulatoryFramework. The OWL reasoner traverses these relationships automatically. You do not need to anticipate every question at schema design time, because the relationships are declared at the semantic level and composed at query time.

A relational schema answers questions you anticipated at design time. An ontology can answer questions you did not think to ask, because the relationships are declared at the semantic level and composed at query time.

Cross-System Constraints

In a typical enterprise, supplier data spans SAP MM (procurement), Ariba (sourcing), a custom vendor portal, and probably a spreadsheet someone in compliance maintains. Each system enforces its own constraints. None enforce constraints across systems.

An ontology axiom like "A Supplier cannot be assigned to a new PurchaseOrder if its ISO 9001 certification has expired" applies regardless of which system creates the PurchaseOrder. The axiom lives in the ontology, not in SAP's configuration, not in Ariba's business rules, not in a Python script. It is a single rule with universal enforcement.

This kind of gap is well-documented. Non-certified suppliers receiving purchase orders because the certification check exists in one system but not in the side-channel that buyers actually use is a recurring pattern in procurement audits. A shared ontology can eliminate that class of error.

Evolution Without Breakage

Relational schemas are brittle in a specific, painful way. Adding a column is easy. Changing a relationship is not. If you decide that a Supplier can hold multiple certifications instead of one, you need a new junction table, migration scripts, API changes, and downstream consumer updates. Every consumer of the schema must adapt.

Ontologies handle this differently. In OWL and RDFS, adding a new subclass, a new property, or a new relationship does not break existing consumers. A system that only cares about Supplier.name and Supplier.country continues to work even after you add Supplier.sustainabilityScore and a new EnvironmentalCertification class. The ontology is open-world by default: the absence of information is not a contradiction. New knowledge extends the model without invalidating existing knowledge.

This is the Open World Assumption that RDFS and OWL are built on, and it is the opposite of how SQL databases work. In SQL, if a column does not exist, querying for it is an error. In an ontology, if a property is not asserted, it simply is not known yet.

Why This Matters Now

When an enterprise had five systems, humans bridged the semantic gaps with institutional knowledge and manual processes. When the same enterprise runs two hundred systems, those gaps compound faster than anyone can patch them with integration code.

Two specific pressures have made this worse. AI systems, particularly LLMs, produce more reliable results when grounded by structured domain knowledge rather than flat data dictionaries -- and most organizations do not have that structure. Meanwhile, the pace of business change is making schema-migration-driven evolution increasingly painful: every new product line, acquisition, or regulatory requirement means another round of ALTER TABLE and downstream fixes.

When a supplier model cannot express the difference between a contract manufacturer and a raw material supplier, or cannot track the certifications required to sell into the EU market, the problem is not the data. It is the modeling.

The Practical Takeaway

A data model tells a database what to store. An ontology tells an organization what things mean. You need both, but they serve fundamentally different purposes, and treating an ontology as "just a fancy schema" misses the point entirely.

The relational schema is a physical artifact — it describes how data is stored in a specific system. The ontology is a logical artifact — it describes how concepts relate across all systems. The schema is closed-world: what is not declared does not exist. The ontology is open-world: what is not declared is simply not yet known.

For a single application, a schema is almost always sufficient. But when you need to integrate across systems, ground AI in domain knowledge, or enforce rules that span organizational boundaries, a schema hits a wall. That wall usually shows up as a growing pile of integration code that encodes implicit semantics in scattered if-statements -- semantics that an ontology would make explicit and machine-processable.