Semantic Layer vs Ontology: What's the Difference and Why It Matters for AI Agents

An AI agent is asked: "Which customer segments contributed most to revenue growth last quarter, and how do they relate to our product lines?" It identifies the net_revenue metric from the semantic layer, slices it by customer_segment, and returns a number. The SQL is flawless. The result is wrong — because the agent joined customers to contracts through a billing relationship instead of the ownership relationship, conflated physical products (SKUs in a warehouse) with SaaS products (plan tiers in a subscription table), and attributed revenue from multi-product contracts entirely to the first product on the invoice. The semantic layer ensured the metric was computed correctly. What was missing — and what caused every downstream error — was an ontology: a formal model of what kinds of things exist in this business domain and how they relate to each other. This article defines each concept, maps where they overlap and where they diverge, and explains why the distinction stops being academic the moment you deploy an AI agent against real enterprise data.

TL;DR

• A semantic layer translates physical schema into business-meaningful objects — measures, dimensions, metrics, join paths — so tools and agents can query data using business language.
• An ontology defines the categories, entities, properties, and rules of a domain — a formal model of what exists, independent of any specific database implementation.
• They are complementary, not competing: a semantic layer provides the executable mapping from business concepts to SQL; an ontology provides the conceptual framework that gives those concepts meaning and structure.
• For AI agents: a semantic layer grounds queries in correct data; an ontology grounds reasoning in correct relationships. An agent with only a semantic layer can answer "what was revenue last month?" correctly. An agent with both a semantic layer and an ontology can answer "which customer segments contributed most to revenue growth, and how do they relate to our product lines?" — because it understands the domain structure, not just the metric definitions.
• Datus's Context Engine operates primarily at the semantic layer level (schema → metrics → SQL) but its Subject Tree — organizing business domains into hierarchical topics with relationships — is an ontology-like structure that gives agents a conceptual map of the data landscape.

1. Semantic layer: a quick recap

A semantic layer is the business translation of physical data. It defines:

• Measures: what you can quantify — net_revenue, active_users, churn_rate.
• Dimensions: what you group or filter by — region, plan_tier, acquisition_channel.
• Relationships (joins): how tables connect — orders.customer_id → customers.id.
• Business rules: filters, calculations, grain constraints.

The semantic layer is implementation-aware. It knows that net_revenue lives in the fact_orders table, filtered by order_status = 'completed', aggregated as SUM(revenue_usd - refund_usd). It is a practical, executable mapping from business language to database operations.

For a thorough treatment, see what is a semantic layer.

2. Ontology: definition and role

An ontology, in the data and AI context, is a formal representation of the concepts, categories, properties, and relationships that constitute a domain — independent of any specific data system. It defines:

• Classes / types: what kinds of things exist — Customer, Product, Order, Contract, Subscription.
• Properties / attributes: what describes each thing — a Customer has a name, an industry, an annual_revenue; a Product has a sku, a price, a category.
• Relationships: how things connect — a Customer places an Order; an Order contains LineItems; a Customer has a Contract.
• Hierarchies: how things are organized — Enterprise Customer is a subclass of Customer; SaaS Product is a subclass of Product.
• Constraints / rules: what must be true — a Customer must have at least one Contract to place an Order; a Subscription cannot be active after its Contract end date.

An ontology is implementation-independent. It does not say where the data lives, which tables store it, or how to query it. It says what the domain contains and how the pieces fit together. It is a conceptual model — closer to philosophy than to SQL.

In practice, ontologies are often expressed as knowledge graphs, taxonomies, or formal specifications (OWL, RDF). But the most useful ontologies for data engineering are lighter-weight: a shared conceptual map that everyone — analysts, engineers, product managers, AI agents — agrees on.

3. The key differences

Dimension	Semantic layer	Ontology
Primary job	Map physical data to business concepts for query execution	Define the categories, relationships, and rules of a domain
Answers the question	"How do I query net revenue by region?"	"What is a Customer, and how does it relate to an Order?"
Database-aware?	Yes — knows tables, columns, join paths, SQL dialects	No — describes concepts, not storage implementation
Executable?	Yes — generates SQL, applies filters, resolves joins	No — provides conceptual grounding for reasoning, not execution
Primary consumers	BI tools, query engines, AI agents generating SQL	Knowledge graphs, reasoning engines, AI agents performing domain reasoning
Granularity	Table/column level — one semantic model per data source	Domain level — one ontology per business domain
Example artifact	MetricFlow YAML: metric: net_revenue { measure: net_revenue_amount }	Knowledge graph: Customer -[places]-> Order -[contains]-> LineItem

