Data Ontology

A data ontology is a formal, explicit representation of the knowledge in a domain: it defines which entities exist (customer, order, product, invoice), which attributes each one has and, above all, how they relate to one another. Unlike a database schema, which only describes how records are stored, an ontology captures the business meaning of that data so that people and machines interpret it the same way.

In practice, an ontology works like a concept map: it states that "a customer places orders," that "an order contains products" and that "a product belongs to a category." That web of relationships is what lets you answer complex questions without every system having to agree by hand. It is one of the pieces that organizes information when you build a semantic layer on top of data spread across many sources, something central to the analytics that Metrix powers.

The key is that an ontology is technology-independent: the same conceptual model can sit on top of a CRM, an ERP or a data warehouse and give all of them a common way of understanding the business.

Why an ontology matters in the data world

In most companies, the word "customer" means something different in each system: for sales it is an opportunity, for finance it is an account receivable and for logistics it is a delivery address. That ambiguity is the root of reports that do not add up. A data ontology solves the problem by writing down, in a structured way, what each concept is and how it connects to the others, so that the whole organization shares the same definition. It is the conceptual step that enables a real single source of truth, not just a technical integration of tables.

An ontology is typically made up of three ingredients: classes (the types of entity, such as Customer or Product), properties (attributes and relationships, such as "has email" or "purchased") and rules or axioms (logical constraints, such as "an invoice always belongs to a customer"). With those elements, a machine can infer new knowledge: if it knows that A supplies B and B supplies C, it can deduce chains that no record stores explicitly.

How it works in a real project

The usual path starts by interviewing the business to list the important entities and their vocabulary. Then comes the modeling: you define the classes, map the relationships and document the synonyms (that "legal name" and "company name" are the same thing). That model is then implemented in a semantic layer that sits on top of the data warehouse or the data lake, translating business queries into the physical tables. The result is that a user can ask for "sales by region last quarter" and always get the same figure, no matter which tool they query from.

• Defines the business's common vocabulary, eliminating contradictory interpretations across departments
• Enables inference: deducing relationships that are not explicitly stored in any table
• Gives context to AI: an agent or language model that relies on an ontology makes fewer mistakes because it understands how the data connects
• Survives technology changes: the conceptual model does not break if you migrate from one system to another tomorrow
• Improves governance: it makes data governance easier by making definitions and rules explicit

A concrete example in Argentina

Picture a consumer goods distributor operating across several provinces. Its CRM records "customers," its billing system handles "accounts" and its inventory ERP talks about "delivery points." Without an ontology, working out "how much we sold to supermarket X" means cross-referencing spreadsheets by hand and hoping the names match. With an ontology that declares Supermarket X as a single entity linked to its branches, its invoices and its orders, the figure comes out on its own and is consistent. When that same company wants to add an AI agent that answers questions about the business, the ontology is what keeps the agent from confusing two different "Distribuidora del Sur" companies.

Common mistakes

The first is confusing the ontology with the physical database model: the ontology describes the business, not the tables. The second is modeling too much up front; it is better to start with the five or six entities that move the needle and grow from there. The third is treating it as a static document: an ontology that does not keep pace with the business ages quickly and brings back the very ambiguity it was meant to solve.

How it differs from a database schema

This is the most common confusion. Both describe structure, but they work at different levels:

In short, the schema answers "where is the data" and the ontology answers "what does this data mean and what does it connect to." The companies most mature in analytics use both layers: the schema sustains performance and the ontology sustains meaning.