Data ontology: what it is, how it differs from taxonomy and why master data needs it for AI to work

Data ontology is the formal representation of the concepts in a domain and the relationships between them: what the company means by customer, supplier, material, contract, cost center, and how those entities connect with one another. It is not a loose glossary or a list of terms. It is a map of meaning, with rules, that says a supplier can have several distribution centers, that a material belongs to a family and that a contract is tied to an approved supplier and to a specific cost center.

In almost thirty years working with master data and SAP, I have seen many companies confuse ontology with taxonomy and with a data dictionary. They are cousins, but they are not the same thing, and that confusion gets expensive when the subject turns into an artificial intelligence project.

Ontology, taxonomy and metadata: what is the difference

Taxonomy is hierarchy. Think of biology class: kingdom, phylum, class, order, family, genus, species. In the material master it works the same way: group, subgroup, category, item. It organizes from the top down, one box inside another.

Ontology goes beyond hierarchy. It describes the relationship between concepts that are not parent and child. A supplier relates to a contract, a contract relates to a cost center, a cost center relates to a business unit. Ontology says how those pieces talk to each other, not just which shelf each one lives on.

Metadata is something else again: it is data about data, the field that describes the field. Metadata says the column is called CNPJ (Brazil's company registration number), that it is a text field, that it has fifteen positions and that it is mandatory. Ontology uses metadata, but it is not limited to it.

The company that only has taxonomy knows how to classify. The company that has ontology knows how to explain how things connect, and that is what makes a system, or an AI agent, make the right decision without asking twice.

How data ontology works in practice

Let me share an example I lived through on an SAP project. A consumer goods company had its material master organized by taxonomy: merchandise group, division, family. Beautiful on paper. But when the purchasing team asked which approved suppliers served a certain material family, in a certain region, with a certain delivery time, the system did not answer. The information existed, scattered across different tables, with no formal relationship between material, supplier, region and lead time.

Building the ontology there meant explicitly declaring that a material belongs to a family, that a family can be supplied by a set of approved suppliers, that each supplier serves certain regions and that each supplier-region relationship has an average delivery time attached. That is not one more field in the table. It is a structure of relationships that the MDM system, the ERP and, more recently, the AI agent can traverse to answer real questions.

Today, with companies testing AI agents to suggest an alternative supplier or to screen quotes, that structure is no longer a data architect's luxury. Without it, the AI answers with what it finds loose in the text, and what it finds loose is usually wrong.

Who is responsible for ontology inside the company

Ontology does not come ready-made from a software vendor. It comes from a conversation between those who understand the business and those who understand the data. Usually the data architect leads the technical modeling, but the business area defines the meaning of each concept: purchasing says what an approved supplier is, maintenance says what a critical asset is, sales says what a strategic customer is.

The data steward comes in to make sure that definition becomes a rule applied in everyday record maintenance, not a document forgotten in a shared folder. Data governance comes in to arbitrate when two areas disagree about the meaning of the same term, which happens more than you would think. I have seen purchasing and legal disagree about what counts as an active supplier, and without a formal owner of the decision, each system ends up with its own version of the truth.

Which tools support data ontology

To model and maintain the ontology, the company normally combines an MDM platform with a catalog and metadata layer. In the MDM world, SAP MDG, Informatica, Stibo Systems, Reltio, Semarchy, Profisee and Ataccama offer structure to model entities and their relationships. For the data catalog and the semantic layer, Collibra, Alation and Microsoft Purview help document and connect the meaning of terms to the real data flowing through the systems.

For those who work with knowledge graphs, there are also specific ontology modeling tools, more common in more mature data teams, which represent relationships as a graph instead of a table. No tool, by itself, creates the ontology. It helps record and maintain what the business has already decided. Those who decide the meaning are still people, not a software license.

How to learn data ontology

In most curricula there is no course called simply data ontology. It appears inside the subjects of data modeling, information architecture and governance, in the DAMA-DMBOK body of knowledge. Those who seek a market-recognized certification, DAMA's CDMP, study conceptual modeling, taxonomy, ontology and metadata within the same chapter, because in practice they hold each other up.

The fastest path I have seen work is practical: take a real domain of the company, such as supplier or material, and draw by hand, on a whiteboard, which entities exist and how they relate, before opening any tool. After that, yes, study conceptual and logical modeling, understand the difference between one-to-one, one-to-many and many-to-many relationships, and only then bring it into an MDM or catalog platform.

Career opportunities

Professionals who understand data ontology tend to move well between data architecture, governance and, more recently, applied artificial intelligence projects, because it is exactly this structure of relationships that supports a reliable AI agent. Data architects with this skill are sought after by companies that are organizing their master data for an AI project, and the market pays more to those who can translate this for the business, not just for a technical diagram.

Demand grows alongside companies' race for generative AI applied to internal processes. Every company wants the agent that answers questions about suppliers, contracts or inventory. Few have the ontology organized so that this agent answers correctly. That becomes a real opportunity for those who already work with master data and want to stand out.

Main questions about data ontology

Is data ontology the same as taxonomy?

No. Taxonomy organizes by hierarchy, from the top down. Ontology describes relationships between concepts that do not follow a hierarchy, such as supplier, contract and cost center.

Does every company need a formal ontology?

Not at the same depth. A small company, with few systems, gets by with a well-built taxonomy and data dictionary. A large company, with multiple integrated systems and an AI project underway, misses ontology quickly.

What is the relationship between data ontology and MDM?

MDM is where ontology becomes a rule applied in everyday master data work. There is no point in drawing the ontology in a document if the master data system does not apply those relationships when creating a supplier, customer or material.

Why does artificial intelligence depend so much on this?

Because a language model, or an agent that queries the master data, only answers well when the relationship between concepts is explicit somewhere. Without ontology, the AI tries to guess the relationship from loose text, and guessing with corporate data becomes an expensive mistake.

Who should lead this work in the company?

The data architect leads the technical modeling, but the definition of what the terms mean has to come from the business areas, with data governance arbitrating disagreements between areas.

MDM Academy

MDM Academy is 4MDG's school of data governance and master data. It was created to train the professional that the Brazilian market still has too few of: people who understand master data, understand the business and understand how to structure those two things inside a real MDM system, with examples from SAP, procurement and supply chain, not just theory.

Those who go through MDM Academy's courses come out with a structured path to master data modeling, taxonomy, ontology, data quality and applied governance, with the same kind of practical example I use in my projects. If you want to go deeper than this article, it is worth getting to know MDM Academy or joining Data Club, our community of master data and governance professionals who exchange real experience every day.

Conclusion

Data ontology is not an academic fad or a decorative chapter in a governance book. It is the missing piece in many companies that invested in taxonomy, invested in a data dictionary, and still watched their AI project stumble because the system did not know how the master data entities related to one another.

Those who organize this structure now get ahead, because they will not have to redo all their master data when the next AI agent comes knocking, asking for the right answer about a supplier, material or customer. Good governance has always been about this: deciding the meaning before the system, or artificial intelligence, decides for you.