Proposal: Add UUID field to multiscale objects

[joshmoore]

In order to uniquely identify the images that are being generated,
this change proposes that a UUID should be included with each multiscale.
The UUID can either be generated at creation or perhaps copied from
an existing array if all meta(data) is identical (e.g. a rechunking).

[joshmoore]

To view: http://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/joshmoore/ngff/uuid/latest/index.bs

[will-moore]

"In order to uniquely identify the images that are being generated" from the PR - It may be obvious, but maybe that (or something similar) should be included in the spec.
How is this likely to happen? Not via any JSON schema id or ref, but simply by some user's code or unstructured csv/file/DB/notes ?

[joshmoore]

Pushed.

How is this likely to happen? Not via any JSON schema id or ref, but simply by some user's code or unstructured csv/file/DB/notes ?

How do you mean, @will-moore?

[will-moore]

Where will I use the UUID?
E.g. In a description of another NGFF Image This image was processed from Image "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" or in a JSON collection: [{"id": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"}, ...] or is it just not known just now, but it seems like it could be useful in the future?

[sbesson]

On the feature itself, I am also in favor or introducing some semantics allowing to identify of these objects. I can imagine several use cases as these objects are made available on object stored and potentially replicated in many places to allow some form of integrity check.

A secondary proposal included this PR is the refactoring the definition of the multiscales dictionary to use a bullet-point list with clear MAY/SHOULD/MUST mapping - see http://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/joshmoore/ngff/uuid/latest/index.bs#multiscale-md.
The current plate specification uses an vairant with a list of definitions e.g. as in https://ngff.openmicroscopy.org/latest/#plate-md. However, this currently lacks a clear expression requirement level and I have on my todo to review this paragraph.
I do not have a strong preference on one style vs the other (bullet point vs definition list) but I think it would make sense to unify. Adding a bit to the complexity, some of the keys include are themselves dictionaries and the specification needs to define sub-keys. I assume the advantage of the current proposal is that this would be simply represented as indented bullet points

[melonora]

I would like to present a use case here with regards to view configurations:

I have some work on view configurations that allow reproducing the view across a visualization ecosystem. Below an example of defining in this case SpatialData in that config.

Without having UUIDs I see some operations as impossible. Starting with the case that is possible without UUIDs

1. I locally have my viewconfigs at the root of the zarr store. Now I deposit the data in a database so the url has changed. In this case, you would not need a UUID as the config is contained in the zarr store and you can just update the path in the config.

Now 2 cases that I think are not possible without UUIDs:

1. I have viewconfigs outside the zarr store. I move the zarr store locally. The URL is not valid anymore. In case of a UUID in the top-level zarr.json I could still just match the viewconfig to the zarr store by having an api that takes in a viewconfig and a list of zarr containes that have the UUID. After a match update the URL.

2. Same case as 1 but then instead of moving the zarr store locally, deposit it in a database.

This is my specific case at the moment, but I think there are many other cases where this could be useful.