Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Ontology vs semantic layer decided with four questions. What a data ontology is, who owns what, and the vendor documentation behind every claim.
Updated on
A semantic layer governs how a business measures things. It holds the metric definitions, the dimensions, the valid join paths and the query time access rules, so that revenue means the same thing in a dashboard, a notebook and an AI agent. An ontology models the business itself: which entities exist, what properties they carry, how they relate, what constraints hold, and in operational implementations, which actions are permitted against them. The semantic layer produces a trusted number. The ontology produces a navigable picture of the situation that number came from.
This article builds on Jatin Solanki's piece on the same question, published on Medium in August 2026. His framing is the one we start from, and his words for it are these:
The semantic layer governs how the business measures the world. The ontology describes the world being measured.
What follows takes that division and makes it operational: a named test that routes you to one layer, both or neither, a contract that says who owns which concept, and every vendor claim checked against the vendor's own documentation rather than repeated from memory. If the comparison you actually came for is the context layer rather than the ontology, that is a different question and we answer it separately in context layer vs semantic layer.
The source article closes on an instruction rather than a recommendation. It says to start with the failure you actually have: if dashboards disagree, govern the calculations; if systems cannot agree on what their records represent, model the domain; if agents must move from questions to decisions that cross domains, connect the two. That instruction is correct and it is the right place to start. What it does not have is a procedure. The Failure First Test is that procedure. It is named after the instruction, it routes to the same answers, and it takes about ten minutes.
Answer all four questions before you read the routing table. Each one is answerable from something you already know about your own stack, so none of them requires an assessment or a vendor conversation.
Not what might fail later, and not what a vendor says is coming. Write down the failure that is costing you time this month. Two people producing different numbers for the same metric in the same week is a calculation failure. Two systems that hold the same customer under different identifiers, so nobody can say with confidence whether they are the same company, is a meaning failure. If you cannot name a failure in either category, that is a real answer and it routes you somewhere specific.
Look at where the output of your data actually lands. If it lands in dashboards, reports, notebooks and agents that answer analytical questions, the consumption is analytical. If it lands in operational applications, in agents that work across several business domains, or in interfaces where a person browses objects rather than filtering predefined dimensions, the consumption is operational. Most organizations have some of both; answer with where the pain is, not where the volume is.
A dimensional model is very good at slicing a measure by attributes that already sit in a stable hierarchy. It is much weaker when the work is traversal: following a part through suppliers, shipments, plants and production orders, or moving from a customer to its subscriptions to the products those subscriptions use to the incidents affecting those products. Ask whether your hard questions are answered by grouping rows or by walking a path. Entity resolution, provenance and temporal validity belong on the traversal side too: if you need to state explicitly when a fact was true and where it came from, that is a modeling requirement, not an aggregation one.
A read heavy workload ends when the number is returned. An operational workload does not: something has to be created, updated, approved or escalated, and the system has to know who is allowed to do it. If the answer to a question triggers a change to an operational object, the permitted change and the permission to make it have to be represented somewhere. That is not something a metric definition can hold.
Score each question, then read the outcome that matches your pattern. The table is the whole test; nothing else is needed to run it.
| Question | Points to the semantic layer when | Points to the ontology when |
|---|---|---|
| 1. What is failing? | People disagree about how a metric is calculated, or the same report gives different numbers depending on who ran it. | Systems disagree about what a record represents, or the same real world entity appears differently in several systems and nobody can reconcile them. |
| 2. What consumes the answer? | Dashboards, reports, notebooks and analytical agents. | Operational applications, agents reasoning across business domains, and users who explore objects rather than predefined dimensions. |
| 3. Relationships or attributes? | The relationships that matter already fit a stable dimensional model, and the hard questions are answered by grouping and aggregating. | The hard questions are answered by walking a path between entities, or lineage, provenance, temporal truth and entity resolution have to be explicit. |
| 4. Answer or action? | Workflows are read heavy and nothing acts against an operational object. | The system has to represent which actions are permitted, on what, and by whom. |
| Your pattern | What to build | Why |
|---|---|---|
| All four answers point to the semantic layer | A semantic layer only. | Your problem is executable metric governance. An enterprise modeling program will not fix a disagreement about a formula, and it will cost you a year finding that out. |
| All four answers point to the ontology | An ontology only. | Your problem is shared meaning and identity across systems, not calculation. Standardizing metrics you are not arguing about buys you nothing. |
| Question 1 shows both failures, or Question 4 says an answer must trigger an action | Both, with a written boundary between them. | An analytical answer that starts an operational workflow needs a trustworthy number and a reliable picture of what the number is about. One layer cannot give you both. Read the ownership contract below before you start either. |
| You could not name a failure in Question 1 | Neither yet. | Fix your data models and metric definitions first. Buying a layer to solve a problem you cannot describe is how you acquire a third thing to maintain. |
The fourth outcome is the one most often skipped and it is the one the source article is most direct about:
A small team with a handful of dashboards and one warehouse may gain more from fixing its data models and metric definitions than from introducing an ontology platform.
A useful sanity check on the third outcome, before you commit to running two layers: if the only reason both appear on your list is that an AI project is being scoped, run the test again in three months against the failures you have by then. Agents strengthen the case for explicit semantics, but they do not create a modeling requirement that was not already there.
A data ontology is a formal, shared model of the things your business deals with, written so that software can read it. It states which kinds of thing exist, what facts they carry, how they connect to each other, what rules keep those connections valid, and where in your data estate each of those things is actually stored. That last part is what separates a data ontology from an academic one: it is bound to real tables.
The formal definition comes from the W3C. The OWL 2 Web Ontology Language overview describes OWL 2 as "an ontology language for the Semantic Web with formally defined meaning" and says that OWL 2 ontologies "provide classes, properties, individuals, and data values and are stored as Semantic Web documents". That is the academic lineage of the word and it is worth knowing, because it explains why an ontology can support inference in a way a dimensional model cannot.
The enterprise version is more concrete. Microsoft's documentation for the ontology item in Fabric, a feature currently in preview, defines one in a single sentence that is worth reading closely, because it names all four parts:
An ontology is a shared, machine-understandable vocabulary of your business. It's made up of the things in your environment (represented as entity types), their facts (represented as properties on entity types), and the ways they connect (represented as relationships), while offering constraints and rules that keep representations consistent.
Entity types, properties, relationships and constraints are the model. Data binding is what connects the model to your data, and without it you have a diagram. The Microsoft documentation is precise about each one, and the definitions transfer to any platform:
| Part | What it is | What the documentation says it does for you |
|---|---|---|
| Entity type | The reusable logical model of a real world concept, such as Shipment, Product or Sensor. | It "standardizes the name, description, identifiers, properties, and constraints for that item", and by elevating the concept above any single table it eliminates conflicting column level definitions across sources. |
| Property | A named fact about an entity, with a declared data type. | Properties "improve semantics by enforcing consistent types, units, and naming, and by enabling rules and quality checks at the concept level". |
| Relationship | A typed, directional link between entity types or instances, which can carry its own attributes and cardinality rules. | Relationships enable "traversal, dependency analysis, rule based inference, and clearer answers to business questions without custom join logic". |
| Entity instance | A concrete occurrence of an entity type, populated from data bindings. | Instances "keep track of which source created them and when they were true", which is how temporal validity and provenance become explicit rather than implied. |
| Data binding | The connection between the model and concrete data, in Fabric's case lakehouse tables, eventhouse streams and Power BI semantic models. | A binding "describes data types, identity keys, how columns map to properties, and how keys map to relationships across multiple data sources", and it carries schema evolution rules, data quality checks and provenance at the concept layer. |
Two consequences of that table are worth stating plainly, because they are the practical reasons a data ontology is worth the effort. First, the entity type sits above the tables, so a definition of Customer stops being a column in whichever system happens to be authoritative this quarter. Second, because relationships are declared rather than discovered, a question that would otherwise require someone to write the correct join by hand becomes a traversal the model already knows how to make.
Some enterprise implementations go one step further and model not only what exists but what may be done to it. Palantir's documentation on action types states it directly: "In the Ontology, users can make changes to objects, properties, and links by applying actions", and an action type is "the definition of a set of changes or edits to objects, property values, and links that a user can take at once". That is the point at which an ontology stops being a description of the business and starts being an interface to it, and it is the capability Question 4 of the test is looking for.
We are not going to write another explainer of the semantic layer here; two Decube articles already cover it, one on how the catalog, the semantic layer and the warehouse fit together and one on what the semantic layer becomes in the AI era. What is worth adding is what the leading implementations actually put in the definition file, because that is the most concrete answer to what the layer owns.
In the dbt Semantic Layer, a metric definition requires a name and a type, where the type is one of conversion, cumulative, derived, ratio or simple, and optionally takes a description, a display label, configuration and a filter, which the documentation describes as your WHERE clause. Joins are not written by hand. The join logic documentation explains that joins "use entities defined in your semantic model configs as the join keys between tables", and that MetricFlow "creates a graph using the semantic models as nodes and the join paths as edges to perform joins automatically". It also refuses certain combinations outright: a primary to foreign or foreign to foreign join is rejected as a fan out rather than silently returning inflated numbers.
Looker takes the same idea through a modeling language. The Google Cloud introduction to LookML says LookML "is the language that is used in Looker to create semantic data models", that you use it "to describe dimensions, aggregates, calculations, and data relationships in your SQL database", and that "Looker uses a model that is written in LookML to construct SQL queries against a particular database". Model files hold which tables a project uses and how they should be joined.
Read those two together and the boundary in the source article stops being abstract. Both products define measures, dimensions and approved join paths, and both compile them into SQL. Neither defines what a Customer is outside the context of a query, neither resolves the same customer across two systems, and neither can express that an account manager may approve a retention offer up to a certain value. Those are the questions the other layer answers.
The source article warns that two layers do not automatically produce twice the clarity, and that they can instead create two definitions of Customer, two representations of product hierarchy, and two teams each claiming to own business meaning. Its division of responsibility is five rules: the ontology owns stable domain concepts, identifiers, relationships and operational capabilities; the semantic layer owns analytical measures, dimensions, grains, aggregation behavior and query time policies; shared concepts have mapped identifiers and coordinated lifecycle rules; definitions are authored once where possible and referenced elsewhere; and changes are tested against both analytical and operational consumers.
Those rules are right, and they are also the point at which most teams stop, because a rule is not yet a contract. The table below is the contract. Read the fourth column as the thing you have to keep synchronized and the fifth as the failure you get if you do not, which is what tells you how much effort the fourth column is worth.
| Concept | The ontology owns | The semantic layer owns | Where they must agree | What breaks when they disagree |
|---|---|---|---|---|
| Customer identity | The entity type, its identifier, and the resolution rules that decide when two records are the same company. | The customer dimension used to slice measures, and the grain at which it is safe to do so. | The identifier. The dimension key must be the resolved entity identifier, not a source system key. | An agent retrieves the right relationships for the wrong customer, or a metric is reported twice for a company that appears under two identifiers. Neither error raises anything. |
| Revenue | The financial concept and its relationships to invoices, contracts and subscriptions. | The calculation: recognized against invoiced against collected, currency and rate date, refunds, and the reporting period. | Which invoices and contracts belong to which customer, and over what period they are valid. | The number is defensible and the explanation of it is not, so an agent that reports a correct figure attributes it to the wrong contract. |
| Product hierarchy | The entity types for product, family and platform, and the relationships between them. | The rollup dimension used for reporting and the levels that are safe to aggregate over. | The levels themselves and their lifecycle: a product retired in one place is retired in both. | Reporting rolls a retired product into a live family while the operational model still treats it as separate, so the two sides disagree about the total and both are internally consistent. |
| Relationships and joins | Declared relationships between entities, with cardinality. | Approved analytical join paths and the grain each one produces. | That an approved join path does not contradict a declared cardinality. | Fan out. The analytical path multiplies rows the model says are one to many, and the metric is inflated in a way that looks plausible. |
| Time and validity | When a fact was true, and where it came from. | Which date determines the reporting period. | The event date and the validity window have to be the same date. | A restatement changes history in one layer and not the other, so last quarter's reported figure can no longer be reproduced. |
| Access and permission | Who may see which entity, and who may act on it. | Row level and column level access applied at query time. | The subject of the policy. Both must resolve the same person to the same role. | A user is blocked from a metric but can read the underlying objects through the ontology, or the reverse. Either way the control that was signed off is not the control in force. |
| Permissible actions | Which actions exist, what they change, and the constraints on who may perform them. | Nothing. This is outside the semantic layer entirely. | That the metric which triggers an action and the action itself refer to the same object. | An automated intervention fires against an object the metric was never about, which is the failure mode with the shortest path to a real world consequence. |
| Change management | Concept, relationship and constraint changes. | Metric, dimension and grain changes. | The release process. A change on either side is tested against consumers on both sides before it ships. | A silent break somewhere downstream that nobody attributes to the change for weeks, because the team that made it tested only its own consumers. |
One rule makes the whole table cheaper to maintain: author each definition once and reference it everywhere else. Where a concept genuinely has to exist on both sides, one side is the author and the other holds a reference, never a copy. A copy is a fork with a delay built into it.
A semantic layer on its own is the right answer more often than the discussion around it suggests. It is enough when most consumption happens through dashboards, reports, notebooks or analytical agents; when the disagreements you have are primarily about metric definitions; when the relationships that matter already fit a stable dimensional model; when users need governed dimensions and measures rather than domain reasoning; when workflows are read heavy and nothing acts against an operational object; and when your business domains are limited enough that entity identity is manageable inside the data models you already have.
The clearest case is a company trying to standardize revenue, gross margin, retention and conversion rates across its reporting. That company should not start by constructing an enterprise ontology. Its immediate problem is executable metric governance, and a semantic layer addresses it directly.
An ontology earns its place when the work depends on understanding and navigating a connected business domain rather than measuring one. That usually shows up when several systems represent the same real world entities differently; when relationships are as important as the attributes of individual records; when applications or agents have to reason across business domains; when users need to explore objects rather than predefined analytical dimensions; when lineage, provenance, temporal truth or entity resolution have to be explicit; when the system must represent permissible actions and operational constraints; and when AI needs grounded context beyond table schemas and metric descriptions.
The late delivery example in the source article separates the two cleanly. Calculating the percentage of deliveries that were late is a semantic layer problem. Working out which orders are affected, which suppliers and routes they depend on, which customers will be hit and which mitigations are permitted is an ontology problem. As the article puts it, the first produces a trusted measure and the second builds a navigable situation.
You need both when an analytical answer turns into an operational decision. Take a request to find enterprise customers whose renewal risk rose this month, explain the likely causes and recommend an intervention. The semantic layer supplies the governed renewal risk measure, its current and prior values, the customer and time dimensions, the approved revenue and usage metrics, and the row level access controls. The ontology supplies the identity of each customer and its corporate relationships, the active contracts and subscriptions, the linked support cases and incidents, the account ownership, the eligible interventions and the constraints on who may perform each one.
Remove either side and the failure is quiet rather than loud. Without the semantic layer an agent reasons correctly over well connected objects while using the wrong definition of renewal risk. Without the ontology it calculates the risk correctly and lacks the context to understand the cause or to act safely. The division the source article draws is the one to remember:
The semantic layer makes the signal trustworthy. The ontology makes the situation understandable.
If Question 1 produced no failure you could name, the honest answer is that neither layer is your next purchase. Both are governance investments, and a governance investment applied to a problem you cannot describe becomes another system to maintain. The work that pays first is unglamorous: agree the definitions of your core metrics in writing, fix the data models underneath them, and find out which of your sources disagree about the same entity. Do that and you will have answered Questions 1 and 3 properly, which is the only way the rest of the test produces a useful result.
This applies with particular force when the reason both layers are on the table is that an AI project needs to be seen to be underway. AI agents do strengthen the case for explicit semantics, but they do not by themselves justify an enterprise modeling program, and a knowledge graph full of beautifully connected concepts will not settle an argument about the correct formula for annual recurring revenue.
These two are confused more often than the ontology and the semantic layer are, and the distinction is simple once you have seen it. The ontology is the schema. The knowledge graph is the data that fills it in.
The W3C definition makes the schema side explicit: an OWL 2 ontology provides "classes, properties, individuals, and data values". Classes and properties are the model. The Microsoft Fabric documentation describes the populated side just as plainly, saying that the ontology graph is "a queryable instance graph built from your data bindings and relationship definitions" in which "nodes are entity instances, and edges are links". The model is authored; the graph is produced by binding it to data and refreshing it.
| Question | Ontology | Knowledge graph |
|---|---|---|
| What it is | The formal model: entity types, properties, relationships and constraints. | The populated instance graph produced by binding that model to real data. |
| What it contains | Definitions and rules. It is authored by people and it changes rarely. | Instances and links. It changes whenever the underlying data changes. |
| What you do with it | Validate, constrain and reason. It says which structures are legal. | Traverse, search and run graph algorithms such as paths and centrality. |
| Can it exist without the other? | Yes. An ontology with no data bound to it is still a valid model, and often the first thing a team builds. | In practice no. A graph with no ontology behind it has no agreed meaning for its node and edge types, which is how graphs turn into a second unmanaged data store. |
This is also why a knowledge graph is not a substitute for a semantic layer. It answers a different kind of question, and the source article is blunt about it:
Similarly, a knowledge graph containing thousands of beautifully connected concepts will not resolve disagreements about the correct formula for annual recurring revenue.
The integration is not theoretical and it does not require you to choose which box sits on top. Some organizations bind ontology entities to curated warehouse models and expose analytical measures through a separate semantic layer; others make governed semantic models available as sources for the ontology. Microsoft documents the second direction in unusual detail, and it is worth reading because it shows what the handover actually involves.
Microsoft's documentation on generating an ontology from a semantic model says the generation automatically creates entity types "that match the tables in your semantic model", static properties "based on the columns in your tables" together with the data bindings that link data rows to them, and relationship types "between entity types that follow relationships defined in the semantic model". So a well built dimensional model gives you a first draft of an ontology at no modeling cost.
The same page is equally clear about what the draft is missing, and the gaps are the more useful half of the lesson. After generating, you still have to bind time series data by hand because those properties are not created automatically, review the entity type keys and add any that are missing, particularly for multi key entities, and bind the relationship types to data yourself. Binding support also depends on the mode the semantic model runs in: entity, property and relationship definitions generate in Import, Direct Lake and DirectQuery modes, but data bindings generate only in Direct Lake, and even then only under specific conditions.
Read that list again and you have a precise statement of what a semantic layer does not carry. Keys, identity, relationships to real data and time validity are exactly the four things you have to add by hand, and they are exactly the four things Question 3 of the test asks about. The two layers connect cleanly; the connection just does not fill in the parts that were never there.
Running two layers means two places where business meaning is defined, and the second one is free to drift. The concepts that drift first are the ones that appear on both sides: customer, product, account, contract. Nothing raises an error when they diverge, because each side is internally consistent. You find out from a number that cannot be reproduced, or from an automated action taken against the wrong object.
The controls that catch this are not new and are not specific to ontologies. A business glossary gives each concept one authored definition with an owner. Column level lineage across systems is what lets you trace which downstream consumers a definition change reaches, so the source article's rule about testing changes against both analytical and operational consumers becomes something you can actually check rather than something you promise. Data contracts between producers and consumers, enforced by tests, are what stop a schema change on one side arriving as a surprise on the other. Policy driven tagging and classification keeps the access rules attached to the concept rather than to each copy of it.
Those controls are what Decube is built to hold, and each one has a home in the platform. The data catalog indexes the sources so there is one inventory rather than one per team. The business glossary is where a concept gets its authored definition, its owner and its custom attributes, which is the artifact both layers should be pointing at. Column level lineage across systems, with a structured approval flow so a lineage change is reviewed rather than silently applied, is what turns the rule about testing a change against both analytical and operational consumers into something you can check. Data contracts between producers and consumers, enforced by SQL based tests, stop a schema change on one side arriving as a surprise on the other. And data governance is where the access rules live, with automatic classification of personal data, role based access and approval workflows attached to the concept rather than to each copy of it.
TrustyAI sits over that metadata as a governed natural language interface for semantic discovery, lineage analysis, operational health and profile summarization, so the questions people ask about a definition are answered from governed metadata rather than from whoever remembers. If you are about to run two layers and want to see how the boundary is held in practice, book a walkthrough.
Run the four questions against the failure you have this month, not the architecture you want next year. If your dashboards disagree, govern the calculations. If your systems cannot agree on what their records represent or how they relate, model the domain. If agents have to move from questions to decisions that cross domains, connect the two and write the ownership contract before either team starts building. And if you could not name a failure at all, the most valuable thing you can do this quarter is fix the data models and the metric definitions you already have.
The framing worth keeping, from the article this one builds on, is that there are two kinds of truth at stake and each layer protects one of them. One is computational: the same rules should produce the same answer every time the company asks for a metric. The other is contextual: when the company refers to a customer, an order, an asset or an incident, its systems should understand what that thing is and how it relates to everything else. A semantic layer protects computational truth. An ontology protects contextual truth. You need both when your systems must do more than calculate the world, and must understand enough of it to make a decision.
A semantic layer governs how the business measures the world, and an ontology describes the world being measured. In practice the semantic layer holds metric definitions, dimensions, approved join paths and query time access rules, so that a number means the same thing everywhere it is consumed. An ontology holds entity types, their properties, the relationships between them, the constraints that keep those relationships valid, and in operational implementations the actions that may be performed against them. The semantic layer produces a trusted number; the ontology produces a navigable picture of the situation that number came from.
A data ontology is a formal, machine readable model of the things a business deals with, bound to the data where those things actually live. Microsoft describes an ontology as a shared vocabulary of your business made up of the things in your environment, represented as entity types, their facts, represented as properties, and the ways they connect, represented as relationships, together with constraints and rules that keep representations consistent. The binding step is what makes it a data ontology rather than a diagram: it connects entity types, properties and relationships to concrete sources such as warehouse tables, event streams and analytical models, and it records data types, identity keys and how columns map to properties.
No. The ontology is the schema and the knowledge graph is the populated instance graph built from it. An OWL 2 ontology provides classes, properties, individuals and data values; the graph produced by binding that model to real data has entity instances as nodes and links as edges. The ontology is authored by people and changes rarely. The graph changes whenever the underlying data changes. An ontology can exist with no data bound to it and still be useful; a graph with no ontology behind it has no agreed meaning for its node and edge types.
Some organizations need only one. Many will need both once analytics, operational applications and AI agents share the same business context. The test is what is failing. If people disagree about how a metric is calculated, you need a semantic layer. If systems disagree about what their records represent, you need an ontology. If an analytical answer has to trigger an operational action, you need both, with a written boundary between them, because an agent without the semantic layer will reason well over the wrong definition and an agent without the ontology will calculate correctly and lack the context to act safely.
No, because it is built to answer a different question. A dbt metric definition requires a name and a type, where the type is conversion, cumulative, derived, ratio or simple, and optionally takes a description, a label, configuration and a filter. Joins are resolved automatically from the entities declared in the semantic models, with MetricFlow building a graph of semantic models and join paths and refusing combinations that would fan out. That governs calculation very well. It does not define what a customer is outside the context of a query, resolve the same customer across two systems, or express which actions a person is permitted to take.
Yes, and a well built dimensional model makes the second step cheaper. Microsoft documents generating a Fabric ontology directly from a Power BI semantic model: entity types are created to match the tables, static properties from the columns along with data bindings, and relationship types following the relationships already defined in the model. What does not come across is instructive. You still have to bind time series data manually, review the entity type keys and add missing ones, and bind the relationship types to data yourself. Identity, time validity and relationships to real data are the parts a semantic layer never held.
They usually refer to the same artifact seen from two directions. Business ontology emphasizes the agreed vocabulary of the domain, the concepts and their relationships as the business understands them. Data ontology emphasizes that the model is bound to real data and can be queried. A model that is agreed but never bound stays a glossary, and a model that is bound but never agreed with the business becomes a second data store with no authority. The useful version is both: authored with the domain owners, then bound to the sources.
In data management an ontology is the layer that fixes what things are, as distinct from the layers that catalog where data sits or govern how it is calculated. It sits above individual tables, so a definition of Customer no longer depends on whichever system is currently treated as authoritative, and it makes relationships, provenance and temporal validity explicit rather than implied by a join someone wrote. Its practical value in a governance program is that it gives entity identity a single owner, which is the prerequisite for reconciling systems that describe the same real world things differently.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)