This summary is produced by the author, and not by AI.
There were many announcements last week at FabCon Barcelona. Overall, there was one clear theme: semantic models are as important as ever and have more use cases than ever before.
Additionally, Microsoft has shown a clear and continued commitment to supporting AI agents for Power BI report development, Fabric App development, and semantic modeling. Expect this to continue into the future.
In their announcement blog post, Microsoft positions Fabric Apps as the next generation of report development. Natural language development of Fabric Apps is coming to Power BI Desktop. Power BI Pro and PPU licenses will cover Fabric Apps, along with Fabric SQL DBs. These changes make it clear that Microsoft sees Fabric Apps as a supplement for Power BI reports. The introduction of SQL DBs also opens up the capacity for more app-like development in the future too.
In addition to eventually being able to make Fabric Apps in Power BI Desktop, they have made it easier to build them in the GitHub Copilot App.
We’ve written before about Fabric Apps and how they work. They provide a lot of opportunities but also many new challenges. Put one way, the ceiling of what you can do is rising but the floor of what you get out of the box is lowering. One benefit of this change will be increased use and focus on semantic models, as well as less report-specific logic in semantic models.
Additionally, you now have to do less work in JavaScript for your DAX queries. Specifically, there is now support for direct connectors to semantic models as well as various SQL sources in Fabric. This makes it much easier to take advantage of the logic in your existing semantic model.
Despite this news, adoption is not going to be quick or easy. Fabric Apps require more data literacy and more AI literacy. Without that, it’s incredibly easy to produce reports that are not up to the same standards of what you might produce in Power BI.
At FabCon Barcelona, Microsoft confirmed its commitment to Apache Ossie, working with Snowflake on converting semantic layers between the two platforms. Microsoft also said it wants to establish DAX as an Ossie-recognized query language, and to expand Ossie’s support for ontologies.
Apache Ossie, formerly the Open Semantic Interchange, is an industry movement to standardize semantic modeling in a vendor-neutral way. In theory, this allows for more data model portability. It also should mean better support for agents that need to understand the meaning behind data sources and measures or metrics. However, if you have ever had to migrate from one reporting system to another, you know how complicated this is.
Ossie defines a semantic model in YAML or JSON files: datasets (their term for tables), fields, relationships and metrics (their term for measures). If you’ve ever worked with Power BI Projects (PBIP), this should sound familiar, because TMDL also describes tables, columns, relationships and measures as plain text files. The big difference is the language metrics are written in. Ossie was originally focused around SQL and SQL providers, so a metric’s expression is often written in a SQL dialect (such as Snowflake SQL or BigQuery SQL, or in Ossie’s own portable SQL).
A strict focus on SQL would have been a problem for Power BI, because DAX and SQL have no clean mapping. For example, a percent of total takes one line of DAX:
Sales % of All Products :=
DIVIDE (
[Sales],
CALCULATE (
[Sales],
REMOVEFILTERS ( 'Product' )
)
)
The measure ignores the product filter and keeps every other filter, in any query. A single SQL expression cannot do the same, because the SQL depends on which columns each query groups by.
Given this, it’s not surprising that Microsoft was not a part of the initial announcement for Ossie in September 2025. Later, in December 2025, MDX and Tableau were added as non-SQL dialects. Now that Microsoft has joined, Apache Ossie has added DAX as a supported language in the Ossie specification. A metric can be defined as a DAX expression, a SQL expression, or both.
Microsoft has also added a two-way converter between Power BI/Fabric semantic models and Ossie models. The converter keeps each expression in the language it was written in. The only SQL metrics that it translates to DAX are very simple ones: a single aggregate, such as SUM or COUNT, over one column.
While we don’t have many details yet, Microsoft has teased semantic views coming to Fabric lakehouses. Below is a teaser image of semantic views from the announcement blog. Based on the image, it looks like this will be stored in the Ossie format as YAML files.
This is exciting because it means it’s possible to define the business logic much closer to the source data. This makes it easier to review the business logic in the context of the source data and keep everything managed together.
Ontologies are an item in Fabric IQ that aims to represent the business as a whole, ideally at a level that spans across individual semantic models. Now it is possible to define ontologies based on multiple semantic models instead of one. It is also possible to define metrics in an ontology based on DAX measures. Both features are currently in preview.
This shows an increased emphasis on the semantic model and DAX as one place where you can define meaning within your business and provide it to your AI agents.
We have argued before that if you are using the PBIX format, you should consider using PBIP and source control instead. This is doubly so if you are doing anything at all with AI agents, where source control can provide a safety net for unexpected changes. With PBIP formats going GA, you absolutely should start using these formats today.
This is good timing, because Microsoft’s official agentic experiences for Power BI are GA as well. Agents are much safer to use with source control and PBIP. The agentic experiences include the Power BI authoring skills, Power BI authoring MCP, and Power BI Desktop Bridge.
If you prefer to edit your models in Tabular Editor 3, then good news, our latest release had a number of agentic improvements as well. This means that Power BI developers have many options available and can pick and choose. For example, you could make model changes with the Tabular Editor Assistant and then use Microsoft’s report authoring skills for the report layer.
FabCon showed Microsoft’s emphasis on semantic models, agentic development, and the PBIP format. Semantic modeling remains a rich and vibrant area in the Microsoft ecosystem.
Take your semantic models further with Tabular Editor.
Give Tabular Editor a spin