Ontology vs. Semantic Layer: Why Your AI Agent Needs Both

One Metric, Three Numbers

Since we shipped OceanBase DataPilot, one pattern has come up with almost every customer: the same metric returns a different number depending on who asks. Finance says revenue is 10.2M. Marketing says 10.4M. The AI assistant in Slack says $9.8M. Three numbers, no agreement.

That used to be a people problem, and people could settle it in a ten-minute meeting. An agent won't ping a colleague to ask how a metric was defined. When it hits a column called rev_ttm_adj_v2, it either invents an answer or takes the first definition it happens to find.

Injecting modeled domain knowledge into the retrieval path has been shown to cut hallucination rates by around 40% — but only if that knowledge is actually modeled somewhere, rather than living in the heads of the three people who built the tables. This is why we treat the context layer as a first-class part of OceanBase's AI Lakebase architecture. It doesn't matter how much data you can store or how capable the agent is: if everything between them is raw tables and SQL, the business will never trust the output.

The Context Layer

Context Layer isn't a product name. It's the layer that wraps semantic definitions, domain knowledge, lineage, governance policy, quality signals, and certification status behind one interface that humans and agents can both query.

Ontologies and semantic layers are its two load-bearing pieces. Vendors like to fold them into a single buzzword, but they solve different problems — and teams that build them in the wrong order end up with AI projects that demo beautifully and never reach production.

The Division of Labor, in One Sentence

A semantic layer answers "what is our revenue?" An ontology answers "what is a customer?"

The semantic layer owns metrics: how revenue, MAU, and LTV are calculated, which tables to join, which filters apply. Its job is to make sure every team and every tool computes them identically.

The ontology owns meaning: what a customer is, how a customer relates to an order, which rules make a customer Platinum, and whether a machine can derive new conclusions from facts it already has.

Ontology: Concepts, Relationships, and Reasoning

The textbook definition — "an explicit formal specification of a shared conceptualization" — comes down to three parts:

• Classes — the kinds of things in the domain (Customer, Product, Order, Region)
• Properties and relationships — how they connect (a Customer places an Order; a Product belongs to a Category)
• Axioms and rules — the logical constraints (every Order contains at least one Product; a Customer belongs to exactly one Region at any given time)

Because ontologies are written in W3C standards such as RDF and OWL, machines can do more than read them — they can reason over them. If the ontology says a Platinum customer is one with annual revenue above 1M, and the facts say Acme's annual revenue is 2M, the engine concludes on its own that Acme is Platinum. Nobody writes the if-else. This is the part semantic layers and BI tools can't do: they execute calculations you defined in advance, but they never derive a fact you didn't.

Ontologies also reconcile vocabulary across systems. CRM calls it a Customer, ERP calls it a Client, Finance calls it an Account — the ontology points all three at the same business object. An agent grounded in an ontology traverses a connected graph instead of guessing its way through a pile of unrelated tables. SNOMED CT in healthcare and FIBO in financial services are the canonical examples; in regulated domains, a formal ontology is effectively table stakes.

The cost is just as clear. Palantir turned enterprise ontology into a category, but the delivery model is heavy: forward-deployed engineers, hand modeling, six to eighteen months for a full build, and formal-logic skills that are genuinely hard to hire.

Semantic Layer: Metrics, Logic, and Numbers That Agree

The semantic layer comes from a more pragmatic engineering tradition. Business Objects shipped "Universe" in the 1990s to hide complex schemas behind business language, and the problem it addressed hasn't changed since: teams calculate revenue differently, the numbers disagree, and trust erodes. What's new is the blast radius. Inconsistent definitions used to produce an awkward slide; now they produce a hallucinated number inside a decision report.

A modern semantic layer has four parts: a metadata repository that maps mrr_calc_v3 to "monthly recurring revenue"; a business logic engine that holds metric formulas in one place, defined once and reused everywhere; query translation that generates the joins and filters; and access control that applies row- and column-level permissions consistently.

The tooling has matured quickly. dbt Semantic Layer with MetricFlow put metrics under version control as YAML and compiles them to multiple SQL dialects. Snowflake, Salesforce, dbt Labs, and BlackRock launched OSI (Open Semantic Interchange) in September 2025, and v1.0 shipped in January 2026 as a vendor-neutral standard for exchanging semantic metadata. LookML, DAX, Cube, AtScale, Snowflake Semantic Views, and Databricks Metric Views are all converging on the same idea: the semantic layer is becoming standard infrastructure in an AI-ready data stack.

It still has a ceiling. It can tell you exactly how revenue is calculated. It cannot tell you how a customer relates to a market and a regulatory framework, or whether an account should be flagged as high-risk under a set of domain rules.

As Jessica Talisman put it in Metadata Weekly: the semantic layer is for lookup; the ontology is for context and reasoning.

What Breaks When You Only Build One

Semantic layer only: accurate but shallow. Ask which channel drove the highest GMV last month and you get a precise answer. Ask why that channel declined, or whether you should increase spend on it, and you get nothing. The layer has no model of how channels, spend strategy, and customer profiles relate.

