The procedure
From cycler export to citable dataset, five stages.
You bring a folder of instrument files. BattINFO walks them through five stages, each one checkable before the next. At the end you have validated records with permanent identifiers, a DOI you can put in a paper, and data the whole field can find and read.
raw files → BDF tables → Cell spec → Cell → Test → Dataset → JSON-LD → DOI + registry
python -m venv .venv
# until the 0.8 release lands on PyPI, install from source:
.venv/bin/pip install git+https://github.com/BIG-MAP/BattINFO.git- 1
Convert
pythonws.convert() # NEWARE / Biologic / Excel auto-detected ws.convert("*.csv") # or force generic CSV exportsYou get: bdf/*.bdf.csv — every cycler's export in one tidy, documented table format (BDF).
Why this stage exists: Instrument formats are the first interoperability wall. One canonical table format means every later step — and every colleague — reads the same thing.
- 2
Identify
pythonhits = ws.search("molicel p45b") # fuzzy; [] if no match spec = hits[0] if hits else battinfo.CellSpec( manufacturer="Molicel", model="INR21700-P45B", format="cylindrical", chemistry="Li-ion") ws.add("cell", spec=spec, serial_numbers=["S1", "S2", "S3"])You get: Cell records for the physical cells you tested, linked to a shared cell spec with a persistent IRI.
Why this stage exists: Your measurements are about specific physical cells. Naming them once gives every test and dataset an unambiguous subject — the start of the provenance chain.
- 3
Link
pythonws.add("test", type="cycling", cell="S1", data="bdf/S1.bdf.csv")You get: A test record tied to the cell, plus a dataset record pointing at the converted data file.
Why this stage exists: Data without its test conditions is trivia. The link cell → test → dataset is what makes the numbers reusable by someone who wasn't in the lab.
- 4
Save & validate
pythonws.save()You get: .battinfo/records/** — canonical JSON records, schema-validated, with deterministic w3id.org IRIs minted from each record's identity.
Why this stage exists: Validation runs before anything leaves your machine. Re-running the same save is a no-op — identical inputs always mint identical identifiers.
- 5
Publish
pythonws.publish(note="Cycling campaign, 2026") # add zenodo=True for a DOIYou get: A citable archive (Zenodo DOI) and records staged for the Battery Genome registry, where curators review and index them.
Why this stage exists: This is the payoff: a DOI reviewers can cite, machine-readable JSON-LD any tool can consume, and a record the whole field can find.
Before the DOI
Credit your co-authors, and pick a license.
A DOI is a citation, so the metadata your co-authors and reviewers care about goes on before you publish: every contributor by ORCID, and a data license (CC-BY-4.0 is the usual choice for open research data). These become the Zenodo record’s authors and license.
# credit every author by ORCID, once per workspace
ws.contributor("0000-0002-1825-0097", name="Ada Lovelace")
ws.contributor("0000-0001-5109-3700", name="Alan Turing")
# publish with a data license; the authors become the Zenodo creators
ws.zenodo(
license="cc-by-4.0",
creators=[
{"name": "Lovelace, Ada", "orcid": "0000-0002-1825-0097"},
{"name": "Turing, Alan", "orcid": "0000-0001-5109-3700"},
],
)The result is a citable dataset you can paste into a Data Availability statement: Lovelace, A., & Turing, A. (2026). [dataset title]. Zenodo. https://doi.org/10.5281/zenodo.XXXXX.
Before you publish
Check your record here, in the browser.
Paste any record into the validator to see exactly what the library and the registry will say about it, same schemas, same verdict. Or explore a finished example first to see where you are heading.
Go deeper
The full tutorial and reference live in the docs.
This page is the map. The step-by-step tutorial, with a sample dataset, validation output, and the Zenodo sandbox, plus the complete Python API, CLI, and schema reference, live in the developer documentation.