Data federation, and why battery data needs it
Battery knowledge is scattered across datasheets, lab notebooks, cycler exports, suppliers, and regulators. Federation makes those sources interoperable without forcing them into one database. BattINFO is the backbone that makes it possible, and Battery Genome is that backbone in practice.
What it is
Don't move the data. Agree on how to describe and address it.
Data federation is an architecture for making many independent datasets behave like one. Instead of centralizing everything into a single store, federation keeps each dataset where it lives and adds a thin shared layer, a common vocabulary, persistent identifiers, and a common serialization, so the pieces can be linked and queried together.
Centralized
Copy everyone's data into one database under one schema. Breaks on ownership, scale, privacy, and the next format change. Whoever holds the database holds the power.
Federated
Data stays with its owner. A shared vocabulary, shared identifiers, and a shared serialization let independent sources interoperate and link, queried as if they were one graph.
The backbone
BattINFO supplies the three things federation depends on.
Federation only works if independent parties share a small, well-governed core. BattINFO standardises exactly that core, and nothing more, so data owners stay in control of everything else.
Shared meaning
Every property and unit maps to an EMMO domain-battery IRI, so “nominal capacity” means the same thing in a datasheet, a lab export, and a regulator's database, no per-source glossary required.
Shared identifiers
Cells, specs, tests, and datasets get persistent w3id.org/battinfo IRIs. A record in one repository can point at a record in another, and the link still resolves years later.
Shared serialization
Records publish as JSON-LD aligned to one context. Independently authored documents merge into a single RDF graph you can query, without anyone agreeing on a database schema first.
A publication backend, the BattINFO registry, mints those canonical identifiers and renders public, resolvable artifacts, so a record published by one group is addressable and linkable by everyone else. How identifiers work →
In practice
Battery Genome: federation, running.
Battery Genome is a working instance of this idea. It brings together cell specifications, instances, test protocols, and cycling datasets contributed from many sources, manufacturers, research labs, and public collections, and binds them with BattINFO.
Nothing is forced into a single proprietary schema. Each contribution is described with the shared vocabulary, gets a persistent IRI, and is published as Linked Data. The result is a growing, queryable graph of battery knowledge that no single organization owns, the “genome” assembled from independently held parts.
- 1
A lab describes a cell and its tests with BattINFO, in plain JSON.
- 2
Publishing mints persistent IRIs and emits EMMO-aligned JSON-LD.
- 3
The registry renders resolvable public artifacts for each resource.
- 4
Records from different contributors link by IRI into one graph.
- 5
Battery Genome queries across all of it, as if it were one dataset.
The same machinery you use to publish one record is what makes the whole federation cohere. Build on the shared backbone and your data is interoperable by construction, not by a future migration.
Join the federation.
Describe your battery data once with BattINFO and it links into the wider graph. Start with the docs, or convert a record in the browser.