From cc0d6387a2e2325aae512edd9672ef6472c0d2e2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Besson?= <seb.besson@gmail.com>
Date: Wed, 2 Feb 2022 14:04:32 +0000
Subject: [PATCH] chore(rebuild): Merge pull request #87 from
 will-moore/v0.4_schemas

Add 0.4 schemas and examples

SHA: 430a9ae7894f4427e823408a3bd3bbf149f0d578
Reason: push, by @sbesson

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
---
 0.1/index.html    |   4 +-
 0.2/index.html    |   4 +-
 0.3/index.html    |   4 +-
 latest/index.html | 244 ++++++++++++++++++++++++++++++++++++++--------
 4 files changed, 207 insertions(+), 49 deletions(-)

diff --git a/0.1/index.html b/0.1/index.html
index b0686c71..49032518 100644
--- a/0.1/index.html
+++ b/0.1/index.html
@@ -1489,7 +1489,7 @@
 </style>
   <meta content="Bikeshed version 2e3c4c68b, updated Fri Jan 14 14:49:00 2022 -0800" name="generator">
   <link href="https://ngff.openmicroscopy.org/0.1/" rel="canonical">
-  <meta content="90de9f1c440bf7dccaac34fcfceb5785fc09ada5" name="document-revision">
+  <meta content="430a9ae7894f4427e823408a3bd3bbf149f0d578" name="document-revision">
 <style>/* style-autolinks */
 
 .css.css, .property.property, .descriptor.descriptor {
@@ -1825,7 +1825,7 @@
   <div class="head">
     <img alt="OME logo (6 circles in a hexagon)" src="http://www.openmicroscopy.org/img/logos/ome-logomark.svg" style="float:right;width:42px;height:42px;"> 
    <h1 class="p-name no-ref" id="title">Next-generation file formats (NGFF)</h1>
-   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Final Community Group Report, <time class="dt-updated" datetime="2022-01-28">28 January 2022</time></span></h2>
+   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Final Community Group Report, <time class="dt-updated" datetime="2022-02-02">2 February 2022</time></span></h2>
    <div data-fill-with="spec-metadata">
     <dl>
      <dt>This version:
diff --git a/0.2/index.html b/0.2/index.html
index 9272eaf6..d134125f 100644
--- a/0.2/index.html
+++ b/0.2/index.html
@@ -1489,7 +1489,7 @@
 </style>
   <meta content="Bikeshed version 2e3c4c68b, updated Fri Jan 14 14:49:00 2022 -0800" name="generator">
   <link href="https://ngff.openmicroscopy.org/0.2/" rel="canonical">
-  <meta content="90de9f1c440bf7dccaac34fcfceb5785fc09ada5" name="document-revision">
+  <meta content="430a9ae7894f4427e823408a3bd3bbf149f0d578" name="document-revision">
 <style>/* style-autolinks */
 
 .css.css, .property.property, .descriptor.descriptor {
@@ -1825,7 +1825,7 @@
   <div class="head">
     <img alt="OME logo (6 circles in a hexagon)" src="http://www.openmicroscopy.org/img/logos/ome-logomark.svg" style="float:right;width:42px;height:42px;"> 
    <h1 class="p-name no-ref" id="title">Next-generation file formats (NGFF)</h1>
-   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Final Community Group Report, <time class="dt-updated" datetime="2022-01-28">28 January 2022</time></span></h2>
+   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Final Community Group Report, <time class="dt-updated" datetime="2022-02-02">2 February 2022</time></span></h2>
    <div data-fill-with="spec-metadata">
     <dl>
      <dt>This version:
diff --git a/0.3/index.html b/0.3/index.html
index ffb85fc2..102d6085 100644
--- a/0.3/index.html
+++ b/0.3/index.html
@@ -8,7 +8,7 @@
   <link href="https://www.w3.org/2008/site/images/favicon.ico" rel="icon">
   <meta content="Bikeshed version 2e3c4c68b, updated Fri Jan 14 14:49:00 2022 -0800" name="generator">
   <link href="https://ngff.openmicroscopy.org/0.3/" rel="canonical">
-  <meta content="90de9f1c440bf7dccaac34fcfceb5785fc09ada5" name="document-revision">
+  <meta content="430a9ae7894f4427e823408a3bd3bbf149f0d578" name="document-revision">
 <style>/* style-autolinks */
 
 .css.css, .property.property, .descriptor.descriptor {
@@ -344,7 +344,7 @@
   <div class="head">
    <p data-fill-with="logo"><a class="logo" href="https://www.w3.org/"> <img alt="W3C" height="48" src="https://www.w3.org/StyleSheets/TR/2021/logos/W3C" width="72"> </a> </p>
    <h1 class="p-name no-ref" id="title">Next-generation file formats (NGFF)</h1>
-   <p id="w3c-state"><a href="https://www.w3.org/standards/types#CG-FINAL">Final Community Group Report</a>, <time class="dt-updated" datetime="2022-01-28">28 January 2022</time></p>
+   <p id="w3c-state"><a href="https://www.w3.org/standards/types#CG-FINAL">Final Community Group Report</a>, <time class="dt-updated" datetime="2022-02-02">2 February 2022</time></p>
    <details open>
     <summary>More details about this document</summary>
     <div data-fill-with="spec-metadata">
diff --git a/latest/index.html b/latest/index.html
index 4262a7c6..848e921a 100644
--- a/latest/index.html
+++ b/latest/index.html
@@ -1489,7 +1489,7 @@
 </style>
   <meta content="Bikeshed version 2e3c4c68b, updated Fri Jan 14 14:49:00 2022 -0800" name="generator">
   <link href="https://ngff.openmicroscopy.org/latest/" rel="canonical">
-  <meta content="90de9f1c440bf7dccaac34fcfceb5785fc09ada5" name="document-revision">
+  <meta content="430a9ae7894f4427e823408a3bd3bbf149f0d578" name="document-revision">
 <style>/* style-autolinks */
 
 .css.css, .property.property, .descriptor.descriptor {
@@ -1825,7 +1825,7 @@
   <div class="head">
     <img alt="OME logo (6 circles in a hexagon)" src="http://www.openmicroscopy.org/img/logos/ome-logomark.svg" style="float:right;width:42px;height:42px;"> 
    <h1 class="p-name no-ref" id="title">Next-generation file formats (NGFF)</h1>
-   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2022-01-28">28 January 2022</time></span></h2>
+   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2022-02-02">2 February 2022</time></span></h2>
    <div data-fill-with="spec-metadata">
     <dl>
      <dt>This version:
@@ -1878,7 +1878,7 @@ <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
      <a href="#metadata"><span class="secno">3</span> <span class="content">Metadata</span></a>
      <ol class="toc">
       <li><a href="#axes-md"><span class="secno">3.1</span> <span class="content">"axes" metadata</span></a>
-      <li><a href="#trafo-md"><span class="secno">3.2</span> <span class="content">"transformations" metadata</span></a>
+      <li><a href="#trafo-md"><span class="secno">3.2</span> <span class="content">"coordinateTransformations" metadata</span></a>
       <li><a href="#multiscale-md"><span class="secno">3.3</span> <span class="content">"multiscales" metadata</span></a>
       <li><a href="#omero-md"><span class="secno">3.4</span> <span class="content">"omero" metadata</span></a>
       <li><a href="#labels-md"><span class="secno">3.5</span> <span class="content">"labels" metadata</span></a>
@@ -1965,6 +1965,11 @@ <h2 class="heading settled" data-level="2" id="on-disk"><span class="secno">2. <
 is represented here as it would appear locally but could equally
 be stored on a web server to be accessed via HTTP or in object storage
 like S3 or GCS.</p>
+   <p>OME-Zarr is an implementation of the OME-NGFF specification using the Zarr
+format. Arrays MUST be defined and stored in a hierarchical organization as
+defined by the <a href="https://zarr.readthedocs.io/en/stable/spec/v2.html">version 2 of the Zarr specification </a>.
+OME-NGFF metadata MUST be stored as attributes in the corresponding Zarr
+groups.</p>
    <h3 class="heading settled" data-level="2.1" id="image-layout"><span class="secno">2.1. </span><span class="content">Images</span><a class="self-link" href="#image-layout"></a></h3>
    <p>The following layout describes the expected Zarr hierarchy for images with
 multiple levels of resolutions and optionally associated labels.
@@ -2017,7 +2022,7 @@ <h3 class="heading settled" data-level="2.1" id="image-layout"><span class="secn
 </pre>
    <h3 class="heading settled" data-level="2.2" id="hcs-layout"><span class="secno">2.2. </span><span class="content">High-content screening</span><a class="self-link" href="#hcs-layout"></a></h3>
    <p>The following specification defines the hierarchy for a high-content screening
-dataset. Three groups must be defined above the images:</p>
+dataset. Three groups MUST be defined above the images:</p>
    <ul>
     <li data-md>
      <p>the group above the images defines the well and MUST implement the <a href="#well-md">well specification</a>. All images contained in a well are fields
@@ -2028,6 +2033,8 @@ <h3 class="heading settled" data-level="2.2" id="hcs-layout"><span class="secno"
      <p>the group above the well row defines an entire plate i.e. a two-dimensional
 collection of wells organized in rows and columns. It MUST implement the <a href="#plate-md">plate specification</a></p>
    </ul>
+   <p>A well row group SHOULD NOT be present if there are no images in the well row.
+A well group SHOULD NOT be present if there are no images in the well.</p>
 <pre>.                             # Root folder, potentially in S3,
 │
 └── 5966.zarr                 # One plate (id=5966) converted to Zarr
@@ -2075,19 +2082,33 @@ <h3 class="heading settled" data-level="3.1" id="axes-md"><span class="secno">3.
      </ul>
    </ul>
    <p>If part of <a href="#multiscale-md">§ 3.3 "multiscales" metadata</a>, the length of "axes" MUST be equal to the number of dimensions of the arrays that contain the image data.</p>
-   <h3 class="heading settled" data-level="3.2" id="trafo-md"><span class="secno">3.2. </span><span class="content">"transformations" metadata</span><a class="self-link" href="#trafo-md"></a></h3>
-   <p>"transformations" describes a series of transformations, e.g. to map discrete data space of an array to the corresponding physical space.
+   <h3 class="heading settled" data-level="3.2" id="trafo-md"><span class="secno">3.2. </span><span class="content">"coordinateTransformations" metadata</span><a class="self-link" href="#trafo-md"></a></h3>
+   <p>"coordinateTransformations" describe a series of transformations that map between two coordinate spaces (defined by "axes").
+For example, to map a discrete data space of an array to the corresponding physical space.
 It is a list of dictionaries. Each entry describes a single transformation and MUST contain the field "type".
 The value of "type" MUST be one of the elements of the <code>type</code> column in the table below.
 Additional fields for the entry depend on "type" and are defined by the column <code>fields</code>.</p>
-   <p>| type          | fields | description |
-| ------------- | ------ |------------ |
-| <code>identity</code> |        | identity transformation, is the default transformation and is typically not explicitly defined |
-| <code>translation</code> | one of: <code>"translation":List[float]</code>, <code>"path":str</code> | translation vector, stored either as a list of floats (<code>"translation"</code>) or as binary data at a location in this container (<code>path</code>). The length of vector defines number of dimensions. |
-| <code>scale</code> | one of: <code>"scale":List[float]</code>, <code>"path":str</code> | scale vector, stored either as a list of floats (<code>scale</code>) or as binary data at a location in this container (<code>path</code>). The length of vector defines number of dimensions. |</p>
-   <p>In addition, the field "axisIndices" MAY be given to specify the subset of axes that the transformation is applied to, leaving other axes unchanged. If not given, the transformation is applied to all axes. The length of "axisIndices" MUST be equal to the dimensionality of the transformation. If "axisIndices" are not given, the dimensionality of the transformation MUST be equal to the number of dimensions of the space that the transformation is applied to.
-If given, "axisIndices" MUST be given in increasing order. It uses zero-based indexing.</p>
-   <p>The transformations in the list are applied sequentally and in order.</p>
+   <table>
+    <tbody>
+     <tr>
+      <th><code>identity</code> 
+      <td>
+      <td>identity transformation, is the default transformation and is typically not explicitly defined 
+     <tr>
+      <th><code>translation</code> 
+      <td> one of: <code>"translation":List[float]</code>, <code>"path":str</code> 
+      <td>translation vector, stored either as a list of floats (<code>"translation"</code>) or as binary data at a location in this container (<code>path</code>). The length of vector defines number of dimensions. | 
+     <tr>
+      <th><code>scale</code> 
+      <td> one of: <code>"scale":List[float]</code>, <code>"path":str</code> 
+      <td>scale vector, stored either as a list of floats (<code>scale</code>) or as binary data at a location in this container (<code>path</code>). The length of vector defines number of dimensions. | 
+    <thead>
+     <tr>
+      <th>type
+      <th>fields
+      <th>description 
+   </table>
+   <p>The transformations in the list are applied sequentially and in order.</p>
    <h3 class="heading settled" data-level="3.3" id="multiscale-md"><span class="secno">3.3. </span><span class="content">"multiscales" metadata</span><a class="self-link" href="#multiscale-md"></a></h3>
    <p>Metadata about an image can be found under the "multiscales" key in the group-level metadata. Here, image refers to 2 to 5 dimensional data representing image or volumetric data with optional time or channel axes. It is stored in a multiple resolution representation.</p>
    <p>"multiscales" contains a list of dictionaries where each entry describes a multiscale image.</p>
@@ -2103,16 +2124,15 @@ <h3 class="heading settled" data-level="3.3" id="multiscale-md"><span class="sec
 Each dictionary in "datasets" MUST contain the field "path", whose value contains the path to the array for this resolution relative
 to the current zarr group. The "path"s MUST be ordered from largest (i.e. highest resolution) to smallest.</p>
    <p>Each "datasets" dictionary MUST have the same number of dimensions and MUST NOT have more than 5 dimensions. The number of dimensions and order MUST correspond to number and order of "axes".
-Each dictionary MAY contain the field "transformations", which contains a list of transformations that map the data coordinates to the physical coordinates (as specified by "axes") for this resolution level.
-The transformations are defined according to <a href="#trafo-md">§ 3.2 "transformations" metadata</a>. In addition, the transformation types MUST only be <code>identity</code>, <code>translation</code> or <code>scale</code>.
-They MUST contain at most one <code>scale</code> transformation per axis that specifies the pixel size in physical units.
-It also MUST contain at most one <code>translation</code> per axis that specifies the offset from the origin in physical units.
-If both <code>scale</code> and <code>translation</code> are given <code>translation</code> must be listed after <code>scale</code> to ensure that it is given in physical coordinates. If "transformations" is not given, the identity transformation is assumed.
-The requirements (only <code>scale</code> and <code>translation</code>, restrictions on order) are in place to provide a simple mapping from data coordinates to physical coordinates while
-being compatible with the general transformation spec.</p>
-   <p>Each "multiscales" dictionary MAY contain the field "transformations", describing transformations that are applied to each resolution level.
-The transformations MUST follow the same rules about allowed types, order, etc. as in "datasets:transformations".
-These transformations are applied after the per resolution level transformations specified in "datasets". They can for example be used to specify the <code>scale</code> for a dimension that is the same for all resolutions.</p>
+Each dictionary MUST contain the field "coordinateTransformations", which contains a list of transformations that map the data coordinates to the physical coordinates (as specified by "axes") for this resolution level.
+The transformations are defined according to <a href="#trafo-md">§ 3.2 "coordinateTransformations" metadata</a>. The transformation MUST only be of type <code>translation</code> or <code>scale</code>.
+They MUST contain exactly one <code>scale</code> transformation that specifies the pixel size in physical units or time duration. If scaling information is not available or applicable for one of the axes set it to 1.
+It MAY contain exactly one <code>translation</code> that specifies the offset from the origin in physical units. If <code>translation</code> is given it MUST be listed after <code>scale</code> to ensure that it is given in physical coordinates.
+The length of the <code>scale</code> and <code>translation</code> array MUST be the same as the length of "axes".
+The requirements (only <code>scale</code> and <code>translation</code>, restrictions on order) are in place to provide a simple mapping from data coordinates to physical coordinates while being compatible with the general transformation spec.</p>
+   <p>Each "multiscales" dictionary MAY contain the field "coordinateTransformations", describing transformations that are applied to all resolution levels in the same manner.
+The transformations MUST follow the same rules about allowed types, order, etc. as in "datasets:coordinateTransformations" and are applied after them.
+They can for example be used to specify the <code>scale</code> for a dimension that is the same for all resolutions.</p>
    <p>Each "multiscales" dictionary SHOULD contain the field "name". It SHOULD contain the field "version", which indicates the version of the multiscale metadata of this image (current version is 0.4).</p>
    <p>Each "multiscales" dictionary SHOULD contain the field "type", which gives the type of downscaling method used to generate the multiscale image pyramid.
 It SHOULD contain the field "metadata", which contains a dictionary with additional information about the downscaling method.</p>
@@ -2131,18 +2151,18 @@ <h3 class="heading settled" data-level="3.3" id="multiscale-md"><span class="sec
             "datasets": [
                 {
                     "path": "0",
-                    "transformations": [{"type": "scale", "scale": [0.5, 0.5, 0.5], "axisIndices": [2, 3, 4]}]  # the voxel size for the first scale level (0.5 micrometer)
+                    "coordinateTransformations": [{"type": "scale", "scale": [1.0, 1.0, 0.5, 0.5, 0.5]}]  # the voxel size for the first scale level (0.5 micrometer)
                 }
                 {
                     "path": "1",
-                    "transformations": [{"type": "scale", "scale": [1.0, 1.0, 1.0], "axisIndices": [2, 3, 4]}]  # the voxel size for the second scale level (downscaled by a factor of 2 -> 1 micrometer)
+                    "coordinateTransformations": [{"type": "scale", "scale": [1.0, 1.0, 1.0, 1.0, 1.0]}]  # the voxel size for the second scale level (downscaled by a factor of 2 -> 1 micrometer)
                 },
                 {
                     "path": "2",
-                    "transformations": [{"type": "scale", "scale": [2.0, 2.0, 2.0], "axisIndices": [2, 3, 4]}]  # the voxel size for the second scale level (downscaled by a factor of 4 -> 2 micrometer)
+                    "coordinateTransformations": [{"type": "scale", "scale": [1.0, 1.0, 2.0, 2.0, 2.0]}]  # the voxel size for the second scale level (downscaled by a factor of 4 -> 2 micrometer)
                 }
             ],
-            "transformations": [{"type": "scale", "scale": [0.1], "axisIndices": [0]],  # the time unit (0.1 milliseconds), which is the same for each scale level
+            "coordinateTransformations": [{"type": "scale", "scale": [0.1, 1.0, 1.0, 1.0, 1.0]],  # the time unit (0.1 milliseconds), which is the same for each scale level
             "type": "gaussian",
             "metadata": {                                       # the fields in metadata depend on the downscaling implementation
                 "method": "skimage.transform.pyramid_gaussian", # here, the paramters passed to the skimage function are given
@@ -2276,8 +2296,13 @@ <h3 class="heading settled" data-level="3.7" id="plate-md"><span class="secno">3
     <dt><strong>columns</strong>
     <dd>A list of JSON objects defining the columns of the plate. Each column
       object defines the properties of the column at the index of the object
-      in the list. If not empty, it MUST contain a <code>name</code> key specifying the
-      column name.
+      in the list. Each column in the physical plate MUST be defined, even
+      if no wells in the column are defined. Each defined column MUST contain
+      a <code>name</code> key specifying the column name. The <code>name</code> MUST contain only
+      alphanumeric characters, MUST be case-sensitive, and MUST NOT be a
+      duplicate of any other <code>name</code> in the <code>columns</code> list. Care SHOULD be
+      taken to avoid collisions on case-insensitive filesystems
+      (e.g. avoid using both <code>Aa</code> and <code>aA</code>).
     <dt><strong>field_count</strong>
     <dd>An integer defining the maximum number of fields per view across all
       wells.
@@ -2286,16 +2311,28 @@ <h3 class="heading settled" data-level="3.7" id="plate-md"><span class="secno">3
     <dt><strong>rows</strong>
     <dd>A list of JSON objects defining the rows of the plate. Each row object
       defines the properties of the row at the index of the object in the
-      list. If not empty, it MUST contain a <code>name</code> key specifying the row
-      name.
+      list. Each row in the physical plate MUST be defined, even if no wells
+      in the row are defined. Each defined row MUST contain a <code>name</code> key
+      specifying the row name. The <code>name</code> MUST contain only alphanumeric
+      characters, MUST be case-sensitive, and MUST NOT be a duplicate
+      of any other <code>name</code> in the <code>rows</code> list. Care SHOULD be taken to avoid
+      collisions on case-insensitive filesystems (e.g. avoid using both <code>Aa</code> and <code>aA</code>).
     <dt><strong>version</strong>
     <dd>A string defining the version of the specification.
     <dt><strong>wells</strong>
     <dd>A list of JSON objects defining the wells of the plate. Each well object
       MUST contain a <code>path</code> key identifying the path to the well subgroup.
+      The <code>path</code> MUST consist of a <code>name</code> in the <code>rows</code> list, a file separator (<code>/</code>),
+      and a <code>name</code> from the <code>columns</code> list, in that order. The <code>path</code> MUST NOT contain
+      additional leading or trailing directories.
+      Each well object MUST contain both a <code>rowIndex</code> key identifying the index into
+      the <code>rows</code> list and a <code>columnIndex</code> key indentifying the index into
+      the <code>columns</code> list. <code>rowIndex</code> and <code>columnIndex</code> MUST be 0-based.
+      The <code>rowIndex</code>, <code>columnIndex</code>, and <code>path</code> MUST all refer to the same
+      row/column pair.
    </dl>
-   <p>For example the following JSON object defines a plate with two acquisition and
-6 wells (2 rows and 3 columns), containing up 2 fields of view per acquistion.</p>
+   <p>For example the following JSON object defines a plate with two acquisitions and
+6 wells (2 rows and 3 columns), containing up to 2 fields of view per acquisition.</p>
 <pre class="language-json highlight"><c- f>"plate"</c-><c- p>:</c-> <c- p>{</c->
     <c- f>"acquisitions"</c-><c- p>:</c-> <c- p>[</c->
         <c- p>{</c->
@@ -2335,43 +2372,147 @@ <h3 class="heading settled" data-level="3.7" id="plate-md"><span class="secno">3
     <c- f>"version"</c-><c- p>:</c-> <c- u>"0.3"</c-><c- p>,</c->
     <c- f>"wells"</c-><c- p>:</c-> <c- p>[</c->
         <c- p>{</c->
-            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/1"</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"A/1"</c-><c- p>,</c->
+            <c- f>"rowIndex"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->
+            <c- f>"columnIndex"</c-><c- p>:</c-> <c- mi>0</c->
         <c- p>},</c->
         <c- p>{</c->
-            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/2"</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- f>"A/2"</c->
+            <c- f>"rowIndex"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->
+            <c- f>"columnIndex"</c-><c- p>:</c-> <c- mi>1</c->
         <c- p>},</c->
         <c- p>{</c->
-            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/3"</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- f>"A/3"</c->
+            <c- f>"rowIndex"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->
+            <c- f>"columnIndex"</c-><c- p>:</c-> <c- mi>2</c->
         <c- p>},</c->
         <c- p>{</c->
-            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/1"</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- f>"B/1"</c->
+            <c- f>"rowIndex"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"columnIndex"</c-><c- p>:</c-> <c- mi>0</c->
         <c- p>},</c->
         <c- p>{</c->
-            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/2"</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- f>"B/2"</c->
+            <c- f>"rowIndex"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"columnIndex"</c-><c- p>:</c-> <c- mi>1</c->
         <c- p>},</c->
         <c- p>{</c->
-            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/3"</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- f>"B/3"</c->
+            <c- f>"rowIndex"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"columnIndex"</c-><c- p>:</c-> <c- mi>2</c->
+        <c- p>}</c->
+    <c- p>]</c->
+  <c- p>}</c->
+</pre>
+   <p>The following JSON object defines a sparse plate with one acquisition and
+2 wells in a 96 well plate, containing one field of view per acquisition.</p>
+<pre class="language-json highlight"><c- f>"plate"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"acquisitions"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"id"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"maximumfieldcount"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"single acquisition"</c-><c- p>,</c->
+            <c- f>"starttime"</c-><c- p>:</c-> <c- mi>1343731272000</c->
+        <c- p>},</c->
+    <c- p>],</c->
+    <c- f>"columns"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"3"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"4"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"5"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"6"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"7"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"8"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"9"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"10"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"11"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"12"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"field_count"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+    <c- f>"name"</c-><c- p>:</c-> <c- u>"sparse test"</c-><c- p>,</c->
+    <c- f>"rows"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"A"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"B"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"C"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"D"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"E"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"F"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"G"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"H"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.1"</c-><c- p>,</c->
+    <c- f>"wells"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- f>"C/5"</c->
+            <c- f>"rowIndex"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"columnIndex"</c-><c- p>:</c-> <c- mi>4</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- f>"D/7"</c->
+            <c- f>"rowIndex"</c-><c- p>:</c-> <c- mi>3</c-><c- p>,</c->
+            <c- f>"columnIndex"</c-><c- p>:</c-> <c- mi>6</c->
         <c- p>}</c->
     <c- p>]</c->
   <c- p>}</c->
 </pre>
    <h3 class="heading settled" data-level="3.8" id="well-md"><span class="secno">3.8. </span><span class="content">"well" metadata</span><a class="self-link" href="#well-md"></a></h3>
    <p>For high-content screening datasets, the metadata about all fields of views
-under a given  well can be found under the "well" key in the attributes of the
+under a given well can be found under the "well" key in the attributes of the
 well group.</p>
    <dl>
     <dt><strong>images</strong>
     <dd>A list of JSON objects defining the fields of views for a given well.
       Each object MUST contain a <code>path</code> key identifying the path to the
       field of view. If multiple acquisitions were performed in the plate, it
-      SHOULD contain an <code>acquisition</code> key identifying the id of the
+      MUST contain an <code>acquisition</code> key identifying the id of the
       acquisition which must match one of acquisition JSON objects defined in
       the plate metadata.
     <dt><strong>version</strong>
     <dd>A string defining the version of the specification.
    </dl>
    <p>For example the following JSON object defines a well with four fields of
-views. The first two fields of view were part of the first acquisition while
+view. The first two fields of view were part of the first acquisition while
 the last two fields of view were part of the second acquisition.</p>
 <pre class="language-json highlight"><c- f>"well"</c-><c- p>:</c-> <c- p>{</c->
     <c- f>"images"</c-><c- p>:</c-> <c- p>[</c->
@@ -2394,6 +2535,23 @@ <h3 class="heading settled" data-level="3.8" id="well-md"><span class="secno">3.
     <c- p>],</c->
     <c- f>"version"</c-><c- p>:</c-> <c- u>"0.3"</c->
   <c- p>}</c->
+</pre>
+   <p>The following JSON object defines a well with two fields of view in a plate with
+four acquisitions. The first field is part of the first acquisition, and the second
+field is part of the last acquisition.</p>
+<pre class="language-json highlight"><c- f>"well"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"images"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"0"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>3</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"1"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.1"</c->
+<c- p>}</c->
 </pre>
    <h2 class="heading settled" data-level="4" id="naming-style"><span class="secno">4. </span><span class="content">Specification naming style</span><a class="self-link" href="#naming-style"></a></h2>
    <p>Multi-word keys in this specification should use the <code>camelCase</code> style.