example with rembi module

[Tom-TBT]

Here's an example I made. I was wondering from the example min-specimen-biosample.json if we shouldn't group metadata within REMBI blocks.

My example is a mess, and I'm not sure what type should be for these REMBI blocks. For the Specimen, I chose for type "Whole organism" from a Drosophila ontology. (the ontobee link is broken, but here's from the OLS)

• the specimen is linked to a biosample
• the image acquisition is linked to a specimen
• the channels are listed from a specimen

Screenshot from https://json-ld.org/playground/

[Tom-TBT]

@sherwoodf

[sherwoodf]

Thanks Tom!

I'm not sure what type should be for these REMBI blocks. Agreed: REMBI being metadata guidance, rather than something defined in linked data terms, makes referencing it's concepts a little awkward.

I didn't precisely go with the REMBI structure due to our experience with BIA submissions. As a quick overview, REMBI, as you've done in your example, links:

• Image -> Image Acquisition (unique up to the settings used and what was in the field of view of that particular image)
• Image Acquisition -> Specimen (unique up to what & how a biological entity was prepared for imaging)
• Specimen -> Biosample (unique up to the physical thing that was grown, dissected, etc).

We've found that most submitters to the BIA think more about protocols that the individual instances of events and samples that formed the image, so have gone with a graph that looks more like:

• Image -> Image Acquisition (unique up to the settings used / protocol followed for imaging)
• Image -> Specimen (unique up to what & how a biological entity was prepared for imaging)
• Specimen -> Biosample (unique up to the physical thing that was grown, dissected, etc).
• Specimen -> SpecimenPreparationProtocol (unique up to protocol followed).

This is influenced by the BIA's user interface, as well as us dealing with large datasets of images, both of which point users towards thinking about protocols they can re-use (whereas with the REMBI model performing the same acquisition protocol on different specimens would require 2 different Image Acquisitions). Since storing metadata with the zarr is more focused at the image level, these considerations probably don't hold as much as with large datasets that the BIA users are used to. The objects are relatively easy to draw parallels / transform between the two.

[joshmoore]

Not sure when/if @Tom-TBT is on holidays, but I'd be for us getting any final changes here pushed and then merging.

Do we additionally want to provide any command-line options for these fields?

[Tom-TBT]

I am here. My feeling is that https://github.com/ome/ome2024-ngff-challenge/blob/main/dev3/zarr-crate/example_usage/example_ro_crate/ro-crate-metadata.json is a much more comprehensive example now. I would rather close this PR

[joshmoore]

Sounds good. Can always be resurrected if needed.