Describe the issue
I want to raise my concerns regarding the connectedness constraint of 0.6-dev4, quoted below. I will bring a series of arguments for relaxing it.
Graph connectedness: The coordinate systems defined in the multiscales metadata and the scene metadata combined with the coordinate transformations form a transformations graph. In this graph, coordinate systems represent nodes and coordinate transformations represent edges. The graph MUST be fully connected in the sense that any two coordinate systems in the metadata MUST be connected by a sequence of edges represented by coordinate transformations. Coordinate systems that are connected by a non-invertible transformation count as connected in this sense, even though graph traversal may not be closed-form computable in every direction.
Connectedness doesn't imply applicability of transformations -> so why is connectedness useful?
Consider the following example. We are aware that connectedness of the undirected transformation graph does not imply that each element can be transformed into any other element in each coordinate system.
In the example above we can still visualize sample1 and sample2 together in the scene coordinate system, but it's easy to construct even an example in which there are images belonging to the same connected scene graph that cannot be visualized together in any coordinate system (i.e. the two scale0 images below).
Therefore I don't find the connectedness constraint useful in practice.
It's a metadata constraint that forces on-disk layout changes
Assume I have 4 samples. Each sample has a number of cells and I want to use them all together for some analysis (for instance featurize the images into a big table). Ideally I have a single Zarr group with the 4 image groups inside. Once I proceed to feature extraction, I don't really need if some samples can be visualized together, I just need some metadata in a table column to keep track of what belongs to what (for instance in case I want to split later the cells into train/val/test). But the connectedness constraint for the scene means that I cannot position all the images into a single folder. I must have 2 scenes, and therefore 2 different subfolders.
In other words I cannot have the following on-disk
and I must rely to something like this
I don't think that a constraint on the metadata should have implications on the on-disk layout. There already examples of initiatives in which one tries to limit on-disk layout changes, for example in OMERO the hierarchy of the data is limited to 2 levels so that one is encouraged using tags to encode nested hierarchies (e.g. patient -> condition -> fov -> sample) instead of having to switch the on-disk layout.
Checking for connectedness makes validation more complex because you need to build the graph
In order to check for connectedness, low-level validation libraries such as ome-zarr-models-py need to be able to construct and validate the graph, either promoting the use of additional dependencies or adding maintenance burden for custom implementations for graphs exploration.
A local change of transformation can invalidate a whole group
This is a tricky one: imagine I have a Zarr group with 100 samples, each belonging to a different coordinate system. As long as I have no scene the data is valid! as nobody forces me to add a scene. But imagine that now I add a 101th sample, and this sample actually shares the same coordinate system with the 100th sample. Now if I add a scene with a transformation between the coordinate system of the 100th sample and the 101th sample, suddenly I obtain that the scene makes the whole group invalid. This is caused by the fact that the transformation graph of the whole Zarr group contains the coordinate system 1-99, which are not included in the Scene. So a local property (the fact that the 100th and 101th samples can be visualized together) have the implication that the whole group becomes invalid.
Connectedness as a way to ensure Scene validity encourages mixing the concept of Transformations and Collections
The rationale of asking for connectedness for the Scene is implicitly telling that a Scene is not just a set of coordinate systems/transformations (that refer to elements outside an image and so had to be stored somewhere else), but is a set of coordinate systems/transformations that make sense together. I believe that this extra semantic goes beyond the scope of RFC-5 and falls into the realm of Collections.
Describe the issue
I want to raise my concerns regarding the connectedness constraint of 0.6-dev4, quoted below. I will bring a series of arguments for relaxing it.
Connectedness doesn't imply applicability of transformations -> so why is connectedness useful?
Consider the following example. We are aware that connectedness of the undirected transformation graph does not imply that each element can be transformed into any other element in each coordinate system.
In the example above we can still visualize
sample1andsample2together in thescenecoordinate system, but it's easy to construct even an example in which there are images belonging to the same connected scene graph that cannot be visualized together in any coordinate system (i.e. the two scale0 images below).Therefore I don't find the connectedness constraint useful in practice.
It's a metadata constraint that forces on-disk layout changes
Assume I have 4 samples. Each sample has a number of cells and I want to use them all together for some analysis (for instance featurize the images into a big table). Ideally I have a single Zarr group with the 4 image groups inside. Once I proceed to feature extraction, I don't really need if some samples can be visualized together, I just need some metadata in a table column to keep track of what belongs to what (for instance in case I want to split later the cells into train/val/test). But the connectedness constraint for the scene means that I cannot position all the images into a single folder. I must have 2 scenes, and therefore 2 different subfolders.
In other words I cannot have the following on-disk
Checking for connectedness makes validation more complex because you need to build the graph
In order to check for connectedness, low-level validation libraries such as
ome-zarr-models-pyneed to be able to construct and validate the graph, either promoting the use of additional dependencies or adding maintenance burden for custom implementations for graphs exploration.A local change of transformation can invalidate a whole group
This is a tricky one: imagine I have a Zarr group with 100 samples, each belonging to a different coordinate system. As long as I have no scene the data is valid! as nobody forces me to add a scene. But imagine that now I add a 101th sample, and this sample actually shares the same coordinate system with the 100th sample. Now if I add a scene with a transformation between the coordinate system of the 100th sample and the 101th sample, suddenly I obtain that the scene makes the whole group invalid. This is caused by the fact that the transformation graph of the whole Zarr group contains the coordinate system 1-99, which are not included in the Scene. So a local property (the fact that the 100th and 101th samples can be visualized together) have the implication that the whole group becomes invalid.
Connectedness as a way to ensure Scene validity encourages mixing the concept of Transformations and Collections
The rationale of asking for connectedness for the Scene is implicitly telling that a Scene is not just a set of coordinate systems/transformations (that refer to elements outside an image and so had to be stored somewhere else), but is a set of coordinate systems/transformations that make sense together. I believe that this extra semantic goes beyond the scope of RFC-5 and falls into the realm of Collections.