Semantic Layer, Semantic Layer, or Semantic Layer?

Three different technologies share one name. If you're evaluating a "semantic layer" right now, you need to know which one you're buying.

---

"Semantic layer" is one of the most overloaded terms in data. When a BI vendor says it, they mean one thing. When AtScale, Cube, or Coginiti says it, they mean something related but architecturally different. When someone with a knowledge-graph background says it, they mean something else entirely — a tradition with its own conferences, its own W3C standards, and a thirty-year head start on the question of how machines represent meaning.

The confusion isn't pedantic. We regularly talk to data leaders who have been pitched all three under the same label, and who reasonably conclude the category is vapor. It isn't. These are three distinct lineages that emerged from three distinct problems, and the reason the term suddenly matters again is that AI agents need all three things at once.

So let's disambiguate. Semantics, after all, is the study of what words actually mean.

Lineage 1: The BI semantic layer (1991)

The term has a birthplace and a patent number.

In 1990, Bernard Liautaud and Denis Payre founded Business Objects in a Paris suburb, building on technology from an independent engineer named Jean-Michel Cambot. Cambot's insight: business users shouldn't need SQL to ask business questions. Instead, IT would define a layer of "business objects" — Customer, Revenue, Region — that mapped friendly names onto the relational schema underneath. Users would drag and drop objects; the tool would generate the SQL.

Business Objects filed U.S. Patent 5,555,403, "Relational Database Access System Using Semantically Dynamic Objects," in November 1991. They called the abstraction a universe, and only later started calling the idea a semantic layer — by Liautaud's own account, the name came after the invention. The company defended the patent aggressively through the 1990s and 2000s, extracting settlements from Brio and Cognos before SAP acquired Business Objects for $6.8 billion in 2007.

Every major BI tool since has shipped its own version of the same idea: Cognos Framework Manager models, MicroStrategy schema objects, Looker's LookML (2012), Tableau data models, and Power BI datasets — which Microsoft pointedly renamed "semantic models" in late 2023, an acknowledgment that the 1991 idea had become the category's center of gravity again.

What it is: a business-friendly abstraction over a schema, designed so humans can build reports without writing SQL.

Its defining limitation: it lives inside the BI tool. Define Revenue in your Business Objects universe and it exists only there. Define it again in Tableau, again in Power BI, again in Looker — and now you have four definitions of Revenue, which is precisely the problem the semantic layer was invented to solve. The abstraction worked; the architecture trapped it.

Lineage 2: The universal semantic layer (2013–present)

The second lineage starts from that limitation. If every consumption tool embeds its own semantic layer, the fix is to pull the semantics out of the tools and make them a standalone tier of the data platform — defined once, consumed everywhere.

AtScale, founded in 2013, is the canonical early example, originally framed as "OLAP on Hadoop": a virtualized cube layer that let Excel and Tableau query big data through one consistent dimensional model. AtScale's Dave Mariani has been open about borrowing the term from Business Objects; the innovation wasn't the word, it was the position in the stack.

The idea accelerated around 2020–2021 with the "metrics store" wave. Airbnb published details on Minerva, its internal metrics platform. Startups like Transform built headless metric stores. Analysts argued the modern data stack had a missing layer between transformation and consumption. dbt Labs agreed strongly enough to acquire Transform in 2023 and build its MetricFlow-based Semantic Layer. Cube, which began as the open-source Cube.js project, generalized from embedded analytics into a universal layer with APIs for SQL, REST, GraphQL — and, lately, MCP.

By 2025 the category had matured enough to need interoperability: the Open Semantic Interchange (OSI) initiative brought Snowflake, Salesforce, dbt Labs, AtScale, Coginiti, and others together on a vendor-neutral specification for exchanging semantic models. When competitors agree on a wire format, a category has arrived.

What it is: a centralized, tool-agnostic tier where metrics, dimensions, and entities are defined once and served to every consumer — BI tools, notebooks, applications, and now AI agents.

Its defining limitation: most implementations are, at heart, metric catalogs. They answer "what is Revenue?" with a SQL expression and an owner. They are far weaker at "how does Revenue relate to Bookings, which contracts roll into it, what does active customer mean in the dialysis business versus the pharmacy business, and what should an agent do when a question is ambiguous?" Definitions, yes. Meaning, only partially.

Lineage 3: The Semantic Web and ontologies (1999–2012)

The third lineage never used the word "layer" much, but it owns the word "semantic" by seniority.

