The Semantic Layer vs. The Ontology Layer

The Semantic Layer Moment

The data industry is having a semantic layer moment. Databricks acquired AtScale. dbt introduced its metrics layer (now the semantic layer in dbt Cloud). Looker has been doing LookML-based semantic modeling for years. Google's acquisition of Looker and subsequent integration with BigQuery brought semantic modeling into the mainstream cloud data stack.

The pitch is compelling: define your business metrics once, in a shared layer, and every tool — BI dashboards, notebooks, reverse ETL pipelines, LLM-powered analytics — uses the same definitions. No more three departments with three different definitions of "revenue." No more analysts rewriting the same SQL join logic in every query. One source of truth for business logic.

This is genuinely valuable, and these tools solve a real problem well. But the term "semantic" can be misleading when it comes to enterprise architecture, because a semantic layer is not an ontology. The words sound similar. The architectures are quite different, and it is worth understanding why.

What the Semantic Layer Actually Does

A semantic layer is a translation layer between business concepts and database queries. It defines mappings: "revenue" maps to SUM(line_items.amount) WHERE status = 'completed'. "Active customer" maps to customers WHERE last_order_date > CURRENT_DATE - INTERVAL 90 DAY. "Churn rate" maps to a more complex expression involving cohort analysis and time windows.

These definitions are valuable because they centralize business logic that was previously scattered across dozens of SQL queries, dbt models, dashboard filters, and Python notebooks. The semantic layer acts as a shared vocabulary: when someone says "revenue," everyone agrees on what computation produces that number.

The major implementations — dbt's semantic layer, Databricks Unity Catalog's metrics, AtScale's virtual OLAP, Looker's LookML — all work roughly the same way. You define entities (which map to tables or views), dimensions (columns you group by), measures (aggregations you compute), and relationships (joins between entities). A query against the semantic layer is compiled into SQL and executed against the warehouse.

A Concrete Example

In dbt's semantic layer, you might define a metric like this (simplified):

metrics:
  - name: monthly_revenue
    type: sum
    sql: amount
    timestamp: completed_at
    time_grains: [day, week, month]
    filters:
      - field: status
        operator: "="
        value: "'completed'"
    dimensions:
      - region
      - product_category

This is clean. It tells you exactly how monthly revenue is calculated. Any downstream consumer — a Hex notebook, a Tableau dashboard, an AI agent — can query monthly_revenue by region and get a consistent answer. The semantic layer compiles this into a SQL query against your warehouse and returns the result.

What it does not tell you: what "revenue" is. Where it comes from. What business processes produce it. What constraints govern it. What happens when it needs to be adjusted, reversed, or audited. For that, you need something else entirely.

What an Ontology Does Differently

An ontology defines the concepts in a domain and the formal relationships between them. Not as metric definitions — as a world model. In an ontology, "revenue" is not a SQL expression. It is a concept with a formal definition:

• Revenue is a MonetaryMeasure derived from Invoices.
• An Invoice references a Contract and contains one or more LineItems.
• A LineItem fulfills a SalesOrder, which originates from a Customer.
• Revenue recognition follows rules defined by AccountingStandard (IFRS 15, ASC 606), which specify when revenue is recognized — at point of delivery, over time, or upon milestone completion.
• A CreditNote adjusts an Invoice, reducing recognized Revenue. A Refund reverses a LineItem, which reverses the associated Revenue.

This is not a metric definition. It is a structural model of the business domain that captures entities, relationships, constraints, and rules. The ontology does not just tell you how to compute revenue — it tells you what revenue means, where it comes from, what can modify it, and what rules govern those modifications.

Metrics Dictionary vs. World Model

The distinction becomes clear when you consider what each layer can and cannot do.

The semantic layer can answer: "What was revenue last quarter, by region?" The ontology can answer: "Which contracts contributed to revenue last quarter, what were their original terms, which invoices were issued, which have been paid, which are disputed, and are we recognizing revenue in compliance with IFRS 15 given the delivery milestones specified in each contract?"

The semantic layer can enforce: "Revenue is calculated as SUM(amount) with these filters." The ontology can enforce: "A refund must reference an original transaction. A credit note cannot exceed the value of the invoice it adjusts. Revenue cannot be recognized before the performance obligation is satisfied."

