Author, license, project description, and other free text metadata

[jni]

I am writing an image for which I wanted to include a dataset description (free text), a license, authorship, and author contributions. I expected that this would go in the "omero" transitional field, and through previous links and issues (#155 (comment)), found this page:

https://ngff.openmicroscopy.org/latest/#omero-md

which links to this example JSON:

https://docs.openmicroscopy.org/omero/5.6.1/developers/Web/WebGateway.html#imgdata

which includes projectDescription and imageAuthor fields. Problem solved, right? Except in #155 @will-moore links to the "omero" schema:

ngff/0.4/schemas/image.schema

Line 53 in 642a7a1

"omero": {

and "meta" isn't in it at all.

Since omero is transitional, could the "meta" dict be added to the schema as optional? Having free text allows data writers to at least keep all their metadata together with their image, even if unstructured.

Certainly happy to entertain other options. 😊 Could I instead add another entry to the top-level dict (sibling to "omero") without invalidating readers?

Thank you!

[will-moore]

I don't think there's been any previous spec discussions about where to store metadata such as description, license, authorship and author contributions.
I wouldn't suggest using the omero block as that's really just for channels and rendering settings.
There must be plenty of existing conventions / schemas / ontologies for these kind of fields, so we don't reinvent the wheel, but I'm not familiar with this area.

There's some initial discussion about where to store custom data at #68 (to use while you wait for spec changes) but that also needs some more attention.

[jni]

Thanks for the link. For free text, I'm really only looking for something that won't break existing implementations. I know how long finding a proper specification can take! 😅 Is there a chance we could define a field "custom" that is a freeform dictionary, with no compatibility guarantees? e.g. the napari "metadata" field in a layer is totally custom and has seen some good use in the community — which can then become something more formal.

[joshmoore]

Oooh, fun question. In no particular order:

• The OME-XML does define some of these fields (Yes, yes. I hear you cringing across both the Atlantic and the Pacific) ome-types can make this more palatable though. 😄
• I'm partially tempted to say let's define a "napari" field. It would keep "omero" from being singular and provide some namespacing for what you're looking to do. More
• More general, though, would be a Dublin Core / Data Cite / or similar location.
• (But really, I wanna just say "JSON-LD")

[will-moore]

In the short term I would start by picking a keyword, eg. custom or one of the other suggestions at #68 and just start using it. Also add a comment on that issue to say what you've picked so that at least others know what you're doing and may be encouraged to pick the same - it could even be chosen to become part of the spec in the longer term. I'm not sure that "napari" is a good choice since the data you want to store isn't specific to napari (just like "omero" wasn't a good choice for rendering info as it discourages others to use it).

It would even be good to know what terms you're using within your "custom" block for author etc, since that would make a start for adding those terms to the spec too.

Much longer term "JSON-LD".

[jni]

@joshmoore I'm actually in Mallorca right now so it's just the Mediterranean between us — that's probably why you could hear it. 😂

Anyway, I actually didn't cringe about OME-XML but at a "napari" field. 😂 OME-XML at least is a long-running standard. napari is one app and anyway it wouldn't use these fields — these are just for my own information because I feel like I should include this sort of information in the image itself.

Happy to stay out of "omero" and use "custom". Thanks @will-moore!

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/saving-volumetric-data-with-voxel-size-colormap-annotations/85537/1

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/saving-volumetric-data-with-voxel-size-colormap-annotations/85537/10

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/saving-volumetric-data-with-voxel-size-colormap-annotations/85537/11