Draft of MICrate as profile for storing extensible metadata alongside the OME-Zarr images

[sukunis]

follow up on RO-Crate metadata minimal design

First DRAFT for a RO-Crate profile defining a detached RO-Crate.

Things to discuss:

1. Agreeing on MUST, SHOULD, COULD for properties
2. context extensions and their mapping
3. design decision in terms of specimen: is specimen a property of the root data entity:
   

or of entity for acquisition_mode:

[joshmoore]

Few thoughts:

1. Agreeing on MUST, SHOULD, COULD for properties

Outside the challenge I could see specimen not being a MUST.

2. context extensions and their mapping

i.e. how do other people add in the extensions? Is there any way to do this at a higher-level of abstraction rather than on a field-by-field basis? I'm thinking of how to allow in an entire block of community metadata specified externally.

a detached RO-Crate.

So what makes this detached is the fact that the about @id and the Dataset @id point to a remote URL, right?

[sukunis]

So what makes this detached is the fact that the about @id and the Dataset @id point to a remote URL, right?

Key points detached ro-crate:

• without defined root directory,
• not processed in a file-system context
• referenced data entities are web-based
• naming: ${prefix}-ro-crate-metadata.json

https://www.researchobject.org/ro-crate/specification/1.2-DRAFT/structure.html#detached-ro-crate-package

[sukunis]

comments on that from @JensWendt (see issue#3)