For many companies, Power BI is the linchpin when it comes to figures, facts and decisions. It is where the meaning of the data is described, where data is transformed and where its relationships are modelled. However, this information often remains isolated within the Microsoft universe. If you want to use agents to generate insights, you first have to go to considerable effort to make it available to them. Often, the semantics are rebuilt by hand.

So I wrote a small tool: https://github.com/s6nlbeck/tmdl2ossie. It reads a Power BI semantic model and converts it into the vendor-neutral format “Apache Ossie”. From there, it exports to Snowflake, Databricks, Cube and Honeydew.

The problem: every semantic layer speaks its own language

Semantic layers are everywhere at the moment. Snowflake has semantic models for Cortex Analyst, Databricks has Metric Views, and then there are Cube, Honeydew, dbt and others. At their core, they all describe the same things: tables, fields, relationships and metrics. And every platform uses its own format to do so.

This is particularly frustrating because AI agents need exactly these semantics to reduce hallucinations and give reliable answers about the data. Without them, they don’t know that “revenue” comes from the sales table and is linked to the region via the customer ID.

Apache Ossie as a common language

Apache Ossie is a vendor-neutral YAML format for exactly this kind of description. The idea is simple: translate into Ossie once, or model directly in Ossie, then export anywhere. A number of ready-made converters are already available for exporting.

The catch: for many companies, Power BI is the semantic tool. Maintaining the semantics twice is no solution. Unfortunately, neither is retiring Power BI. Data analysts know and value their Power BI, and switching involves a great deal of effort.

Since Power BI doesn’t export Ossie itself, I needed a solution that keeps Power BI in use but ensures the semantics don’t have to be laboriously rebuilt. My goal: the semantics are maintained in Power BI and can also be used in Snowflake and the like with little effort.

What it looks like

The interface is a small web app with four tabs: upload a Power BI project as a ZIP file, review and edit the translated semantics, view the data model as a graph, and export for the target platform. Everything runs locally; no connection to Power BI or a data warehouse is required.

Under the bonnet

My tool uses the TMDL files that Power BI creates when you save a model as a project (.pbip). In the first step, a purpose-built TMDL parser reads this proprietary Microsoft format – pure Python, no dependencies.

The objects from the TMDL files are then mapped to Ossie semantics. The whole process is static and deterministic: the same model always produces the same result.

The Ossie model can then be processed further using one of the ready-made converters. I have integrated the ones for Snowflake, Cube and Honeydew directly into my project. The Databricks converter, unfortunately, is written in Java. So that the tool can do without Java, I ported it to Python. The original’s tests also run against the port, and the output is identical to that of the Java converter.

Limitations

So far, the tool has been tested with a small sample model and the converters’ test suites, not with large production models. The main open issue is translating DAX into SQL. DAX measures are carried over, but SQL-based targets such as Snowflake or Databricks skip them. The obvious solution would be an AI agent that translates DAX into SQL – but that would sacrifice determinism.

If you have a larger model and give it a try, I’d be glad to hear your feedback and see issues on GitHub.

Licence

tmdl2ossie is free for private use, research, teaching and non-profit organisations (PolyForm Noncommercial 1.0.0). A commercial licence is available for use in companies; please send enquiries to mail(at)nils-becker.org.