Summary - HackMD

# Summary ### Brief OME-NGFF status The specifications scheduled for v0.5 are near final call for comments and are already used by several communities. Outstanding comments on the PRs exist and should be revisited after testing in the wild and after initial merge. The timeline for conversion to Zarr v3 is unclear but would be accelerated by help from the community. Norman R agreed to help with conversion. Likely there are no significant changes with respect to metadata in NGFF. ### Metadata in NGFF The primary purpose of the meetings was to discuss how NGFF might deal with metadata. General There are different ideas of what NGFF should / could do with metadata in general. In short these range from having full freedom regarding metadata to having more constraints: 1. NGFF should only define where and how metadata is stored (e.g., "load file A/B/C which is in JSON".) For the rest, users should have full freedom. 2. NGFF comes up with a minimal model of metadata, however, what is minimal to one is not minimal to someone else. Getting consensus on this could prove challenging. 3. NGFF supports a single, unified metadata framework like [LinkML](https://linkml.io), but there was some discussion that this could be a parallel but related effort. - _**Potential Details**: Standards that are maintained by communities can choose from fields present in these models. If a field is not present this could be added by opening a PR. Fields have a IRI (international resource identifier) as key. Valid values are determined by a given metadata standard itself. Metatadata standards have a name and can be registered in a registry such as linkml registry. Parent, child system of metadata models was discussed in case people partially would use a metadata specification._ Some of these options could live next to one another, too. First priority for NGFF would be to have format and location. Point 3 could be interoperable with that and could possibly encourage consensus building. Format In general the community is in favor of moving away from xml to another format. There were no objections to linkml. People have volunteered for experimenting with the usage of linkml. Linkml could be used for schema authoring, provides loaders and dumpers and validation in several RDF related formats and formats often used by biologists (csv). Several people will be experimenting with this in https://github.com/ome/linkml-sandbox Location Opinions differ as to what the storage location of metadata should be. Multiple options have been discussed which are not neccesarily mutually exclusive: 1. Metadata in one file stored at a given location within Zarr. 2. Metadata stored at multiple locations within Zarr. Location depends on what kind of metadata. A possible issue was raised regarding the time it would take to parse metadata from all locations to find what you want. Concept of chunked metadata raised by Josh Moore in response. 3. Links to external metadata. An example here would be donor metadata in case imaging and sequencing was performed. Without links this would lead to metadata duplication. A need for the possibility of consolidation of metadata at the top level of the Zarr store was raised. At the same time the metadata specification should allow for subsetting data without metadata loss. Viewing configs Omero metadata is transitional, but only [issue 78](https://github.com/ome/ngff/issues/78) was closest to where someone has gotten for a specification. For location it was mentioned that it should not be near image data as this would be more difficult when having multiple volumes with different rendering settings. An alternative would be storing with image data, but with allowing multiple viewconfigs. ### Other matters of business Future meetings A need for more frequent meetings was raised to discuss current ongoing activities. Possibilities include more community meetings, spontaneous meeting in case of hot topic on github / image sc, or hybrid form of these.