A practical way to understand the difference: if you change your database from Snowflake to BigQuery, your semantic layer needs to be re-mapped (different tables, different column names, different SQL dialect). Your ontology does not — a Customer placing an Order is true regardless of which warehouse stores the data. The semantic layer is the implementation layer; the ontology is the conceptual layer.

4. How they work together

Semantic layers and ontologies are complementary. Together, they give an AI agent both executable access (semantic layer) and domain understanding (ontology):

Agent task	What the semantic layer provides	What the ontology provides
"What was net revenue last month?"	Metric definition, SQL generation, filter application	— (simple metric query does not need domain reasoning)
"Which customer segments had the highest churn, and what product lines are they on?"	Churn metric definition, customer dimension, product line dimension	"Customer segment" is a property of Customer; "product line" is a property of Product; Customer relates to Subscription via Contract
"What factors correlate with enterprise customer churn?"	Churn metric, customer attributes (industry, size, contract value) as dimensions	Enterprise is a subclass of Customer with additional properties (contract value, dedicated support); churn factors include contract lifecycle events
"Build a Subagent for the marketing analytics domain."	Tables relevant to marketing: campaigns, leads, conversions, attribution	Marketing domain boundaries: what entities belong (Campaign, Lead, Channel) and what does not (Payroll, Inventory)

The ontology gives the agent scope awareness — knowing which concepts belong to which domain, how they relate, and what does not belong. The semantic layer gives the agent execution capability — knowing how to actually query the data for those concepts.

For data engineering agents specifically, ontologies help with:

• Domain scoping: when building a Subagent for "marketing analytics," the ontology defines which entities belong — campaigns, leads, channels, conversions — and which do not — payroll, inventory, facilities.
• Context traversal: when an agent needs to understand a query about "customer lifetime value," the ontology tells it that LTV connects concepts from Customer, Order, Subscription, and Contract — guiding context retrieval across domains.
• Ambiguity resolution: when a query references "product," the ontology determines whether the context is physical product (SKU, inventory, warehouse) or service product (plan tier, subscription, feature set) — routing the agent to the right domain.

5. Datus's Context Engine: the semantic-ontology bridge

Datus's Context Engine operates primarily at the semantic layer — generating semantic models from schema, metrics from SQL, capturing validated queries, and scoping Subagents. But its Subject Tree — organizing business domains into a hierarchy of topics — functions as a lightweight, practical ontology:

Subject Tree (ontology-like structure)
  ├── Finance
  │   ├── Revenue
  │   │   ├── Net Revenue (metric)
  │   │   └── Revenue by Product Line (metric)
  │   └── Costs
  ├── Product
  │   ├── User Engagement
  │   └── Feature Adoption
  └── Marketing
      ├── Campaign Performance
      └── Attribution

The Subject Tree is not a formal ontology (no class hierarchies, no property definitions, no inference rules), but it serves a similar function: it gives agents a conceptual map of the data landscape. When an agent receives a query about "campaign ROI," it traverses the Subject Tree to Marketing → Campaign Performance, retrieves the relevant semantic models and metrics, and generates a grounded response. The Subject Tree provides domain awareness; the semantic models provide execution capability.

This is a pragmatic middle ground: a full formal ontology (OWL, RDF, knowledge graph) is powerful but expensive to build and maintain. A Subject Tree is lighter-weight — defined through /gen_semantic_model and user curation — but gives agents enough conceptual structure to navigate domains, scope Subagents, and resolve ambiguity. For most data engineering teams, the gap between "no ontology at all" and "a practical Subject Tree" is far larger than the gap between "a Subject Tree" and "a formal ontology."

6. When you need to think about ontology

Most data teams do not need a formal ontology. The signals that you might:

• Multiple teams interpret the same concept differently. If Marketing's definition of "customer" differs from Finance's, and both differ from Product's — and these differences cause conflicting reports — you need shared domain definitions. An ontology formalizes what "customer" means and which properties it has, across teams.
• AI agents make reasoning errors across domains. If an agent confuses "product" (physical SKU) with "product" (SaaS plan tier) and generates wrong answers, an ontology can disambiguate these concepts before the agent queries data.
• You are building a large knowledge graph. If your organization already maintains a knowledge graph (Neo4j, Amazon Neptune, RDF stores), integrating it with your semantic layer gives agents both conceptual reasoning and executable data access.
• Regulatory or compliance requirements demand traceable concept definitions. If you need to prove that "revenue" means the same thing across all systems for audit purposes, an ontology provides the formal specification.

