One model. One meaning. On top of the systems we already have.

The problem: the same question, several answers

Ask three teams in any large organization a simple business question — “how many active customers do we have?” — and you will often get three confident, well-engineered, different answers.

This is not because anyone is careless. It is a structural property of how data estates grow. Our own estate is typical of the pattern: a data lake on Azure Databricks holds large, curated datasets alongside raw landing zones, while a constellation of SQL databases continues to serve operational applications and older reporting. Each system is correct on its own terms. But the meaning of the data — what counts as an active customer, how revenue is netted, which hierarchy defines a region — is not stored in any of them. It lives in BI reports, in ETL code, in spreadsheets, and in people’s heads, re-implemented slightly differently every time someone needs it.

The industry has a name for the missing piece. A semantic layer is a governed layer that sits between data platforms and the tools that consume data, translating technical structures — tables, columns, joins — into business concepts, and recording decisions like “revenue means SalesAmount from the online-sales fact, excluding canceled orders” in exactly one place.^[1][2] Metrics and entities are defined centrally and queried from many “spokes” — BI tools, SQL clients, APIs, and increasingly LLM-based agents — so every consumer works from the same definition, every time.^[3]

This article introduces the concept we are adopting — a semantic model built as an ontology on top of our existing storage — explains the technology we are evaluating to deliver it (Timbr), and sets out one deliberate policy choice: the parts of the model that are ready are already authoritative. We are not waiting for the whole estate to be harmonized before the semantic layer becomes the front door to data in the domains it covers.

What a semantic layer actually is

Strip away the vendor language and a semantic layer is three commitments, made once, kept everywhere:

• Shared vocabulary. Business entities (customer, order, asset, shipment), their attributes, and the relationships between them are named and defined in business terms, not table-and-column jargon.^[2]
• Shared calculations. Metrics — revenue, churn, utilization, on-time delivery — are formulas defined centrally, so “revenue” computed in a dashboard equals “revenue” computed in a notebook or an API call.^[3]
• Shared access semantics. The layer is a governance point: who may see which concept, which rows, which measures — enforced once, not re-implemented per tool.^[1][4]

Databricks describes the semantic layer as the bridge that “translates technical structures into business-friendly terms,” creating a single source of truth that serves both human decision-making and AI-driven analysis.^[1] IBM frames it the same way: an abstraction layer providing consistent definitions so different teams stop interpreting data independently.^[2] The idea is not new — BI “universes” and OLAP cubes were semantic layers scoped to a single tool. What is new is making the layer universal: one definition serving every tool, instead of one definition per tool.^[4]

From glossary to ontology

Many semantic layers stop at a catalog of metrics: useful, but flat. The stronger form — the one we are pursuing — is an ontology: a formal, machine-readable model of a business domain, expressing not just terms but structure and logic.

Ontologies come from a mature body of work standardized by the W3C. The Resource Description Framework (RDF) models facts as subject–predicate–object statements, and the Web Ontology Language (OWL) builds on it to define classes, properties, hierarchies, and logical constraints rigorous enough that software can check consistency and infer knowledge that was never explicitly stored.^[5][6] This is not academic exotica: entire industries maintain shared ontologies as working infrastructure — finance has the EDM Council’s Financial Industry Business Ontology (FIBO), which formally defines legal entities, instruments, and contracts;^[7] healthcare runs on SNOMED CT, a clinical ontology of hundreds of thousands of concepts used in electronic health records worldwide.^[8]

What an ontology adds over a metric catalog

• Concepts and inheritance. A B2B customer is a customer; everything true of customers (attributes, measures, access rules) is inherited automatically. Definitions are written once at the right level of abstraction.^[9]
• First-class relationships. “Customer places order,” “order contains product,” “plant ships to region” are modeled explicitly — so a question that spans five tables becomes a path through named relationships, not a hand-crafted five-way join.^[9]
• Rules and inference. The model can classify data by logic (“a customer with an order in the last 90 days is an active customer”), so derived business states are computed from definitions rather than baked into pipelines.^[5][9]

