Ontologies

Software versioning is solved. Ontology versioning isn’t. When you change what counts as an ‘active customer,’ that’s not a schema migration with a clear notion of correctness. It’s a contested definition where reasonable people can land in different places. Fabric IQ gives you the artifact, but it doesn’t ship the governance workflow. That part you build yourself. This post digs into what running layered ontologies actually takes, and why the organizational problem matters more than the technical one.

A sharp LinkedIn critique argues declared ontologies are broken by design. Model your business formally, and by the time you’re done, it’s already changed underneath you. The proposed fix: let structure emerge from data instead of declaring it upfront. It’s a compelling pitch, but I think it misdiagnoses the problem. Ontology drift isn’t evidence that formalization failed. It’s evidence we failed to separate what should be stable from what shouldn’t. The real answer might be simpler than either camp admits.

We’ve spent years encoding business knowledge into Power BI semantic models. What a customer is, what revenue means. The problem is that knowledge is locked in DAX, invisible to AI agents. Fabric IQ introduces ontologies as the fix, a layer that captures meaning in a form machines can reason against. But generating an ontology from your existing semantic model inherits all its limitations. The real question is whether organisations will do the hard work of agreeing on definitions.

For years I thought dimensional models were about organizing data and making queries fast. That’s true, but it’s profoundly incomplete. Dimensional models describe how we store facts. They don’t describe what those facts mean. That gap shows up the moment someone asks a question your star schema wasn’t designed for. Ontologies solve a different problem: formal, machine-readable definitions of business concepts and their relationships. With Microsoft now shipping Fabric IQ, this conversation isn’t academic anymore.