Semantic Link Labs, a Python library for Microsoft Fabric notebooks

A companion library for the parts of Semantic Link that are awkward

Semantic Link Labs is described as a Python library designed for use in Microsoft Fabric notebooks, and it extends the capabilities of Semantic Link with additional functionalities to work alongside it.

The stated goal is to simplify technical processes, empowering people to focus on higher level activities and allowing tasks that are better suited for machines to be handled without human intervention. That is a useful framing, because Semantic Link itself is a thin, elegant API for reading a semantic model from a notebook, and the operations that practitioners actually need, such as migrating a model, checking guardrails or generating measure descriptions, sit one level below it.

The intended audience is therefore narrow and clear: data engineers and BI practitioners working inside Fabric notebooks, using Python, who need to do more than read a model. The repository topics match that reading, with analysis-services, analysis-services-tabular, dax, jupyter-notebook, microsoftfabric, powerbi and python.

There is also a governance dimension, because Semantic Link itself is the link to a Semantic Link model, and the other half of the picture is the linguistic schema, the power BI semantic model and its artifacts. The labs library is the place where that vocabulary gets exercised in code.

Direct Lake migration is the headline scenario

The first featured scenario is the one that decides whether you need this library at all: migrating an import or DirectQuery semantic model to Direct Lake. Around it sit the operations that make a migration survivable.

There is a function to check why a Direct Lake semantic model would fall back to DirectQuery, and another to check Direct Lake guardrails. There is one to update the connection of a Direct Lake semantic model and one to dynamically generate a Direct Lake semantic model from scratch.

Then there is a set of cache operations, which is where the library earns its keep in practice. You can warm the cache of a Direct Lake semantic model after a refresh using the columns currently in memory, or warm it via a perspective, and there is a separate clear cache function. There is also a notebook for visualising a refresh, and another for Query Scale Out management.

Two more entries are worth naming because they are the kind of analysis that is painful to build from scratch. The measure dependency tree shows what depends on what inside a model, and get_dax_query_dependencies lists the unique columns touched by a single DAX query or by several of them. There is a notebook for analysing delta tables for Direct Lake semantic models using Delta Analyzer.

The Tabular Object Model wrapper and the metadata translation

The TomWrapper class is a separate documentation module in its own right, and it is the part of the library that sits closest to the underlying Analysis Services object model.

Through it you can add, update and view an incremental refresh policy, which is a configuration task that is otherwise fiddly to do by hand in the XML of a model. There is also a way to translate a semantic model's metadata, and a way to create a .vpax file, the package format used to move a model between workspaces.

The wider lifecycle operations live in the main sempy_labs module. There is refresh, backup, restore, copy backup files, and move or deploy a semantic model across workspaces, which is deploy_semantic_model. There is a clear cache function and a measure dependency tree.

There is also a linguistic schema angle. You can view the synonyms from the linguistic schema, and you can list them from the linguistic metadata, and there is a feature for auto-generating descriptions for any or all measures in bulk. That last one is the clearest example of the library's stated purpose: work that a person would do by hand in the Power BI interface, done in a loop instead.

Best practice analyzers, DAX impersonation and report metadata

The Reports section of the featured scenarios runs parallel to the semantic model one. There is a Report Best Practice Analyzer, alongside a Model Best Practice Analyzer for models and a Vertipaq Analyzer for the storage engine. There is a way to view report metadata and a way to see the semantic model objects most frequently used in Power BI reports.

The model side has the same analyzer trio: the Model Best Practice Analyzer, the Vertipaq Analyzer, and the semantic model metadata translation, all linked from the code examples in the wiki.

Two functions stand apart from the rest. evaluate_dax_impersonation runs DAX queries which impersonate a user, which is the only way to check what a specific identity would actually see in a model. And get_lakehouse_tables, documented in the lakehouse module, is what the Direct Lake guardrail check is built on.

The dependency choices in the manifest are worth a look, because they explain some of the capabilities:

dependencies = [
    "semantic-link-sempy>=0.14.2",
    "anytree",
    "polib",
    "jsonpath_ng",
    "anywidget",
    "sqlglot",
]

sqlglot is a SQL parser and transpiler, and it is how the library reads and rewrites DAX-adjacent expressions and measures. anytree provides the tree structures that the dependency tree and the model hierarchies are built on. polib handles translation files, jsonpath_ng handles metadata queries, anywidget provides the interactive widget support in Jupyter, and semantic-link-sempy, the Semantic Link package itself, is a required dependency at 0.14.2 or newer.

An alpha library with a moving API and a documentation-first workflow

The package metadata says Development Status :: 3 - Alpha, and that single classifier is the most important fact for anyone planning to depend on this library.

The version constraint is also specific: requires-python is >=3.10,<3.14, so Python 3.10 through 3.13 are supported and 3.14 is excluded. The intended audiences are listed as Developers, Education and Science/Research, and the Framework classifier is Jupyter.

Because it is an early access library, the documentation is the contract, not the type hints. The README points to the Read the Docs site at semantic-link-labs.readthedocs.io for the stable documentation, to a GitHub wiki for code examples, and to a video introducing Semantic Link, Semantic Link Labs and demos of the key features.

The README is also explicit about the feedback loop. Bugs go to a GitHub issue with a bug report template, feature ideas go to a feature request template, and there is a specific instruction for anyone who wants a Labs capability to move into Semantic Link itself: submit a vote in the discussions. The link points at a specific discussion thread, which tells you this is an active upstreaming process rather than a rhetorical invitation.

The release record shows regular work, with 0.16.0 on 2026-07-21, 0.17.0 on 2026-07-28 and 0.17.1 on 2026-09-10, and the last push on 2026-10-19. The licence is MIT, with the file in the repository root. The repository also carries the usual governance files, with AGENTS.md, CLAUDE.md, CODE_OF_CONDUCT.md, SECURITY.md and SUPPORT.md, plus an environment.yml, a notebooks directory and a tests directory.

Editorial conclusion

Adopt Semantic Link Labs if you build and operate semantic models inside Microsoft Fabric notebooks and want the Direct Lake migration path, the Tabular Object Model wrapper and the DAX dependency tooling in one library instead of a pile of scripts. Do not adopt it as a stable production dependency without pinning, because the package metadata marks it as alpha, and expect to read the docs rather than guess, since the API surface changes between releases. Before you build on it, read the Read the Docs pages for the specific module you need, check that your Fabric environment is one of the supported scenarios, and note the release picture, where 0.17.1 shipped on 2026-09-10 and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/semantic-link-labs on GitHub
4. README
5. Releases