Why We Need an Ontology
An ontology is a written map of the things your business runs on and how they connect. Why you need one the day your answers depend on connections across systems, what the building blocks are, which tools build it, and how to build one in-house.
TL;DR
An ontology is a written map of the things your business runs on, customer, order, product, shipment, and the rules for how they connect. You need one the day your answers stop living inside a single system and start depending on connections that span several. That is the day a table can no longer answer the question and a person starts stitching the systems together by hand. The case only grows from there, with every system you add and every AI assistant you point at your data, because both need one honest definition of what your things are.
- The problem it solves. Every system keeps its own private idea of "customer." The ontology is the shared map they all agree to point at.
- When the case is strong. Your real questions are about connections, and bridging those connections by hand has become a standing tax.
- What you build. A written contract first. A graph underneath only when your questions turn from counts into paths.
Scope
Vendor-neutral. The examples name Microsoft Fabric, Palantir Foundry, Neo4j, and the W3C RDF stack, but the reasoning holds whatever you build on.
The dots, and why they stay apart
Your business is already a graph. Customers place orders, orders ship from warehouses, warehouses source from suppliers, suppliers sit inside countries with their own rules. The dots are real, and in the world they are connected.
Your data is not. The CRM knows customers, the billing system knows accounts, the support tool knows contacts, and none of them share an id or an agreed definition. So the moment a question crosses two of them, "which paying customers filed a support ticket last week," no single system can answer it. Someone exports three files, lines them up in a spreadsheet, and rebuilds the connection by hand. Next month the same question arrives and the same person rebuilds the same join.
An ontology is the decision to connect those dots once, on purpose. It writes down what your things are and how they relate, in one place every system can point at, so the join lives in the map instead of in a spreadsheet that gets recreated forever. That is the whole idea, and it is why "connecting the dots" is not a metaphor here. It is literally the job.
What makes the case strong
The trigger is never size for its own sake. A three-person startup can need one and a large bank can get by without. The real signal is a symptom: your answers depend on connections that no single system holds, and reconciling those connections has become recurring manual work that nobody put on a budget.
Count the systems that store your core entity today. One, and nothing can disagree, so you already have an ontology written into how that system is named. A few that give different answers to the same question, and you have a definition problem. Questions whose answers are paths nobody can chart ahead of time, and you have crossed into the territory a graph is built for.
The checker below is the same logic, made concrete. Tick what is true for you.
Check every statement that is true today. The verdict updates as you go.
One source of truth means nothing can disagree. You already have an ontology, written into how your data is named. Leave it alone.
The building blocks
An ontology is not one thing. It is a small stack of parts, and knowing them apart is most of what keeps the project honest.
Fig 1. Entities, relationships, and rules are the cheap contract almost everyone needs. Identity and the graph store are the part large businesses have to pay for.
- Entities. The kinds of thing your business deals in: customer, order, product. Palantir Foundry calls these object types, and each real record is an instance of one.
- Relationships. How the entities connect, and in which direction. An order belongs to exactly one customer; a customer has many orders. These are the links you will later walk.
- Rules. What must always be true. A shipment cannot exist without an order. This is what makes an ontology more than a diagram, it can reject data that violates the shape of the business.
- Identity. Deciding that customer 4471 in the CRM and account 90b in billing are the same person. This is the hardest part, and the one that never fully finishes.
- The graph store. Where it all lives, often a graph database, so the connections are cheap to traverse rather than reassembled with joins each time.
The first three are the contract. They hold no data, cost almost nothing, and are the part nearly every business actually needs. Identity and the store are where scale, freshness, and a monthly bill enter the picture.
Why a graph
Most ontology systems sit on a graph, and the reason is the shape of the questions. A table is superb at magnitude: how much revenue, by region, this quarter. It is poor at structure: which of our suppliers, two or three steps removed, are exposed to a sanctioned entity. That answer is a path, not a total, and you do not know how many hops it runs until you walk it. Ask that of a warehouse and you get a chain of joins nobody can write in advance. Ask it of a graph and you get the path back directly.
The deeper reason a business keeps its own idea of "customer" in every system is that the systems were never built to agree. The ontology is the one map they converge on.
Fig 2. Each system holds its own private version of the same person. The ontology is where they are reconciled into one definition every tool can trust.
This is also why ontologies stopped being an enterprise-architecture curiosity and turned urgent. Point a language model straight at your raw database and it guesses, confidently and wrongly. Give it the ontology and it knows what your things are and how they connect. This is the pattern behind GraphRAG: the ontology constrains which entities and relationships the model may extract and ask about, so its answers are anchored to defined connections instead of free-form guesses. The mechanics of turning a question into a query and back are their own subject, covered in knowledge retrieval systems.
The tools that build one
The tools that build ontologies span from a folder of text files to a platform that runs your operations. Heavier is not better. Pick the lightest rung that answers your questions.
In Microsoft Fabric, the ontology is built in three moves: model a shared vocabulary of entity types, map each source system's data onto them, then add the semantic relationships that connect them. Neo4j, at the other end, is an operational store and does not do OWL-style reasoning on its own; teams that need that layer it on top.
Building one in-house
Yes, you can build one yourself, and for a single well-chosen domain it is a genuinely good project to own end to end. The order matters more than the tools.
- Pick a slice. One domain, five to ten entity types. Resist the urge to model the whole company on day one. That instinct is what kills these projects.
- Write the contract. Plain files first: the entities, their relationships, the rules that must hold. Version-controlled, reviewed like code, no database yet. Most of the value is already here.
- Load the instances. Point it at real records. A property graph such as Neo4j with Cypher is the friendliest start; the RDF/OWL stack if you need formal reasoning and interoperability.
- Resolve identity. The unglamorous majority of the work: matching the same real thing across every source. Budget more time here than for all the other steps combined.
- Govern it. Owners, version history, and a way to change a definition without breaking everything that reads it.
The tempting shortcut is to have a language model extract the whole graph from your documents. It genuinely helps with the extraction in step 3. It cannot do the schema design, the identity resolution, or the governance, and those are most of the work, the parts that stay stubbornly human. Set expectations accordingly: the first three steps are a weekend. Steps four and five are the actual project.
The bottom line
You need an ontology the day your answers depend on connections that live across systems, and that day tends to arrive sooner than teams expect. Start with the contract, cheap and universal, the moment two systems disagree about what a customer is. Add the graph when your questions turn from counts into paths. Add the governance the instant more than one person owns a definition.
The dots are already there, drawn by how your business actually works. An ontology is just the decision to connect them once, deliberately, instead of forever by hand.