Together, the concepts, relationships, and rules over our data form a knowledge graph — but, crucially, one that can be virtual: a graph of meaning laid over data that stays exactly where it is today.

Why Timbr: an ontology you query in SQL

Classical ontology stacks ask an organization to adopt a parallel universe: RDF triple stores, SPARQL queries, and specialist skills far from where data teams live. The reason Timbr is our leading candidate is that it collapses that distance: it implements the ontology as an extension of SQL, so the knowledge-graph ideas above become accessible to anyone who can write a SELECT statement.^[13]

The core mechanics

• SQL-native ontology. Concepts, inheritance (“is-a” hierarchies), relationships, and business rules are defined and queried in standard SQL; the ontology is exposed as a virtual schema that behaves like tables.^[9][13]
• Virtual knowledge graph over existing sources. Timbr maps concepts to the underlying databases and lakehouse tables and pushes queries down to them — federating across sources without moving or duplicating data.^[9][11]
• Joins become relationships. Because relationships are part of the model, analysts traverse them in SQL without writing explicit join chains; the engine resolves the paths.^[9]
• Measures defined once, inherited everywhere. Metric definitions attach to concepts and flow down concept hierarchies, so consistency is structural rather than disciplinary.^[11]
• Standard plumbing. The model is consumed through JDBC/ODBC drivers, SQLAlchemy, REST APIs, and native connectors for Power BI, Tableau, and Excel — plus NL2SQL interfaces for natural-language querying grounded in the ontology.^[13]

The Databricks fit

For our lakehouse, the integration is direct: Timbr partners with Databricks and embeds as an ontology-based semantic layer inside the lakehouse, mapping business concepts, relationships, and measures to Delta tables without moving data.^[11] The semantic model is exposed through Unity Catalog / the metastore, so governance stays aligned with the platform we already operate; queries against the model can be issued straight from Databricks notebooks in SQL, Python, R, or Scala; and SSO can unify access control between the two.^[12] The same model simultaneously reaches into our SQL databases — one ontology, both storage worlds.

To make it concrete, here is the shape of the experience for an analyst. Instead of reconstructing the join path from a wiki page:

-- Before: physical SQL, meaning reinvented per query
SELECT c.customer_name, SUM(f.sales_amount)
FROM   gold.sales_fact f
JOIN   gold.customer_dim c  ON f.customer_sk = c.customer_sk
JOIN   erp.dbo.Kunden k     ON c.source_id   = k.KundenNr   -- which key? ask around
WHERE  f.status NOT IN ('X','C')                            -- is this "net"? unclear
GROUP  BY c.customer_name;

-- After: the ontology carries the meaning
SELECT customer_name, net_revenue
FROM   dtimbr.customer
WHERE  is_active = true;

(Illustrative query shape — concept and measure names come from our model, and net_revenue and is_active resolve to the single, governed definitions.)

Why we are not waiting for harmonization to finish

We are mid-way through harmonizing our data model — aligning entities, keys, and reference data across the lakehouse and the SQL estate. A reasonable-sounding instinct says: finish that first, then build the semantic layer on the clean result. We are deliberately rejecting that sequencing, for three reasons.

1. The semantic layer is how harmonization ships

Harmonization produces its value only when consumers actually use the harmonized definitions. A virtual semantic layer lets each harmonized domain go live the moment it is ready: the ontology exposes the agreed concepts, mapped to wherever the best current physical data lives — a gold Delta table for one domain, a legacy SQL database for another. Practitioner guidance on semantic layers is unambiguous on this point: successful programs start with a small, high-value scope and expand iteratively, rather than attempting a big-bang model of everything.^[14][3]

2. Virtualization decouples consumers from the cleanup

