An ontology, in artificial intelligence and data management, is a formal model that defines the concepts in a domain, their properties and the relationships between them, so that people and systems interpret information with the same meaning. It is what allows an AI agent to understand what your company means when it talks about a customer, an order or a risk.
What an ontology is in data and artificial intelligence
The term comes from philosophy, where it refers to the branch that studies being and what exists. Computer science adopted it with a far more practical meaning, and since the 1990s artificial intelligence has been interested in ontologies as a way of representing knowledge. The classic definition in knowledge engineering describes an ontology as a formal, explicit specification of a shared conceptualisation.
In business terms: an ontology sets out, in a form a machine can read, what exists in your business and how those things relate to each other. The W3C guide to the OWL language states that an ontology may include descriptions of classes, properties and their instances. In practice, it is made up of four elements:
- Classes: the concepts in the domain. Customer, Product, Order, Warehouse.
- Properties: the attributes of each class. A customer has a tax ID (NIF, in Spain), a sector and a registration date.
- Relationships: how classes connect. A customer places orders, an order contains products and a product is stored in a warehouse.
- Instances: the specific cases. A particular customer, an order with its number.
On top of this come rules that the system applies on its own. If the ontology states that every van is a vehicle, and it knows that a specific registration plate belongs to a van, it infers that it is a vehicle without anyone having to say so. This ability to infer is what separates an ontology from a simple list of definitions.
Ontology, taxonomy, data model and knowledge graph
These four concepts are often confused in management committees, and confusing them leads to a poorly scoped project or the wrong choice of tool.
datos.gob.es, the Spanish Government’s open data portal, orders data vocabularies by complexity: from simple lists, through synonym rings and taxonomies, to thesauri and ontologies, which are the most complex. That scale helps to place each element:
- Taxonomy: a hierarchy. It organises concepts into categories and subcategories with a single relationship, that of belonging. It is useful for classifying a product catalogue or a document management system.
- Ontology: adds any type of relationship, as well as properties and rules. It does not only say that a van is a vehicle: it says that a vehicle is assigned to a route, that a route goes through a warehouse and that a delay at that warehouse affects the orders on that route.
- Data model: describes how information is stored in a specific database, with its tables and columns. It answers a technical question; the ontology answers a business question.
- Knowledge graph: the actual data connected according to the structure of the ontology. The ontology is the blueprint and the graph is the building constructed with your data.
The Microsoft Fabric documentation sums it up in one sentence: the ontology declares which things connect and why, while the graph stores and computes the traversals between those connections.
Why ontology is back: AI agents need context
For years, ontologies were the preserve of universities, digital libraries and open data projects. What has brought them back to the centre of the business conversation is AI agents.
A language model that queries your data without context has to guess what each table means. If finance calls an active customer someone who has paid in the last twelve months and marketing calls it someone who has opened an email in the last ninety days, the agent has no way of knowing which definition to apply. It will answer confidently and, very probably, with a figure that nobody in the company recognises as theirs.
The ontology solves that problem at source. It defines once what an active customer is and ensures that every system, including AI agents, works from that same definition.
Microsoft has brought this idea into the core of its data platform. According to its official documentation, Fabric IQ, still in preview, is part of Microsoft IQ alongside Work IQ, Foundry IQ and Web IQ, and includes an ontology item that represents the enterprise vocabulary and semantic layer that unifies meaning across domains. Microsoft recommends using it when you need cross-domain consistency, governance and AI agent grounding, and states that the ontology grounds agents in shared business semantics and rules.
When a vendor like Microsoft makes ontology a component of its AI architecture, the subject stops being academic and becomes an architecture decision.
Ontologies and knowledge graphs in generative AI: from RAG to GraphRAG
La mayoría de asistentes corporativos funcionan hoy con RAG: antes de responder, el sistema busca fragmentos relevantes en la documentación interna y se los entrega al modelo. Funciona bien cuando la respuesta está en un párrafo concreto. Falla cuando la pregunta exige conectar información repartida en muchos documentos.
For that second case, Microsoft Research released GraphRAG, which its documentation describes as a structured, hierarchical approach to RAG, as opposed to semantic search over plain text snippets. The process extracts a knowledge graph from the text, organises entities into communities, generates summaries of each community and uses that structure when answering.
Our view: building and maintaining a graph carries a cost in extraction, modelling and maintenance that does not always pay off. It makes sense when business questions depend on relationships, such as a supply chain, dependencies between contracts or the knock-on impact of an incident. To find a clause in a manual, a well-designed RAG is usually enough.
RDF, OWL and the semantic web: the standards behind it
Ontologies are not any vendor’s proprietary invention. Behind them are open standards from the W3C, the consortium that defines web standards.
OWL (Web Ontology Language) is the reference language for writing ontologies. Its first version has been a W3C Recommendation since February 2004, and OWL 2 since October 2009. It builds on RDF, the data model of the semantic web: according to the W3C itself, any OWL 2 ontology can also be viewed as an RDF graph.
In Spain there are public examples in operation. According to datos.gob.es, the ciudades-abiertas.es initiative, promoted by the city councils of A Coruña, Madrid, Santiago de Compostela and Zaragoza together with Red.es, the Spanish public business entity, generates its vocabularies, such as the municipal agenda vocabulary, with OWL. And the Ontology Engineering Group at the Universidad Politécnica de Madrid has been working on vocabularies and ontologies since 1995.
Basing your enterprise ontology on standards has a practical consequence: it is not tied to a specific tool and can connect to vocabularies that already exist.
How to build an enterprise ontology
Building an ontology is more of a business task than a technology one. The method set out in reference academic material, such as that of the Universitat Politècnica de Catalunya, follows a sequence that still holds:
- Define the domain and purpose. Before modelling anything, you need to establish what the ontology will be used for and which questions it must be able to answer.
- Reuse what already exists. There are public ontologies and vocabularies that cover much of the generic ground. Starting from scratch is usually a waste of time.
- Define the classes and their hierarchy. The key concepts in the domain and how they are organised.
- Define properties and relationships. Which attributes each class has and how it connects to the others.
- Create the instances. Link the ontology to the real data.
If you already work with Power BI semantic models, you are halfway there: the Microsoft Fabric documentation covers generating an ontology from an existing semantic model, which gives you a starting point based on definitions your business already uses.
The mistakes we see most often are three. The first is trying to model the whole company at once; the UPC material itself warns that an ontology does not need to include every possible class in the domain. The second is leaving the work solely to the technology team: if the business does not validate the definitions, the ontology ends up describing tables instead of describing the company. The third is treating it as a static document, when it needs to be versioned and governed like any other data asset.
How we approach ontologies at BertIA
At BertIA we treat the ontology as the layer that connects data with artificial intelligence, not as an isolated project. We start from the business questions that users and agents need to be able to answer, and from there we identify the concepts that each department currently defines in its own way.
As Microsoft and Databricks partners, we start from the semantic models and catalogues that many companies already have in place, so that the ontology is connected to real data from day one and does not become a parallel document that nobody maintains. You can see how this work fits into our artificial intelligence services.
In conclusion
Ontology has moved from university departments to the centre of enterprise AI architecture for a practical reason: agents need to know what data means before they can reason about it. A well-built ontology defines that meaning once, shares it across systems and teams, and relies on open standards that avoid dependence on a single tool.
You do not need to model the whole company to get started. You need to choose a domain with impact, agree the definitions with the business and connect them to the real data.
If you would like to assess how an ontology could improve your agents’ answers and the consistency of your data, you can talk to our team at BertIA.