Ontology only: fluent about concepts, useless on numbers. Ask whether Acme is a Platinum customer and the reasoning is flawless. Ask what Acme's revenue was last month and you're back to three answers, because nothing tells the system which fact table to query or how to aggregate it.

The industry data points the same direction. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing cost, unclear value, and inadequate controls. In a survey of 248 data management leaders, 63% said they lacked the data management practices needed to support AI. Most of these failures aren't about picking the wrong model; they're about data with no semantic grounding underneath it.

The other side of the trend is just as visible. Gartner's 2026 summit projected that by 2030, universal semantic layers will sit alongside data platforms and cybersecurity as critical infrastructure, and Futurum expects adoption to grow from 16% in 2026 to 30% by 2031. Microsoft Fabric IQ is previewing native ontology support, and Timbr.ai markets "semantic layers with reasoning." The two paths are merging.

Where Knowledge Graphs and Taxonomies Fit

A knowledge graph holds the instances — actual customers and actual orders as nodes. The ontology is the schema; the knowledge graph is the data. When an agent walks relationships at runtime, it's walking the graph.

A taxonomy is an ontology with the hard parts removed: parent-child hierarchies, no reasoning, no lateral relationships. Product catalogs, data domain classification, and PII tagging all start here, and that's a reasonable place to start. You only need to move toward a full ontology once an agent has to reason across categories — "if category A is downgraded, does category B's inventory get affected?"

Putting It Together

We think about the context layer in two halves:

• Data context — ontology, semantic layer, knowledge graph, lineage, quality scores, access policy. This tells the AI what kind of business it is operating inside.
• Application context — user preferences, conversation history, domain documents, retrieved facts (memory plus RAG). This tells the AI who it is talking to.

In practice, a single question flows through all four:

1. The ontology defines "revenue recognition" as a concept, along with the rules attached to it
2. The semantic layer turns that into computation — which tables to join, how to aggregate
3. The knowledge graph connects the concept to its metrics, lineage, and downstream consumers
4. MCP delivers that context to the agent at inference time

Everything the context engineering discussion has produced over the past two years lands on the same conclusion: reliable output requires structured context, and ontologies and semantic layers are the two hardest pieces to get right. MCP solves the delivery problem. It does nothing about what you deliver — hand an agent ungoverned tables and SQL, and the protocol will faithfully transport a hallucination.

What We Built: OceanBase OSI

Rather than shipping another BI semantic layer, we unified metrics, definitions, raw data, the context graph, and the ontology into one open semantic stack: OceanBase OSI (Open Semantic Interchange). It has three layers.

• Semantic layer (bottom). Metric definitions, calculation rules, and dimension-to-data mappings. It is built on the Ant-OSI standard, compatible with industry OSI, and has been running in production at Ant Group.
• Context graph (middle). Metrics, objects, events, lineage, and consumers connected as a network. An LLM reasoning over this graph does measurably better than one reading table schemas or YAML alone.
• Ontology layer (top). Business semantics aligned with database semantics. Workspace-local terminology and enterprise-wide concepts stay linked while evolving on their own schedules.

The principle underneath all three is semantic as code: define the semantics once, then let BI render dashboards, agents generate SQL, and governance tools trace lineage — all against the same definition. No separate semantics for BI, for AI, and for governance.

Across customer POCs in several industries, DataPilot's natural-language-to-data accuracy has come out well ahead of the alternatives it was measured against. The model isn't the differentiator — everyone is calling the same frontier LLMs. The differentiator is the quality of the semantic context. Give an agent accurate business definitions instead of raw tables, and NL-to-SQL accuracy improves in a way no amount of prompt tuning will match.

Where to Start

Start with the semantic layer if:

• Teams disagree on what "revenue" or "active user" means
• You're building conversational analytics or chat-with-data
• Your data stack is already centralized and you want returns in two to six months

Start with the ontology if:

• You're in finance, healthcare, or government, where compliance requirements are strict
• Your AI has to reason across domains — customer × product × regulation
• The same concept goes by a different name in half a dozen systems
• You need automated classification or rule-based anomaly detection

For most enterprises, the pragmatic sequence is:

1. Build the semantic layer first. Centralize core metrics so BI and AI read the same definitions.
2. Keep the ontology light to begin with — a business glossary, not a full OWL modeling effort.
3. Layer in governance signals: lineage, quality scores, ownership, certification.
4. Expose all of it to agents over MCP, which is what turns the context layer from a diagram into infrastructure.

dbt won't give you an ontology. A Palantir-style ontology doesn't fit every team. Growing from a glossary into a formal ontology is a far more realistic path than trying to land the whole thing in one jump.

What's Next

Short term, we're rolling the OSI semantic layer out to every DataPilot workspace, with metrics managed centrally in Ant-OSI format and terminology, metrics, and dimensions all discoverable and searchable.

Medium term, we're hardening the OSI ontology layer. Business glossaries, category hierarchies, and entity relationships ship first as a productized taxonomy, then gain cross-system alignment and basic reasoning. That growth happens domain by domain, not top-down.

Long term, the hard question is what happens when domains that modeled their semantics independently need to merge them. Reconciling those conflicts — and keeping the relationship between local and global definitions evolvable — is the problem the OSI context graph exists to solve.