This tradition descends from AI knowledge representation research — semantic networks, Minsky's frames, description logics like KL-ONE in the 1980s — and went mainstream when Tim Berners-Lee, James Hendler, and Ora Lassila published "The Semantic Web" in Scientific American in 2001. The vision: a web of machine-readable meaning, where data carried formal descriptions of what it was, not just how it was formatted.

The W3C built the stack: RDF for representing facts as subject–predicate–object triples, OWL (2004) for defining ontologies — formal models of concepts, properties, and the logical relationships between them — and SPARQL (2008) for querying it all. The grand vision of a fully semantic web never materialized, but the technology found a durable home in the enterprise: Google's Knowledge Graph launched in 2012 with the tagline "things, not strings," and knowledge graphs became standard infrastructure in pharma, finance, intelligence, and anywhere else that entity resolution and inference across messy data is the core problem.

What it is: formal, machine-reasoned models of concepts and relationships. An ontology doesn't just define Customer; it asserts that a Customer is a LegalEntity that holds at least one Account, that Accounts have Contracts, and that a reasoning engine can infer facts nobody explicitly recorded.

Its defining limitation: distance from the operational data. Ontologies excel at representing meaning and historically struggled to connect that meaning to the tables where the business actually lives — and to do so at the price point and skill set of a typical data team. The semantic web community solved expressiveness; it never solved adoption.

Why agents force the question

For thirty years these lineages could ignore each other, because they served different consumers. BI semantic layers served report builders. Universal semantic layers served data platform teams. Ontologies served knowledge engineers.

AI agents collapsed the distinction, because an agent asking a question of your data needs all three things simultaneously:

1. Trusted definitions (the BI lineage's contribution): which expression is Net Revenue, certified by a human owner.
2. Universal, governed access (the universal layer's contribution): one place to get those definitions, regardless of which tool — or which agent — is asking.
3. A model of relationships and context (the ontology lineage's contribution): how concepts connect, which joins are valid, what the business means — because an agent that can't navigate meaning produces confident, plausible, wrong answers.

You can watch the pressure in the metadata itself. For thirty years, a description in a BI semantic layer was a tooltip — documentation for a human picking from a curated list. The moment the consumer became a language model, descriptions became context an agent reasons over, and synonyms became load-bearing: modern semantic model specs now carry explicit synonym fields so that "turnover," "sales," and "rev" all resolve to the one governed Revenue. Here's the thing — the ontology lineage solved exactly this problem long ago. Preferred labels, alternate labels, and formal definitions were standardized in SKOS back in 2009. Synonym fields in a YAML semantic model are a folk reinvention of what knowledge engineers have been doing with full rigor for fifteen years. That's not an argument for rebuilding OWL inside your metrics layer — full ontological expressiveness is a different tool for a different job. It's an argument that the two traditions are solving adjacent problems and ought to interoperate, rather than pretend the other doesn't exist.

A metric catalog without relationship context leaves the agent guessing at joins. An ontology without bindings to live data leaves the agent reasoning beautifully about tables it can't query. A BI-embedded model leaves the agent locked out entirely. No single lineage covers the whole problem, and the next five years won't be decided by which semantic layer "wins." They'll be decided by whether your definitions, your access layer, and your knowledge models can operate together — compatibly, through open interfaces — in front of an agent.

Defining meaning versus operationalizing it

This is the distinction we built Coginiti around, and it's why we describe the platform as semantic intelligence rather than a semantic layer.

A semantic layer, in any of the three senses above, is fundamentally a place where meaning is defined. That's necessary and insufficient. Definitions that sit in a catalog are documentation. What agents and analysts need is meaning that is operational: definitions bound to executable logic, embedded in a graph of relationships, enforced at query time, and available wherever work happens — SQL, pipelines, BI, or an agent conversation over MCP.

To be precise about where Coginiti sits in the taxonomy above: our built-in semantic layer is a universal semantic layer — the same lineage as AtScale and Cube. What's different is what happens to a definition once it exists. In Coginiti's semantic graph, definitions are bound directly to executable CoginitiScript, so the path from "what does this mean?" to "run it, governed, against the warehouse" is one step, not an integration project. And because that layer speaks open interfaces — MCP for agents, OSI for semantic model interchange — it's built to operate alongside the other lineages, not to replace them. If your organization has invested in an ontology or knowledge graph, that's a complementary asset: it holds the deep conceptual model, while the universal layer holds the executable, governed definitions agents query against. Compatibility, not conquest.

The word "semantic" has meant three different things for thirty years. The agentic era doesn't collapse them into one — it forces you to know which one you're talking about, and to make them work together. That's the difference between an AI that answers and an AI you can trust.