Because the layer maps concepts to sources instead of copying data, harmonization work continues underneath it without breaking anyone. When a domain’s physical home migrates — a source system retired, a table redesigned, a dataset promoted from silver to gold in the medallion flow^[10] — the remapping happens once, in the model. Dashboards, notebooks, and APIs keep asking the same questions in the same language. The semantic layer is thus not a consumer of the harmonization program; it is its stabilizing interface.

3. Waiting has a real price

Every quarter without a shared model is a quarter of new dashboards, pipelines, and now AI agents encoding their own private definitions — inconsistency compounding at exactly the moment we are trying to eliminate it. Publishing the ready domains now freezes the bleeding in those domains immediately.

The AI dividend: semantics is what grounds the agents

There is a second, forward-looking reason the semantic model matters more in 2026 than it would have five years ago: it is rapidly becoming the difference between AI that answers data questions correctly and AI that hallucinates plausibly.

The evidence is consistent across independent studies. The data.world benchmark quoted above found GPT-4’s accuracy on enterprise SQL questions jumped from 16.7% to 54.2% — roughly 3× — when the model queried a knowledge-graph representation built from an ontology and mappings instead of the raw schema, with the largest gains exactly where it matters: complex, multi-table, metric-style questions.^[15] dbt Labs’ 2026 benchmark update reports the same shape of result with current frontier models: questions answered through a well-modeled semantic layer reached 98–100% accuracy, versus 84–90% for direct text-to-SQL on the same dataset — and, as importantly, the semantic layer’s deterministic query generation removes the failure mode of subtly-wrong SQL that looks right.^[16]

The mechanism is intuitive. An LLM guessing against raw tables must infer which of three customer tables is authoritative, which status codes mean “canceled,” and how five tables join — precisely the tribal knowledge that raw schemas do not carry. An LLM querying an ontology receives that knowledge explicitly: the concepts, the relationships, the sanctioned metric formulas. Timbr leans into this directly, using the ontology to ground natural-language-to-SQL so that generated queries are constrained by the model rather than free-styled against the schema.^[13]

In other words: the semantic model we are building for human consistency is the same asset that makes governed, self-service AI analytics feasible. We build it once and both audiences — people and agents — speak through it.

How we will work: the model as a product

A semantic model earns authority by being trustworthy, current, and owned. Concretely, the practices we are adopting:

1. Domain by domain, value first. We publish the ontology for the harmonized domains now and sequence the rest by business value, following the iterative expansion pattern the field recommends.^[14]
2. Definitions are reviewed like code. Concepts, relationships, and measures live in versioned model definitions; changes go through review by the domain’s data owner and are released with change notes. (Because Timbr expresses the ontology in SQL, this fits our normal engineering workflow.^[13])
3. One front door. BI connections, notebook access, APIs, and AI agents consume the model through its standard interfaces — JDBC/ODBC, REST, the Unity Catalog exposure on Databricks^[12] — rather than re-deriving logic from physical tables.
4. Reuse before invention. Where mature industry ontologies exist for a domain, we align with them instead of inventing vocabulary — the FIBO and SNOMED CT ecosystems demonstrate how much leverage shared ontologies provide.^[7][8]
5. Adoption is the metric. We will measure the model the way products are measured: how many questions are answered through it, how many definitions moved out of report-local formulas into the ontology, how often two tools disagree on a number (the target is a boring zero).

None of this requires heroics. It requires the discipline of treating meaning as first-class infrastructure — the same discipline we already apply to pipelines and platforms, aimed one level higher.

Where to go from here

If this article gave you the concept, the references below give you the depth: start with Databricks’ and IBM’s overviews of semantic layers,^[1][2] then Timbr’s introduction to SQL-native ontologies^[13] and the Databricks integration,^[12] and — if you want the evidence trail for the AI claims — the data.world benchmark paper.^[15] Questions, challenges, and candidate domains for the next modeling wave are all welcome: a shared language only works if it is genuinely shared.