Can ontology replace a semantic layer?

• A semantic layer calculates. It has no entry for a concept's identity or its connections to other concepts.
• An ontology adds named concepts and typed relationships, such as part of, calculated from, and regulated by. Teams usually build it by extending the glossary they already have.
• In one benchmark test, adding Collate's context graph to the semantic layer took text-to-SQL execution accuracy from roughly 11% to roughly 77%, about a 7x lift.
• An agent without an ontology guesses from column names on relationship questions. With one, it follows a traceable path it can show.
• A governed metric by region still resolves through the semantic model's definition, and a relationship question resolves through the ontology, both pulling from the same columns and tables.

A semantic layer locks one formula per metric

Open a dbt model, a LookML view, or a Cube definition, and you'll find a metric formula pinned to particular tables, joins, and dimensions. Revenue means this column, summed this way, filtered by this flag. Your business intelligence (BI) tool reads those definitions and writes the SQL for you, so every dashboard, every analyst, and every scheduled report gets the same number for "active users" instead of five slightly different ones.

A semantic layer solves that problem well. Ask a governed question by a known dimension, like revenue by region or churn by cohort, and the semantic layer has the formula and tables it needs on hand.

…but it has no entry for identity or relationships

Ask it something else, and there's nothing there. A semantic layer has no entry for a concept's identity, its relationships to other concepts, or the columns that carry it across your warehouse. It was never asked to hold that information, so it doesn't fail and alert anyone when you need it. Ask for a concept's identity or its connections, and it has nothing to look up.

Shawn, a Collate engineer, described this limit in a video walkthrough. On relationship questions, the semantic layer has no error to correct, only an empty space where an answer should be.

The agent guesses from column names and sounds sure

Put an AI agent in front of a semantic layer and ask about the columns your privacy policy covers, and you can watch the missing piece turn into a wrong answer. There's no metric called "covered by privacy policy," so the agent falls back on column names, the only signal it has. It matches on column names that sound right and answers with full confidence. The response shows no sign of a guess. A stakeholder reading that answer has no way to spot the missed items or the wrongly included ones, because the agent can't spot them either.

Typed relationships connect named concepts

An ontology fills exactly that hole with named concepts and typed relationships between them. Personal data, privacy policy, and email address column are each named concepts. Then come the relationships that connect them: part of, calculated from, regulated by. An ontology is a set of business concepts, and each concept is a named thing, so a concept like "personal data" exists once, with a definition, instead of being reconstructed from guesswork each time.

Most teams don't start from nothing here. The fastest path is promoting the business glossary a team already maintains into a set of concepts and adding the relationships between them, rather than building a new structure from scratch. That gives an agent links it can walk, built on typed structure instead of a fuzzy name match, which is a different kind of answer than a guess dressed up as a result. The tagging work a team already did against a standard set of data classes carries forward too, instead of getting redone.

The agent traces a path instead of guessing

Run the privacy policy question again with the ontology connected, and the path changes completely. The agent walks from the policy concept to personal data, to the specific attributes like email and home address, to the tagged columns, and through lineage to the dashboards those columns feed. Every hop is a typed relationship, so the agent can show the path it took to get there instead of asserting a list.

That traceability lets a stakeholder trust the answer. It's why the concept graph is worth examining on its own terms, separate from the semantic layer, rather than folding the two views into one and losing each one's strength. The ontology also inherits the governance and access rules already attached to that data, so a column that's restricted in your catalog remains restricted when an agent reaches it through a relationship instead of a query.

An ontology sits alongside the semantic layer, not instead of it

None of this touches the calculations the semantic layer already handles well. Ask for churn by region, and the answer still resolves through the semantic model's definition, using the formula, tables, and number every analyst already trusts. The ontology doesn't redefine any metric. It sits alongside the metric layer, handling concepts while the metric layer keeps handling calculations. A single query can draw on both views: the governed number from the semantic layer and, through what a semantic context layer actually does, the relationship that explains the number's meaning.

That's also why an open ecosystem can ship ontology support as an addition rather than a rebuild. Ontology Explorer landing in the open-source project builds on the existing glossary and metadata model instead of replacing it, giving every team on that model a common picture of the data estate without touching the metric definitions they already rely on.

Accuracy rose from 11% to 77% in testing

The lift shows up in testing. In that test, the same model ran with and without the context graph, and accuracy rose from roughly 11% to roughly 77%, about a 7x improvement. The test used the hardest of three datasets, a subset of Spider 2.0-Snow built on sparse, undocumented schemas. It's real but not a guarantee; roughly one in four queries are still wrong. The lift came from giving the agent documented context for schemas that had none, instead of guessing from column names. Gartner's research points to the same mechanism at industry scale, projecting a rise in agent accuracy and a drop in run cost for organizations that prioritize semantics in their AI-ready data, as agent adoption grows through 2027.

The two data points point the same way. An agent that can look something up answers differently than one that has to guess, and that difference is the risk you're carrying today every time an agent answers a relationship question with full confidence and zero evidence behind it.

Start with the questions your agent gets wrong

You don't need to model your entire business before this pays off. Start with the questions your agent keeps getting wrong, the ones where it gave you a confident answer that turned out to miss something or include something it shouldn't have. Find the relationship behind that specific failure, write it down using the glossary terms your team already has in place, and connect it to the columns it governs. Expand from there, one traceable relationship at a time, and the ontology grows exactly as fast as the questions that need it. Treat each relationship the way you already treat a glossary term, with an owner who updates it when the glossary or the warehouse underneath it changes.

The semantic layer isn't going anywhere, and it shouldn't. It's still the fastest way to get a governed number. The ontology lets your agent answer the question underneath that number: a concept's identity and its connections, instead of guessing.

FAQs

Does an ontology replace my dbt model, LookML view, or Cube definition?

No. Those definitions still calculate your governed metrics the same way they always have, formula, tables, and joins intact. An ontology sits next to that layer and handles the questions those tools were never built to answer, like a concept's meaning and its relationship to other concepts, because those questions sit outside what a metric formula can hold.

What's the difference between a business glossary and an ontology?

A glossary defines terms in prose, one entry at a time, with no way for a system to act on the relationships between them. An ontology takes those same terms and connects them with typed relationships such as part of, calculated from, and regulated by, so an agent can walk from one concept to the next instead of reading a definition. Most vendors now call some part of their product an ontology, so the mechanism matters more than the label.

Does an ontology recalculate or redefine my metrics?

No. The ontology doesn't redefine any metric, and a governed number like revenue by region still comes from the same formula it always has. The ontology adds the relationship context around that number: the governing policy and the columns that feed it.

We already have a glossary. What does it take to turn it into an ontology?

Start by adding typed relationships between the terms you've already defined. That tagging work carries forward into the ontology instead of getting redone.

Can one AI agent use both the semantic layer and the ontology in the same query?

Yes. Both draw on the same columns and tables, so one query can return the governed number and the relationship behind it. Access rules stay intact wherever the agent reaches.

Ready to see what your agent is missing

Your team already has the glossary and the catalog an ontology builds on. Connect the relationships your agents keep guessing at. Talk to Collate.