Every organization has experienced this nightmare: the same KPI defined differently across tools. Sales revenue calculated one way in Power BI, another in Tableau, and yet another in Databricks. Teams invest a lot of time in manually reconciling definitions and building custom ETL to fix these issues. If they do not do this a possible result is that AI-driven analytics tools produce unreliable outputs because the semantic definitions they're grounded in are inconsistent.
This isn't a technical problem, but a semantic problem that requires a semantic solution.
The Problem: Semantic fragmentation is destroying value
For decades we've outsourced semantic authority to monolithic BI platforms. Each tool built walls around its proprietary format, knowing that semantic lock-in would keep the customers. The result is that the more time you spend to build semantic intelligence into a BI platform, the harder it becomes to leave it. You don't just lose the tool; you lose the definitions of your entire business.
What Apache Ossie actually is
Apache Ossie is a vendor-agnostic semantic model specification designed to make semantic models as portable as code repositories. One definition. Every tool. Zero lock-in.
It is a JSON/YAML-based semantic model specification that describes business entities, relationships, and metrics in a vendor-neutral way. Think of it as a "semantic intermediate language", Ossie lets you define semantics once and deploy to any tool.
Ossie doesn't try to be a universal execution language. It doesn't prescribe how your data warehouse works or how metrics are computed. Instead, it gives you a common surface where tools can agree on what your semantic model means.
source: snowflake
The scalability of the Hub-and-Spoke converter architecture
Ossie's greatest design insight is architectural. Instead of requiring N*(N-1) point-to-point converters between vendors (Snowflake vs. Databricks, Databricks vs. Power BI, etc.), Ossie uses a hub-and-spoke model:
Snowflake
↕
dbt ↔ Ossie (Hub) ↔ Databricks
↕
Power BI
With 10 vendors, this requires only 20 converters instead of 90. More importantly, when a new vendor joins the architecture, you write 2 converters (import and export), not 18.
This means that each new participant (converter) adds a lot of value to the whole ecosystem.
Combining Databricks Metric Views & Power BI
At element61 we do a lot of Databricks, which means we build our semantics in Metric Views and make KPIs live there. But many of our Databricks customers also use Power BI, so the question is how Ossie would bridge the two. The Databricks converter translates between Ossie and Unity Catalog Metric Views as a pure YAML transformation, with no Databricks connection and no runtime dependencies, and it works in both directions.
The Microsoft converter does the same for Power BI and Fabric semantic models (TMSL or TMDL), and it takes the harder route. Instead of forcing DAX into generic SQL, it registers DAX as a supported dialect and stores things like row-level security rules and formatting in custom_extensions, so a model can round-trip without losing anything.
What I find most interesting is the combination. Metric Views speak SQL and Power BI speaks DAX, and one Ossie model can hold both. Define a KPI once, and your Databricks and Power BI teams work from the same definition.
Let's go?
The Future: from Semantic interoperability to Semantic governance
Semantic interoperability becomes possible
Vendor-neutral semantic layers separate the meaning of your data from the tools that read it. Swap your BI tool, change your warehouse or switching to a new AI agent, and your definitions come along. I think this is where the real value lies, because lock-in has never been about features, but about the fear of losing what you built. Once that dissapears, you can pick the best tool for each job instead of accepting whatever one vendor offers: Snowflake for the warehouse, Databricks for AI, dbt for transformation, Tableau for exploration. The semantic layer is what lets them behave like one system.
How does this change the AI landscape inside a company? Agents do hallucinate when definitions drift between tools, and a structured, versioned semantic layer gives them something firm to stand on. But it removes one major source of error, not all of them. Governance is where I think the biggest change sits. We govern code in Git and data with catalogs, yet definitions scattered across Tableau, Power BI, and dbt can't realistically be governed at all. A portable layer makes one version-controlled, auditable definition of "customer" possible, but someone still has to own this and settle the arguments.
What this means for you
Ossie opens a new opportunity without introducing new tools. It allows you to answer business questions with definitions you already trust, adopt a better warehouse or AI agent without rewriting your architecture, and keep your semantic knowledge out of any one vendor's hands. Every new metric strengthens the system, and every new integration reduces friction. The one thing to watch is whether the spec stays honest about complexity. The Power BI converter, which keeps DAX intact instead of flattening it into generic SQL, shows the right instinct.
How we can help you
- Map your semantics: we review where your KPIs are defined today (Metric Views, Power BI, other tools) and where those definitions differ.
- Prove it on your own data: we run a pilot where your key KPIs are defined once in Ossie and used in both Databricks and Power BI.
Reach out for more information.
References
- Apache Ossie GitHub
- Ossie Core Specification
- Ossie Converters
- Ossie Roadmap
- Snowflake: Apache Ossie (Incubating): The New Name for Open Semantic Interchange
- Join the Ossie Community
FAQ
We describe Apache Ossie as a vendor-neutral semantic model specification that makes business definitions portable across tools. It uses JSON or YAML to represent entities, relationships and metrics. Rather than tying semantic knowledge to one BI platform, it provides a shared format in which different tools can agree on what a model means.
We see semantic fragmentation when the same KPI is defined differently in Power BI, Tableau or Databricks. Teams then spend time reconciling definitions and building custom ETL to address inconsistencies. Apache Ossie addresses the semantic side of this problem by offering a common model specification, giving analytics tools a more consistent foundation for interpreting business metrics.
We distinguish a shared semantic specification from a universal execution language. Apache Ossie does not prescribe how a data warehouse operates or how metrics are computed. Instead, it describes business meaning in a common format. SQL and DAX can remain part of the model, rather than being forced into one generic calculation language.
We explain the architecture as a central semantic hub with import and export converters for participating tools. Apache Ossie avoids requiring separate point-to-point translations between every vendor pair. Each new participant adds its own connections to the hub, rather than separate connections to every other platform, making the converter architecture easier to extend.
In our Databricks work, we build semantics in Metric Views, while many customers also use Power BI. Apache Ossie provides a shared model that can hold SQL and DAX. The Databricks converter works with Unity Catalog Metric Views, while the Microsoft converter works with Power BI and Fabric semantic models in TMSL or TMDL.
We highlight that the Databricks converter translates in both directions between Apache Ossie and Unity Catalog Metric Views. The conversion is a pure YAML transformation, with no Databricks connection or runtime dependencies. This makes the converter a model translation mechanism, rather than something that needs a live Databricks environment to perform the transformation.
We highlight the Microsoft converter because it keeps DAX as a supported dialect instead of flattening it into generic SQL. In Apache Ossie, details such as row-level security rules and formatting are stored in custom_extensions. This approach is intended to preserve those model details during round-trip conversion between the shared specification and Power BI or Fabric.
We see a structured, versioned semantic layer as a way to reduce errors caused by drifting business definitions. Apache Ossie can give AI-driven analytics a more consistent semantic foundation, but it does not eliminate every source of hallucination. Governance still matters: someone must own the definitions and resolve disagreements about what business concepts mean. Contact element61 via element61.be to discuss your semantic definitions.
We see particular value for organisations whose KPI definitions span multiple analytics platforms, including Databricks and Power BI. Apache Ossie supports keeping semantic knowledge separate from any one vendor, so definitions can travel when tools change. We can help map where your definitions differ today. Reach out to element61 via element61.be for an initial discussion.
Our approach starts by reviewing where your KPIs are defined today, including Metric Views, Power BI and other tools, and identifying differences. We then run a pilot on your own data, defining key KPIs once in Apache Ossie and using them in Databricks and Power BI. Contact us to discuss your pilot.