The semantic layer is a metrics dictionary. The ontology is a world model. Both are useful. They are not the same thing, and calling them both "semantic" creates confusion that leads to architectural mistakes.

Where They Live in the Stack

The semantic layer lives above the data warehouse. It is a query translation layer. Data flows up from source systems into the warehouse (via Fivetran, Airbyte, custom ETL), is transformed (via dbt, Spark, SQL), and the semantic layer provides a consistent interface for consumption. It is, fundamentally, a read-path technology.

An ontology lives above the entire operational stack — not just the warehouse, but the ERP, the CRM, the MES, the LIMS, the supply chain platform. It models entities that exist across systems and enforces constraints that span system boundaries. When an ontology says that a PurchaseOrder must have an approved Supplier, it is enforcing this rule in the procurement system, not in a warehouse query.

The semantic layer is consumed by analysts and BI tools. The ontology is consumed by operational systems, workflow engines, and AI agents that take actions in the real world. The semantic layer helps you understand your business. The ontology helps you run it.

The Refund Test

Here is a concrete test to illustrate the difference. Consider refund handling.

Can your "semantic layer" enforce that a refund must reference an original transaction? Not as a BI filter — as a structural constraint. Can it prevent the creation of a refund that does not correspond to a real sale? Can it ensure that the refund amount does not exceed the original transaction amount? Can it automatically adjust the revenue metric when a refund is processed, not by re-running a query, but by understanding the causal chain from refund to line item to invoice to revenue?

Current semantic layer products are not designed to do this, and that is fine -- it is not what they are for. But it does highlight the gap. These tools know the syntax of your metrics (how to compute them) but not their semantics in the formal sense (what they mean, what governs them, what can change them). They are metrics layers, and very good ones. The "semantic" branding can just create confusion about what they actually provide.

Complementary, Not Competing

Semantic layers solve a real problem -- metric consistency across an analytics stack -- and they solve it well. dbt's implementation is elegant. LookML is battle-tested. Unity Catalog's integration of governance with metrics is thoughtful engineering.

Our argument is that for operational use cases, they are not sufficient on their own. An enterprise benefits from both layers:

• The semantic layer provides consistent metric definitions for analytics. It lives in the data platform. It serves the data team.
• The ontology layer provides a formal domain model for operations. It lives across the operational stack. It serves the entire organization — including the data team, but also operations, engineering, compliance, and AI systems.

The ontology can also inform the semantic layer. If the ontology defines what "revenue" is and what rules govern it, the semantic layer's metric definition can be derived from the ontology rather than hand-coded in YAML. This is the direction we are exploring with P3: the ontology defines the business concepts, and the analytics layer inherits those definitions. In theory, changing the ontology (say, adding a new revenue category) should propagate to the metric definitions. In practice, we are still working through the edge cases in that propagation.

Think of it this way: the ontology is the source of truth for what things are. The semantic layer is the source of truth for how things are counted. Both are necessary. Neither replaces the other.

Why This Matters Now

This distinction matters more now than it would have in 2020 because of how AI is being deployed. Large language models are increasingly used as interfaces to enterprise data. "Ask your data" products are proliferating. Every BI vendor has shipped or announced an LLM-powered natural language query feature.

When an LLM queries the semantic layer, it can compute metrics. "What was revenue in Q3?" works fine. But when an LLM needs to take action — "process this refund," "approve this purchase order," "rebalance this production schedule" — the semantic layer has nothing to offer. The LLM needs to understand entities, relationships, constraints, and workflows. It needs an ontology.

Without an ontology, the LLM is operating without a world model. It can query numbers but it cannot reason about the business processes that produce those numbers. It can tell you revenue dropped 12% last month but it cannot trace the cause to a supplier contract renegotiation that changed pricing on three product lines, which affected margin on orders from two customer segments, which in turn affected revenue recognition timing under ASC 606.

For analytics-focused use cases, the semantic layer is the right tool. For operational and agentic use cases -- where an AI needs to take actions, not just compute numbers -- you probably need both: the semantic layer for consistent metrics, and an ontology for the structural model that tells the AI what actions are valid and what constraints apply.