NGM Users
One clear outcome of the discussions that happened in the OME 2026 meetings (particularly the OME hackathon) is that more people and groups are interested in the “NGM framework” than just Caterina’s group and the Imaging-PHD project.
We can count at least 5 potential “users” (or “clients”) of the NGMF project:
- the Imaging-PHD project (Caterina Strambio) – obviously that one will be a confirmed user, not merely a potential one;
- Katy Wolstencroft and Tooba Abbassi-Daloii from NL-Bioimaging / Amsterdam UMC;
- Volume EM metadata (Alexandra Zakieva, EMBL);
- Cell tracking metadata (Justin Sonneck, Leibniz-Institut für Analytische Wissenschaften - ISAS - e.V.);
- Analysis metadata (Dave Bunten, University of Colorado).
Components
Based on the multiplicity of users and the fact that NGMF is not supposed to be restricted to the context of OME-Zarr, I envision splitting the projects in “2+n” components as follows:
(1) NGMF itself (or “NGMF-core”)
Roughly, a way to design and write extensible metadata schemas, with
- particular emphasis on the use of LinkML (though LinkML-independent alternative ways might be supported)
- support for different “backends” (where and how the metadata are to be serialised), such as
- OME-Zarr (see (2) below),
- RO-Crate,
- OME annotations (for embedding NGMF metadata into “legacy” OME-Tiff files),
- possibly others.
That component may also be further split as needed, and may also include (probably should include) the work on developing the software libraries aimed at supporting the use of NGMF (e.g. the work on LinkML-Java can be considered part of that).
(2) A NGMF “container” in OME-Zarr
This would take the form of a OME-Zarr RFC describing where and how NGMF metadata are to be written into a zarr.json file.
(n) NGMF metadata “modules”
One separate module for each type of “client/user” of NGMF, e.g.
- one “Imaging-PHD” module;
- one “Volume EM” module;
- one “Cell Tracking” module;
- etc.
At least some of those modules (at the very least the Imaging-PHD one) would be made by “us”, but ultimately anyone interested in the extensibility and interoperability promises of NGMF could create their own module (or extend an existing module).
Governance
Should the work on NGMF be part of a “OME Registered Project” (ORP)? If so, which one?
Options include:
(A) Not creating a dedicated ORP, but instead attaching NGMF to one or several existing ORPs (e.g. the “data model” ORP for the work on the NGMF model and the “OME-Zarr” ORP for the work on defining the “NGMF-in-OME-Zarr container” RFC).
(B) A dedicated ORP specifically for NGMF.
(C) A “metadata” ORP dedicated to more than just NGMF, of which NGMF would be a part.
No strong opinions here for the time being. Part of the answer will likely depend on the wishes of the OME Management Group about ORPs (e.g. do they prefer a small number of “large” ORPs or are they fine with several more focused ORPs?).
Of note, Alexandra Zakieva already took the initiative of kickstarting a “REMBI ORP”: https://docs.google.com/document/d/1dW8amAL51PDzpvkgWDsda5wZ6h9s-IwZaff6B8EO3KE/edit?usp=drivesdk
NGM Users
One clear outcome of the discussions that happened in the OME 2026 meetings (particularly the OME hackathon) is that more people and groups are interested in the “NGM framework” than just Caterina’s group and the Imaging-PHD project.
We can count at least 5 potential “users” (or “clients”) of the NGMF project:
Components
Based on the multiplicity of users and the fact that NGMF is not supposed to be restricted to the context of OME-Zarr, I envision splitting the projects in “2+n” components as follows:
(1) NGMF itself (or “NGMF-core”)
Roughly, a way to design and write extensible metadata schemas, with
That component may also be further split as needed, and may also include (probably should include) the work on developing the software libraries aimed at supporting the use of NGMF (e.g. the work on LinkML-Java can be considered part of that).
(2) A NGMF “container” in OME-Zarr
This would take the form of a OME-Zarr RFC describing where and how NGMF metadata are to be written into a
zarr.jsonfile.(n) NGMF metadata “modules”
One separate module for each type of “client/user” of NGMF, e.g.
At least some of those modules (at the very least the Imaging-PHD one) would be made by “us”, but ultimately anyone interested in the extensibility and interoperability promises of NGMF could create their own module (or extend an existing module).
Governance
Should the work on NGMF be part of a “OME Registered Project” (ORP)? If so, which one?
Options include:
(A) Not creating a dedicated ORP, but instead attaching NGMF to one or several existing ORPs (e.g. the “data model” ORP for the work on the NGMF model and the “OME-Zarr” ORP for the work on defining the “NGMF-in-OME-Zarr container” RFC).
(B) A dedicated ORP specifically for NGMF.
(C) A “metadata” ORP dedicated to more than just NGMF, of which NGMF would be a part.
No strong opinions here for the time being. Part of the answer will likely depend on the wishes of the OME Management Group about ORPs (e.g. do they prefer a small number of “large” ORPs or are they fine with several more focused ORPs?).
Of note, Alexandra Zakieva already took the initiative of kickstarting a “REMBI ORP”: https://docs.google.com/document/d/1dW8amAL51PDzpvkgWDsda5wZ6h9s-IwZaff6B8EO3KE/edit?usp=drivesdk