Three Platforms, One Layer: The Semantic Model Stops Being Optional

Databricks has taken Unity Catalog Business Semantics to general availability and open-sourced its core implementation into Apache Spark, Snowflake has released Semantic Views, and Microsoft has Ontology in public preview inside a Fabric workload called Fabric IQ ^[1][2][3]. Three vendors shipping the same layer in the same window is not a coincidence of roadmaps; it is what happens when the consumer of your data model stops being a person who can ask a follow-up question.

The ambiguity being addressed is old and unglamorous: what counts as an active customer, whether revenue is net or gross, whether a sale includes returns ^[4]. The answer usually exists in a finance director's head, an outdated document, or a DAX measure one person maintains ^[5]. Reporting survived this for years because a trained analyst can navigate an unclear definition and apply judgement ^[6]. An agent cannot. It works only with the definitions available to it, and inconsistent definitions produce inconsistent answers ^[7]. Databricks framed its own release explicitly around giving analysts, engineers and AI agents a single trusted source of metric definitions ^[1].

The interesting part is the architectural distinction Microsoft is drawing, because it is the one most teams will get wrong. A semantic model is a technical artefact: tables, columns, relationships, measures, tied to how the data is physically structured ^[8]. An ontology sits a level above that, describing what a concept means independent of storage, so a single concept such as Customer might map to one table, several tables across different systems, or a calculation spanning multiple sources ^[9]. Fabric's ontology is assembled from entity types, entity instances populated from real data, and properties and relationships, over a queryable graph built from data bindings so relationships can be traced instead of being buried in join logic ^[10][11]. Ontology and semantic models are positioned as complementary, both built on OneLake, and ontologies can be generated from existing Power BI semantic models ^[12][13]. That generation path is the honest admission in the whole design: the definitions already exist, badly organised, in the BI layer.

For what this looks like in production, Databricks published its own account of Scottish Water, which built a natural-language interface to capital investment portfolio data on Genie under the internal name SPARK ^[14]. A user asks in Microsoft Teams via Copilot, a Copilot supervisor agent connects to the Genie Space over the Model Context Protocol, and Genie translates the question into a query against governed data in Unity Catalog ^[15]. The answers are derived from governed metric views ^[16]. Strip out the interface and the load-bearing component is the metric view, not the chat window.

Treat the savings arithmetic with care. Databricks reports that a typical project lookup previously took around eight clicks plus dashboard load time, and that report hunting was a four to five step journey ^[17][18]. The headline figure of roughly 520 to 1,300 hours saved per year is a scenario, not a measurement: it assumes 100 users asking three questions a week at two to five minutes saved each ^[19]. The internal arithmetic holds ^[20], but every input is an assumption.

What to watch: whether anyone outside Databricks actually builds on the open-sourced Spark implementation, since a standard only matters if a second vendor adopts it ^[2]; whether Fabric IQ Ontology reaches general availability from its current preview ^[3]; and whether ontologies generated from existing Power BI models resolve contested definitions or simply inherit them at a higher altitude ^[13].