Skip to main content
Loading Explore guides…
Ontologies vs Semantic Layers · Acedra
Home
Explore
Computer Science
Ontologies vs Semantic Layers
Sign in to save
Chat
If YouTube asks you to sign in, open the video on YouTube.
Watch on YouTube
Reload player
Transcript
47 segments
Copy
Hide video
0:00
Ask a data team what revenue means, and you'll get three answers before launch. Finances gap, recognize revenue. Sales says booked. A RR product says usage-based billing tools. Each is correct within its own context. And that's exactly the problem. Enterprises have been trying to establish shared meaning across their data for decades. Two approaches keep surfacing ontologies and semantic layers both claim to solve the what does this mean problem, but they solve different versions of
0:33
that question and confusing the two leads to governance architectures that are expensive, incomplete, or both. And ontology defines what things are and how they relate. A semantic layer defines how things are measured and calculated. One gives you structure, the other gives you numbers. Your enterprise needs both, and it needs to know which one to reach for when. By the end of this guide, you'll have a precise understanding of
1:00
each approach, a clear framework for when to use one versus the other, and a practical picture of how they converge inside a modern data platform. Most explanations of this topic stay abstract ontology theory on one side, semantic layer tooling on the other in no bridge between them. The practitioners who get this right are the ones who understand where the boundary falls in their own stat, which problems are structural, which are computational, and which need a layer that connects both.
1:29
That's the ground we're covering here. Every enterprise data team inherits the same challenge. There are hundreds of thousands of tables, columns, and hundreds of dashboards and somewhere buried across all of them are the concepts the business actually cares about customer revenue, churn utilization.
1:49
These words appear everywhere in Slack, conversations, in board decks, in SQL queries, in DBT model descriptions. And in almost every organization they mean slightly different things depending on who is using them and where. Now this isn't a new problem. Data dictionaries in the 1990s tried to solve it. Enterprise data models in the two thousands tried to solve it. Master data management initiatives, tried to solve it bi semantic layers.
2:16
The old kind think Cognos or Business Object cubes tried to solve it. Each generation made partial progress and left partial gaps. What's different now is two things. First, the modern data stack has fragmented this problem across more tools than ever. Definitions live in DBT YAML files and Looker ML explorers and Tableau calculated fields and wiki pages in people's heads. Second, AI is now a data consumer, not just a tool, but something that
2:48
needs to understand business context to give accurate answers, and that is what has raised the stakes. When an LLM generates a query against your data warehouse, it needs to know what customer means, not approximately. Precisely two frameworks have emerged as the most credible approaches to closing this gap. Ontologies, which define the structure of meaning and semantic layers, which define the logic of measurement. They're often discussed as if they are competing approaches or if
3:19
one makes the other unnecessary. Neither is true.
3:23
They operate at different levels of abstraction, serve different audiences, and govern different kinds of change. Understanding that distinction is what turns a data governance strategy from a documentation exercise into something that actually works. And ontology in the data world is a formal specification of what kinds of things exist in a domain and how they relate to one another. That sounds academic, and historically it has been.
3:51
Ontology has come from philosophy by way of the semantic web and AI research, but the core idea is practical. Think about how a data architect designs a conceptual model before deciding on table structures or column types. They map out entities, customer account, product order transaction. They then define the relationships A customer has one or more accounts. An account belongs to one legal entity. An order contains one or more line items.
4:19
Each referencing a product, that conceptual model, the entities, their properties, and the relationships between them is an ontology. It defines the possibility space of a domain, what can exist, and how things can relate. Now, the word ontology carries baggage. Many practitioners hear it and picture owl files, protege editors, and two year modeling projects that produce elegant diagrams. In zero adoption, that reputation is earned.
4:50
Some enterprise ontology initiatives have been exactly that, but the reality is actually a spectrum. At one end, there's a flat glossary, a list of terms with definitions like customer, an entity that has purchased at least one product that's useful, but it captures no structure. It doesn't tell us how customer relates to account or what subtypes of customer exists. Move along the spectrum and we get a hierarchal glossary where terms can have parent-child relationships.
5:20
Customer is a type of party retail customer, and wholesale customers are types of customer. Further still, we reach concept models in lightweight ontologies that capture typed relationships, not just hierarchy, but association. A customer can have a lifetime value. A product belongs to a product category. A product category maps to a revenue stream at the far end sits the formal ontology expressed in language like OWL or RDF Schema, machine readable, capable of supporting inference.
5:53
Healthcare has snomed CT and FHIR ontologies that let systems reason about the relationships between diagnoses, procedures and patient encounters. Financial service has fibo, which maps the relationship between financial instruments, parties, and legal entities. These are powerful. They're also expensive to build and maintain. Here's the practical takeaway. Most enterprise data teams don't need a formal ontology. They need something in the middle of the spectrum structured enough
6:23
to capture how concepts relate. Light enough to actually maintain that might look like a well organized business glossary with hierarchical terms and explicit relationships. The key though, is moving beyond a flat list of definitions toward a connected model of meaning. Building on that foundation of what ontologies define, and at ease properties relationships. We can now look at what the semantic layer handles and it handles something fundamentally different.
6:53
A semantic layer is an abstraction between raw data and the people or systems consuming it. Its job is to define metrics and dimensions, the measurements and groupings a business uses to make decisions in a way that is consistent regardless of which tool or query is asking. When we say revenue in a semantic layer, we are not defining what revenue is as a concept. We are defining how it's calculated. Revenue equals the sum of completed order amounts, excluding tax converted into
7:23
the reporting entities, uh, currency. That formula, along with its dimensions, time period, product line, geographic region, is what this semantic layer governs. This is worth pausing on because there is a common misconception that semantic layers are just views or bi models by another name. The modern semantic layer is something actually more specific. It is declarative version controlled EPI, accessible definition layer. Declarative means the definitions describe what to compute.
7:53
Not how to execute it. The engine handles optimization. Version control means metric changes, go through poll requests, code reviews, and deployment pipelines. Just like data transformations, API accessible means any consumer, not just the BI tool it was built for, can query the metric and get a consistent answer. Tools like DBTs Metric, layer through metric flow lookers Look ML at scale in Cube each implement this pattern differently, but the core promise is the same.
8:24
Define the metric once, use it everywhere, and never argue about which Tableau Dashboard has the right revenue number again.
8:32
That's a significant problem to solve. And for metric consistency, the semantic layer is the right tool. But notice what it doesn't cover. It doesn't tell us what types of revenue exist and how they relate. It doesn't explain that recognized revenue booked a RR and build revenue are subtypes of a broader revenue concept with different accounting treatments. It doesn't map the relationship between revenue and the entities that generate it. Customers, contracts and products.
9:02
That structural knowledge lives in the ontology layer. The semantic layer assumes you already know what you want to measure. The ontology helps you understand the domain well enough to know what's worth measuring. Now that we've established what each approach does independently, we can lay them side by side and get specific about the boundaries. We'll start with what each defines. On the ontology side we're defining entities, properties and relationships.
9:31
The nouns and verbs of the domain customer account product belongs to is a type of on the semantic side, we're defining metrics, dimensions, and calculation logic. The measurements and aggregation revenue. Monthly active users churn rate some of x, where Y group by Z. Next, the questions, each answers the ontology answers. What is X and how does it relate to Y? What is a customer? How does a customer relate to an account? What subtypes of customers exist?
10:03
The semantic layer answers, how do we measure X? How do we calculate monthly active customers? What is the formula for customer acquisition cost? What dimensions can we slice those metrics by? Now who typically owns each is revealing ontology. Definitions tend to be governed by data architects, data governance teams or domain stewards, people who think about the conceptual structure of the business. Semantic layer definitions.
10:31
Tend to be governed by analytics engineers and BI teams, people who think about how metrics get computed and consumed. These are often different people with different skill sets, different tools in different change management processes. And that brings us to what might be the most practical distinction, how change propagates. Now, when an ontology definition changes, say the business decides that customer now includes free tier users, not just paying accounts. The impact is structural and broad.
11:02
Every metric that references customer is potentially affected. Every dashboard, every ML model, every report that counts or segments customers needs to be reviewed. That change is high stakes and needs a deliberate governance process.
11:19
When a semantic layer metric changes, say the revenue calculation is updated to exclude refunds processed within 30 days, the impact is specific and traceable. We can identify exactly which dashboards and reports consume that metric and assess the impact through lineage that change is meaningful, but bounded. Let's make this concrete with the revenue example from the opening. A SaaS company has three revenue concepts, gap recognized revenue booked a RR, and build revenue.
11:49
The ontology layer defines these as subtypes of revenue, each with distinct properties. Recognized revenue has an accounting period and recognition schedule booked. A RR has a contract term and renewal date. Build revenue has an invoice date and payment status. The ontology captures that. These are related. Distinct concepts. The semantic layer then provides the calculation for each recognized revenue equals the sum of recognized amounts for the reporting period.
12:18
According to the A SC 6 0 6 rules book, a RR equals the annualized contract value of active subscriptions and build revenue equals invoiced amounts in that period. Each formula is precise. Version controlled and produces a specific number. Without the ontology, though, the semantic layer picks one definition of revenue and hides the others or worse. Different teams build their own metrics and label them all revenue without the semantic layer.
12:48
The ontology tells us that there are three types of revenue, but gives us no consistent way to calculate that. The structure without the logic is a taxonomy exercise. The logic without the structure is a recipe for metric sprawl. With that framework established, we can move into situations where practitioners actually make these decisions. The pattern becomes clear. Some problems are ontology first. Some are semantic layer first, and some require both.
13:16
From the start, consider a healthcare network that has acquired three regional hospital systems. Each system has its own definition of patient encounter. One counts emergency room visits, one counts only admitted patients. The third includes telehealth sessions. Before anyone can build a dashboard that shows average encounter duration across the network, a more fundamental question needs to be answered. What is an encounter in this organization that's an ontology problem?
13:46
The team needs to define encounter as a concept with subtypes, emergency visit and inpatient admission. Telehealth sessions and specify the properties and boundaries for each. Healthcare has mature ontologies like snomed, CT and FHIR that provide a starting framework, which illustrates an important practical point. Industry standard ontologies exist for many domains and they can accelerate alignment significantly.
14:13
Once the ontology structure is agreed upon, the semantic layer can define the specific calculations. Average duration by encounter type, encounter volume by facility. Readmission rates per encounter category. Now contrast that with an e-commerce company that operates in one market with a clear product model and a well understood set of entities. Their problem is simpler. The marketing team and the finance team calculate conversion rate differently. Marketing counts.
14:40
Any session that leads to a cart edition, finance counts only completed purchases divided by unique visitors. The entities are not in dispute. Everyone agrees on what a session a visitor and a purchase are. The measurement logic is the conflict. Now, that's a semantic layer first problem, a unified metric definition with clearly labeled variance. If the business needs both, resolves it without any ontology work. Then there's the case that requires both, and increasingly it's the most common one.
15:13
A financial services firm reports to multiple regulators, the Fed, the OCC, the CFPB, each requiring slightly different definitions of concepts like exposure, counterparty, and.
15:27
Internally, the analytics team has built a looker segment layer for risk dashboards, regulators don't just want metrics, they want definitions. Traceable to regulatory ontologies like fibo, the financial industry business ontology. The semantic layer handles internal metrics, consistency. The ontology aligns entity definitions with external standards, and the critical need is a layer that connects the both. When a regulator asks. How do you define counterparty exposure?
15:59
The answer has to trace from the regulatory definition through the ontology structure to a specific metric calculation to the data assets that feed it. The full chain needs to be visible all in one place. Now one more scenario, and it's the one that's really reshaping this entire conversation. AI when an organization deploys an LLM to answer questions about its data, what was our customer retention rate in Q3? The model needs more than a metric formula.
16:29
It needs to understand what a customer is, what retention means in this business's context, how customers relate to accounts and subscriptions, and which data assets contain the relevant information that's ontological knowledge. The semantic layer provides the calculation once the LM knows what to calculate. But the broader contextual understanding, the kind that prevents hallucinated business logic comes from structured meaning at the ontological level.
16:57
Everything we've covered points to a practical question, where does all this live? The ontological definitions in one system, the semantic layer formulas in another, the actual data assets in a third, and no connection between them. That's the state most organizations are in, and it's why the meaning problem persists despite all these tools. This is where the concept of a context layer becomes relevant. A context layer is not an ontology tool. It is not a semantic layer.
17:26
It is the platform where both become discoverable linked to the data assets they describe and governed through consistent policies. In practice, this means a platform that does several things simultaneously. It provides a business glossary with enough structural capability to capture not just definitions, but relationships between terms. That's a lightweight ontology layer. It integrates with source tools, DBT, Looker, Tableau, presenting their physical
17:53
assets and automating linkings to the glossary and maps lineage from raw data through transformations to consumption, showing how meaning flows through the stack, not just what the metric is. But where its inputs come from and what depends on its outputs, and it applies governance, classification, access policy ownership consistently across both ontological definitions and semantic layer metrics. Now, the practical framework for getting started matters as much as
18:24
the architecture and the most common failure modes point directly to the right sequence failure mode one, starting with a full formal ontology. Organizations spend 18 months modeling every entity in relationship in the domain, producing an artifact that is comprehensive, technically correct, and disconnected from any tool anyone actually uses. By the time it's done, the data landscape has shifted. You need to start lighter.
18:52
A well-structured glossary with hierarchal terms and clear ownership connected to actual data assets delivers 80% of the ontological value at 20% of the effort formalized further only where regulatory or AI requirements actually demand it.
19:09
Now failure mode two. Deploying a semantic layer without ontological clarity. The team defines 200 metrics in DBT, but without agreement on what the underlying entities mean. Different metrics use different entity definitions implicitly customer count in one metric includes free tier users in another only paying accounts. The semantic layer faithfully calculates both. The numbers disagree. Define our core entities first, even if it's just 10 terms in a glossary
19:39
with clear boundaries before defining the metrics that reference them. Now, failure mode three. Building either in isolation from where practitioners actually work. Definitions that live in a wiki die there. Metrics defined in code, but invisible to business users. Only serve the engineering team. The context layer is what makes both investments usable. It's the place where a data analyst can search for revenue. Find the glossary definition, see the metric formula, trace the
20:09
lineage, and check who owns it all without leaving the platform. The sequence then is start with a glossary that captures our core entities in their relationships. Inside the context layer, connect our semantic layer tools, so metric definitions, surface alongside those entities. Let lineage show how meaning flows from definition to data, to dashboard and govern the whole thing, not with the same process for every change, but with governance proportional to impact.
20:41
Ontological changes get broader, review metric changes, get targeted impact analysis. The context layer makes both kinds of governance possible because it knows what connects to what we've covered what ologies and semantic layers each do, where the boundary falls between them, and how a context layer connects both into something practitioners actually use. The next question most teams face is where to start, and specifically, how to structure a business glossary that captures
21:11
enough ontological richness without becoming a two year modeling project. We'll cover exactly that in an upcoming guide on building a business glossary. That works.
Here to help you learn
Sign in to keep a private conversation with your course tutor.
Ask me anything about the material…
Sign in to chat