Signals you do not need a formal ontology (yet):

• You have one semantic layer, one BI tool, one analytics team, and consistent metric definitions.
• Your data estate is small enough that domain knowledge lives in people's heads and the occasional wiki page — and it stays consistent.
• You are not deploying AI agents that need to reason across domains.

7. The ontology layer and AI agents: the emerging architecture

As AI agents become more capable, the architecture is trending toward three layers:

┌──────────────────────────────────────────────┐
│            ONTOLOGY LAYER (Conceptual)         │
│  Classes · Properties · Relationships · Rules  │
│  "What kinds of things exist, and how?"        │
├──────────────────────────────────────────────┤
│          SEMANTIC LAYER (Executable)            │
│  Metrics · Dimensions · Joins · SQL mappings   │
│  "How do I query those things?"                │
├──────────────────────────────────────────────┤
│          PHYSICAL LAYER (Storage)               │
│  Tables · Columns · Warehouses · Lakes         │
│  "Where is the data actually stored?"           │
└──────────────────────────────────────────────┘

An AI agent operating at the ontology layer can reason about domain concepts and their relationships. The semantic layer translates that reasoning into executable queries. The physical layer stores and serves the actual data. An agent with access to all three can answer "what happened?" (semantic layer), "why did it happen?" (ontology + semantic layer), and "what could happen?" (ontology + predictive models).

Today, most teams have the physical layer well-covered and are investing in the semantic layer. The ontology layer is aspirational for most — but the teams that invest in it early will field agents that understand not just their data but their business.

Conclusion

The semantic layer movement has spent a decade making data queryable in business language — and it has largely succeeded. An analyst can ask for "net revenue by region" and get the right number from governed definitions. The ontology movement, quieter and less productized, has spent decades modeling the conceptual structure of domains — and for most data teams, it has felt like academic overhead. AI agents change that calculus. A semantic layer alone can answer "what." It cannot answer "which of these three relationships between Customer and Contract is the right one for this question" or "does 'product' mean a physical SKU or a service plan in this context." Those are ontological questions, and an agent without answers to them will produce confident wrong results exactly where the domain gets complex. The practical path for most teams is not to build a formal OWL ontology. It is to start with a lightweight Subject Tree — domain-organized, agent-curated, incrementally refined — that gives agents enough conceptual structure to navigate ambiguity without the overhead of a formal specification. The gap between no ontology and a practical Subject Tree is far larger than the gap between a Subject Tree and a formal ontology. Most teams will get 80% of the value by crossing the first gap.

Frequently asked questions

What is the difference between a semantic layer and an ontology?

A semantic layer maps physical data to business concepts for query execution — "net_revenue is SUM(amount_usd - refund_usd) WHERE status = 'completed'." An ontology defines the categories, relationships, and rules of a domain — "a Customer places Orders, which contain LineItems, which reference Products." The semantic layer is database-aware and executable; the ontology is database-independent and conceptual. See §3 for the full comparison.

Do I need an ontology if I have a semantic layer?

For simple analytical queries, no — a semantic layer is sufficient. For complex, cross-domain reasoning — especially when AI agents need to understand how business concepts relate, disambiguate terms, or navigate domain boundaries — an ontology provides the conceptual structure the semantic layer alone cannot.

What is a knowledge graph, and how does it relate to ontology?

A knowledge graph is an ontology plus instance data — the formal model (Customer places Order) populated with actual entities (Acme Corp placed Order #12345). An ontology is the schema; a knowledge graph is the schema plus the data. Most enterprise knowledge graphs combine an ontology (the conceptual model) with instance data from operational systems.

Does Datus maintain an ontology?

Datus's Subject Tree serves an ontology-like function: it organizes business domains into a hierarchy of topics, maps metrics and semantic models to those topics, and gives agents a conceptual map of the data landscape. It is not a formal ontology (no class hierarchies, no property definitions, no inference rules), but it provides practical domain awareness — scoping Subagents, traversing context, resolving ambiguity — without the overhead of a full formal specification.

Related articles

• What is a semantic layer? — the execution layer
• What is a semantic model? — the building block of the semantic layer
• What is a data engineering agent? — how agents operationalize both layers