From 97673dab35031e836a96a450d74e16c4c30930ee Mon Sep 17 00:00:00 2001
From: Remi Gau <remi_gau@hotmail.com>
Date: Thu, 12 Dec 2024 14:17:41 +0100
Subject: [PATCH] reset

---
 src/derivatives/imaging.md                    | 131 ++--
 .../behavioral-experiments.md                 |   2 +-
 .../electroencephalography.md                 | 229 +++----
 .../magnetic-resonance-imaging-data.md        | 637 ++++++++----------
 .../magnetoencephalography.md                 | 259 +++----
 5 files changed, 563 insertions(+), 695 deletions(-)

diff --git a/src/derivatives/imaging.md b/src/derivatives/imaging.md
index 5fbdc85a5d..4ba975824f 100644
--- a/src/derivatives/imaging.md
+++ b/src/derivatives/imaging.md
@@ -14,19 +14,20 @@ Template:
             <source_entities>[_space-<space>][_res-<label>][_den-<label>][_desc-<label>]_<suffix>.<extension>
 ```
 
-Volumetric preprocessing does not modify the number of dimensions, and so the
-specifications in [Preprocessed or cleaned data][common_preproc] apply. The use
-of surface meshes and volumetric measures sampled to those meshes is
+Volumetric preprocessing does not modify the number of dimensions, and so
+the specifications in [Preprocessed or cleaned data][common_preproc]
+apply.
+The use of surface meshes and volumetric measures sampled to those meshes is
 sufficiently similar in practice to treat them equivalently.
 
-When two or more instances of a given derivative are provided with resolution or
-surface sampling density being the only difference between them, then the
-[`res`](../appendices/entities.md#res) (for _resolution_ of regularly sampled
-N-D data) and/or [`den`](../appendices/entities.md#den) (for _density_ of
-non-parametric surfaces) entities SHOULD be used to avoid name conflicts. Note
-that only files combining both regularly sampled (for example, gridded) and
-surface sampled data (and their downstream derivatives) are allowed to present
-both [`res`](../appendices/entities.md#res) and
+When two or more instances of a given derivative are provided with resolution
+or surface sampling density being the only difference between them, then the
+[`res`](../appendices/entities.md#res) (for *resolution* of regularly sampled N-D data) and/or
+[`den`](../appendices/entities.md#den) (for *density* of non-parametric surfaces)
+entities SHOULD be used to avoid name conflicts.
+Note that only files combining both regularly sampled (for example, gridded)
+and surface sampled data (and their downstream derivatives) are allowed
+to present both [`res`](../appendices/entities.md#res) and
 [`den`](../appendices/entities.md#den) entities simultaneously.
 
 Examples:
@@ -35,7 +36,6 @@ Examples:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "pipeline1": {
@@ -60,7 +60,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table([
        "derivatives.common_derivatives.ImageDerivatives",
        "derivatives.common_derivatives.ImageDerivativeResEntity",
@@ -80,8 +79,8 @@ Example JSON file corresponding to
 }
 ```
 
-This would be equivalent to having two JSON metadata files, one corresponding to
-`res-lo`
+This would be equivalent to having two JSON metadata files, one
+corresponding to `res-lo`
 (`pipeline1/sub-001/func/sub-001_task-rest_run-1_space-MNI305_res-lo_bold.json`):
 
 ```JSON
@@ -101,15 +100,14 @@ And one corresponding to `res-hi`
 }
 ```
 
-Example of CIFTI-2 files (a format that combines regularly sampled data and
-non-parametric surfaces) having both [`res`](../appendices/entities.md#res) and
-[`den`](../appendices/entities.md#den) entities:
+Example of CIFTI-2 files (a format that combines regularly sampled data
+and non-parametric surfaces) having both [`res`](../appendices/entities.md#res)
+and [`den`](../appendices/entities.md#den) entities:
 
 <!-- This block generates a file tree.
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "pipeline1": {
@@ -153,13 +151,11 @@ Template:
             <source_entities>[_space-<space>][_res-<label>][_den-<label>][_label-<label>][_desc-<label>]_mask.nii.gz
 ```
 
-A binary (1 - inside, 0 - outside) mask in the space defined by the
-[`space` entity](../appendices/entities.md#space). If no transformation has
-taken place, the value of `space` SHOULD be set to `orig`. If the mask is an ROI
-mask derived from an atlas segmentation, then the
-[`label` entity](../appendices/entities.md#label) SHOULD be used to specify the
-masked structure (see
-[Common image-derived labels](#common-image-derived-labels)).
+A binary (1 - inside, 0 - outside) mask in the space defined by the [`space` entity](../appendices/entities.md#space).
+If no transformation has taken place, the value of `space` SHOULD be set to `orig`.
+If the mask is an ROI mask derived from an atlas segmentation,
+then the [`label` entity](../appendices/entities.md#label) SHOULD be used to specify the masked structure
+(see [Common image-derived labels](#common-image-derived-labels)).
 
 JSON metadata fields:
 
@@ -171,7 +167,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table([
        "derivatives.common_derivatives.MaskDerivatives",
        "derivatives.common_derivatives.ImageDerivativeResEntity",
@@ -184,7 +179,6 @@ Examples:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "func_loc": {
@@ -202,7 +196,6 @@ A guide for using macros can be found at
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "manual_masks": {
@@ -218,23 +211,26 @@ A guide for using macros can be found at
 
 ## Segmentations
 
-A _segmentation_ is a labeling of regions of an image such that each location
+A *segmentation* is a labeling of regions of an image such that each location
 (for example, a voxel or a surface vertex) is identified with a label or a
-combination of labels. Labeled regions may include anatomical structures (such
-as tissue class, Brodmann area or white matter tract), discontiguous,
-functionally-defined networks, tumors or lesions.
+combination of labels.
+Labeled regions may include anatomical structures (such as tissue class,
+Brodmann area or white matter tract), discontiguous, functionally-defined
+networks, tumors or lesions.
 
-A _discrete segmentation_ represents each region with a unique integer label. A
-_probabilistic segmentation_ represents each region as values between 0 and 1
-(inclusive) at each location in the image, and one volume/frame per structure
-may be concatenated in a single file.
+A *discrete segmentation* represents each region with a unique integer
+label.
+A *probabilistic segmentation* represents each region as values between
+0 and 1 (inclusive) at each location in the image, and one volume/frame per
+structure may be concatenated in a single file.
 
 Segmentations may be defined in a volume (labeled voxels), a surface (labeled
 vertices) or a combined volume/surface space.
 
-If the segmentation can be generated in different ways, for example, following
-an atlas segmentation, the [`seg` entity](../appendices/entities.md#seg) MAY be
-used to distinguish the name of the segmentation used.
+If the segmentation can be generated in different ways,
+for example, following an atlas segmentation,
+the [`seg` entity](../appendices/entities.md#segmentation) MAY be used to
+distinguish the name of the segmentation used.
 
 The following section describes discrete and probabilistic segmentations of
 volumes, followed by discrete segmentations of surface/combined spaces.
@@ -250,7 +246,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table([
        "derivatives.common_derivatives.SegmentationCommon",
        "derivatives.common_derivatives.ImageDerivativeResEntity",
@@ -260,9 +255,9 @@ A guide for using macros can be found at
 ### Discrete Segmentations
 
 Discrete segmentations of brain tissue represent multiple anatomical structures
-(such as tissue class or Brodmann area) with a unique integer label in a 3D
-volume. See [Common image-derived labels](#common-image-derived-labels) for a
-description of how integer values map to anatomical structures.
+(such as tissue class or Brodmann area) with a unique integer label in a 3D volume.
+See [Common image-derived labels](#common-image-derived-labels) for a description
+of how integer values map to anatomical structures.
 
 Template:
 
@@ -279,7 +274,6 @@ Example:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "pipeline": {
@@ -294,11 +288,12 @@ A guide for using macros can be found at
 ) }}
 
 A segmentation can be used to generate a binary mask that functions as a
-discrete "label" for a single structure. In this case, the mask suffix MUST be
-used, the [`label` entity](../appendices/entities.md#label) SHOULD be used to
-specify the masked structure (see
-[Common image-derived labels](#common-image-derived-labels)), and the
-[`seg` entity](../appendices/entities.md#seg) SHOULD be defined.
+discrete "label" for a single structure.
+In this case, the mask suffix MUST be used,
+the [`label` entity](../appendices/entities.md#label) SHOULD be used
+to specify the masked structure
+(see [Common image-derived labels](#common-image-derived-labels)),
+and the [`seg` entity](../appendices/entities.md#segmentation) SHOULD be defined.
 
 For example:
 
@@ -306,7 +301,6 @@ For example:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "pipeline": {
@@ -324,9 +318,10 @@ A guide for using macros can be found at
 
 Probabilistic segmentations of brain tissue represent a single anatomical
 structure with values ranging from 0 to 1 in individual 3D volumes or across
-multiple frames. If a single structure is included, the
-[`label` entity](../appendices/entities.md#label) SHOULD be used to specify the
-structure.
+multiple frames.
+If a single structure is included,
+the [`label` entity](../appendices/entities.md#label) SHOULD be used to specify
+the structure.
 
 Template:
 
@@ -343,7 +338,6 @@ Example:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "pipeline": {
@@ -357,8 +351,8 @@ A guide for using macros can be found at
    }
 ) }}
 
-See [Common image-derived labels](#common-image-derived-labels) for reserved
-values for the [`label`](../appendices/entities.md#label) entity.
+See [Common image-derived labels](#common-image-derived-labels)
+for reserved values for the [`label`](../appendices/entities.md#label) entity.
 
 A 4D probabilistic segmentation, in which each frame corresponds to a different
 tissue class, must provide a label mapping in its JSON sidecar. For example:
@@ -367,7 +361,6 @@ tissue class, must provide a label mapping in its JSON sidecar. For example:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "pipeline": {
@@ -399,7 +392,7 @@ Values of `label` SHOULD correspond to abbreviations defined in
 
 ### Discrete surface segmentations
 
-Discrete surface segmentations (sometimes called _parcellations_) of cortical
+Discrete surface segmentations (sometimes called *parcellations*) of cortical
 structures MUST be stored as GIFTI label files, with the extension `.label.gii`.
 For combined volume/surface spaces, discrete segmentations MUST be stored as
 CIFTI-2 dense label files, with the extension `.dlabel.nii`.
@@ -413,15 +406,14 @@ Template:
             <source_entities>[_hemi-{L|R}][_space-<space>][_seg-<label>][_res-<label>][_den-<label>]_dseg.{label.gii|dlabel.nii}
 ```
 
-The [`hemi-<label>`](../appendices/entities.md#hemi) entity is REQUIRED for
-GIFTI files storing information about a structure that is restricted to a
-hemibrain. For example:
+The [`hemi-<label>`](../appendices/entities.md#hemi) entity is REQUIRED for GIFTI files storing information about
+a structure that is restricted to a hemibrain.
+For example:
 
 <!-- This block generates a file tree.
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "pipeline": {
@@ -441,7 +433,6 @@ The REQUIRED extension for CIFTI parcellations is `.dlabel.nii`. For example:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "pipeline": {
@@ -458,8 +449,8 @@ A guide for using macros can be found at
 ### Common image-derived labels
 
 BIDS supplies a standard, generic label-index mapping, defined in the table
-below, that contains common image-derived segmentations and can be used to map
-segmentations (and parcellations) between lookup tables.
+below, that contains common image-derived segmentations and can be used to map segmentations
+(and parcellations) between lookup tables.
 
 | **Integer value** | **Description**         | **Abbreviation (label)** |
 | ----------------- | ----------------------- | ------------------------ |
@@ -486,7 +477,6 @@ Example:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "pipeline": {
@@ -500,8 +490,8 @@ A guide for using macros can be found at
    }
 ) }}
 
-Definitions can also be specified with a top-level `dseg.tsv`, which propagates
-to segmentations in relative subdirectories.
+Definitions can also be specified with a top-level `dseg.tsv`, which propagates to
+segmentations in relative subdirectories.
 
 Example:
 
@@ -509,7 +499,6 @@ Example:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
     "pipeline": {
@@ -531,7 +520,6 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_columns_table("derivatives.common_derivatives.SegmentationLookup") }}
 
 An example, custom `dseg.tsv` that defines three labels:
@@ -556,4 +544,5 @@ index   name                abbreviation
 <!-- Link Definitions -->
 
 [common_preproc]: common-data-types.md#preprocessed-or-cleaned-data
+
 [unspecified]: ../common-principles.md#unspecified-data
diff --git a/src/modality-specific-files/behavioral-experiments.md b/src/modality-specific-files/behavioral-experiments.md
index c059383d0e..70fa5ae3a6 100644
--- a/src/modality-specific-files/behavioral-experiments.md
+++ b/src/modality-specific-files/behavioral-experiments.md
@@ -44,7 +44,7 @@ and a guide for using macros can be found at
 
 In addition to the metadata that is either:
 
--   RECOMMENDED for sidecar JSON files for [tabular data](../common-principles.md#tabular-files), or
+-   RECOMMENDED for sidecar JSON files for [tabular data](../common-principles.md#tabular-data), or
 
 -   REQUIRED for some data that can be found in the `beh` directory
     (for example `SamplingFrequency` and `StartTime` for `*_<physio|stim>.tsv.gz` files),
diff --git a/src/modality-specific-files/electroencephalography.md b/src/modality-specific-files/electroencephalography.md
index 86af304c03..25a0fe72a2 100644
--- a/src/modality-specific-files/electroencephalography.md
+++ b/src/modality-specific-files/electroencephalography.md
@@ -1,9 +1,10 @@
 # Electroencephalography
 
 Support for Electroencephalography (EEG) was developed as a
-[BIDS Extension Proposal](../extensions.md#bids-extension-proposals). Please see
-[Citing BIDS](../introduction.md#citing-bids) on how to appropriately credit
-this extension when referring to it in the context of the academic literature.
+[BIDS Extension Proposal](../extensions.md#bids-extension-proposals).
+Please see [Citing BIDS](../introduction.md#citing-bids)
+on how to appropriately credit this extension when referring to it in the
+context of the academic literature.
 
 !!! example "Example datasets"
 
@@ -20,7 +21,6 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template(
    "raw",
    datatypes=["eeg"],
@@ -34,7 +34,7 @@ stored in one of the following formats:
 | **Format**                                        | **Extension(s)**         | **Description**                                                                                                                                                                                      |
 | ------------------------------------------------- | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | [European data format](https://www.edfplus.info/) | `.edf`                   | Each recording consists of a single `.edf` file. [`edf+`](https://www.edfplus.info/specs/edfplus.html) files are permitted. The capital `.EDF` extension MUST NOT be used.                           |
-| [BrainVision Core Data Format][bvformat]          | `.vhdr`, `.vmrk`, `.eeg` | Each recording consists of a `.vhdr`, `.vmrk`, `.eeg` file triplet.                                                                                                                                  |
+| [BrainVision Core Data Format][bvformat]          | `.vhdr`, `.vmrk`, `.eeg` | Each recording consists of a  `.vhdr`, `.vmrk`, `.eeg` file triplet.                                                                                                                                 |
 | [EEGLAB](https://sccn.ucsd.edu/eeglab/index.php)  | `.set`, `.fdt`           | The format used by the MATLAB toolbox [EEGLAB](https://sccn.ucsd.edu/eeglab/index.php). Each recording consists of a `.set` file with an OPTIONAL `.fdt` file.                                       |
 | [Biosemi](https://www.biosemi.com/)               | `.bdf`                   | Each recording consists of a single `.bdf` file. [`bdf+`](https://www.teuniz.net/edfbrowser/bdfplus%20format%20description.html) files are permitted. The capital `.BDF` extension MUST NOT be used. |
 
@@ -47,43 +47,45 @@ RECOMMENDED formats.
 We encourage users to provide additional metadata extracted from the
 manufacturer-specific data files in the sidecar JSON file.
 
-Note the `RecordingType`, which depends on whether the data stream on disk is
-interrupted or not. Continuous data is by definition 1 segment without
-interruption. Epoched data consists of multiple segments that all have the same
-length (for example, corresponding to trials) and that have gaps in between.
-Discontinuous data consists of multiple segments of different length, for
-example due to a pause in the acquisition.
+Note the `RecordingType`, which depends on whether the data stream on disk
+is interrupted or not.
+Continuous data is by definition 1 segment without interruption.
+Epoched data consists of multiple segments that all have the same length
+(for example, corresponding to trials) and that have gaps in between.
+Discontinuous data consists of multiple segments of different length,
+for example due to a pause in the acquisition.
 
 Note that for proper documentation of EEG recording metadata it is important to
 understand the difference between electrode and channel: An EEG electrode is
 attached to the skin, whereas a channel is the combination of the analog
 differential amplifier and analog-to-digital converter that result in a
-potential (voltage) difference that is stored in the EEG dataset. We employ the
-following short definitions:
-
-- Electrode = A single point of contact between the acquisition system and the
-  recording site (for example, scalp, neural tissue, ...). Multiple electrodes
-  can be organized as caps (for EEG), arrays, grids, leads, strips, probes,
-  shafts, and so on.
-
-- Channel = A single analog-to-digital converter in the recording system that
-  regularly samples the value of a transducer, which results in the signal being
-  represented as a time series in the digitized data. This can be connected to
-  two electrodes (to measure the potential difference between them), a magnetic
-  field or magnetic gradient sensor, temperature sensor, accelerometer, and so
-  on.
-
-Although the _reference_ and _ground_ electrodes are often referred to as
-channels, they are in most common EEG systems not recorded by themselves.
-Therefore they are not represented as channels in the data. The type of
-referencing for all channels and optionally the location of the reference
-electrode and the location of the ground electrode MAY be specified.
+potential (voltage) difference that is stored in the EEG dataset. We employ
+the following short definitions:
+
+-   Electrode = A single point of contact between the acquisition system and
+    the recording site (for example, scalp, neural tissue, ...). Multiple electrodes
+    can be organized as caps (for EEG), arrays, grids, leads, strips, probes,
+    shafts, and so on.
+
+-   Channel = A single analog-to-digital converter in the recording system that
+    regularly samples the value of a transducer, which results in the signal
+    being represented as a time series in the digitized data. This can be
+    connected to two electrodes (to measure the potential difference between
+    them), a magnetic field or magnetic gradient sensor, temperature sensor,
+    accelerometer, and so on.
+
+Although the *reference* and *ground* electrodes are often referred to as
+channels, they are in most common EEG systems not recorded by
+themselves. Therefore they are not represented as channels in the data.
+The type of referencing for all channels and optionally the location of
+the reference electrode and the location of the ground electrode MAY
+be specified.
 
 ### Sidecar JSON (`*_eeg.json`)
 
-For consistency between studies and institutions, we encourage users to extract
-the values of these fields from the actual raw data. Whenever possible, please
-avoid using ad hoc wording.
+For consistency between studies and institutions,
+we encourage users to extract the values of these fields from the actual raw data.
+Whenever possible, please avoid using ad hoc wording.
 
 Those fields MUST be present:
 
@@ -95,7 +97,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("eeg.EEGRequired") }}
 
 Those fields SHOULD be present:
@@ -108,7 +109,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("eeg.EEGRecommended") }}
 
 These fields MAY be present:
@@ -121,7 +121,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("eeg.EEGOptional") }}
 
 #### Hardware information
@@ -134,7 +133,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("eeg.EEGHardware") }}
 
 #### Task information
@@ -147,7 +145,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("eeg.EEGTaskInformation") }}
 
 #### Institution information
@@ -160,7 +157,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("eeg.EEGInstitutionInformation") }}
 
 #### Example `*_eeg.json`
@@ -204,8 +200,8 @@ A guide for using macros can be found at
 ```
 
 Note that the date and time information SHOULD be stored in the Study key file
-([`scans.tsv`](../modality-agnostic-files.md#scans-file)). Date time information
-MUST be expressed as indicated in [Units](../common-principles.md#units)
+([`scans.tsv`](../modality-agnostic-files.md#scans-file)).
+Date time information MUST be expressed as indicated in [Units](../common-principles.md#units)
 
 ## Channels description (`*_channels.tsv`)
 
@@ -216,23 +212,20 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["eeg"], suffixes=["channels"]) }}
 
-This file is RECOMMENDED as it provides easily searchable information across
-BIDS datasets. For example for general curation, response to queries, or for
-batch analysis. To avoid confusion, the channels SHOULD be listed in the order
-they appear in the EEG data file. Any number of additional columns MAY be added
-to provide additional information about the channels.
+This file is RECOMMENDED as it provides easily searchable information across BIDS datasets.
+For example for general curation, response to queries, or for batch analysis.
+To avoid confusion, the channels SHOULD be listed in the order they appear in the EEG data file.
+Any number of additional columns MAY be added to provide additional information about the channels.
 
 Note that electrode positions SHOULD NOT be added to this file, but to
 [`*_electrodes.tsv`](./electroencephalography.md#electrodes-description-_electrodestsv).
-Furthermore, the entries in `*_electrodes.tsv` and `*_channels.tsv` do not have
-to match exactly, as for example in the case of recording a single `EOG` channel
-from a bipolar referencing scheme of two electrodes, or a data channel
-originating from an auxiliary, non-electrode device. That is, in most cases
-`*_electrodes.tsv` will have more entries than `*_channels.tsv`. See the
-examples for `*_channels.tsv` below, and for `*_electrodes.tsv` in
+Furthermore, the entries in `*_electrodes.tsv` and `*_channels.tsv` do not have to match exactly,
+as for example in the case of recording a single `EOG` channel from a bipolar referencing scheme
+of two electrodes, or a data channel originating from an auxiliary, non-electrode device.
+That is, in most cases `*_electrodes.tsv` will have more entries than `*_channels.tsv`.
+See the examples for `*_channels.tsv` below, and for `*_electrodes.tsv` in
 ["Electrodes description"](./electroencephalography.md#electrodes-description-_electrodestsv).
 
 The columns of the channels description table stored in `*_channels.tsv` are:
@@ -243,12 +236,11 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_columns_table("eeg.EEGChannels") }}
 
 Restricted keyword list for field `type` in alphabetic order (shared with the
-MEG and iEEG modality; however, only the types that are common in EEG data are
-listed here). Note that upper-case is REQUIRED:
+MEG and iEEG modality; however, only the types that are common in EEG data are listed here).
+Note that upper-case is REQUIRED:
 
 | **Keyword** | **Description**                                              |
 | ----------- | ------------------------------------------------------------ |
@@ -272,15 +264,15 @@ listed here). Note that upper-case is REQUIRED:
 
 Examples of free-form text for field `description`
 
-- n/a
-- stimulus
-- response
-- skin conductance
-- battery status
+-   n/a
+-   stimulus
+-   response
+-   skin conductance
+-   battery status
 
 ### Example `*_channels.tsv`
 
-See also the corresponding [`electrodes.tsv` example](#example-_electrodestsv).
+See also the corresponding [`electrodes.tsv` example](#example-electrodestsv).
 
 ```Text
 name     type  units  description                     reference     status  status_description
@@ -299,16 +291,14 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["eeg"], suffixes=["electrodes"]) }}
 
 File that gives the location of EEG electrodes. Note that coordinates are
 expected in cartesian coordinates according to the `EEGCoordinateSystem` and
-`EEGCoordinateUnits` fields in `*_coordsystem.json`. **If an `*_electrodes.tsv`
-file is specified, a
-[`*_coordsystem.json`](#coordinate-system-json-_coordsystemjson) file MUST be
-specified as well**. The order of the required columns in the `*_electrodes.tsv`
-file MUST be as listed below.
+`EEGCoordinateUnits` fields in `*_coordsystem.json`. **If an
+`*_electrodes.tsv` file is specified, a [`*_coordsystem.json`](#coordinate-system-json-_coordsystemjson)
+file MUST be specified as well**. The order of the required columns in the
+`*_electrodes.tsv` file MUST be as listed below.
 
 <!-- This block generates a columns table.
 The definitions of these fields can be found in
@@ -316,19 +306,17 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_columns_table("eeg.EEGElectrodes") }}
 
-`*_electrodes.tsv` files SHOULD NOT be duplicated for each data file, for
-example, during multiple runs of a task. The
-[inheritance principle](../common-principles.md#the-inheritance-principle) MUST
-be used to find the appropriate electrode positions for a given data file. If
-electrodes are repositioned, it is RECOMMENDED to use multiple sessions to
-indicate this.
+`*_electrodes.tsv` files SHOULD NOT be duplicated for each data file,
+for example, during multiple runs of a task.
+The [inheritance principle](../common-principles.md#the-inheritance-principle) MUST
+be used to find the appropriate electrode positions for a given data file.
+If electrodes are repositioned, it is RECOMMENDED to use multiple sessions to indicate this.
 
 ### Example `*_electrodes.tsv`
 
-See also the corresponding [`electrodes.tsv` example](#example-_channelstsv).
+See also the corresponding [`electrodes.tsv` example](#example-channelstsv).
 
 ```Text
 name   x        y	       z        type     material
@@ -342,9 +330,10 @@ REF    -0.0742  -0.0200  -0.0100  cup      Ag/AgCl
 ```
 
 The [`acq-<label>`](../appendices/entities.md#acq) entity can be used to
-indicate acquisition of the same data. For example, this could be the recording
-of electrode positions with a different electrode position recording device, or
-repeated digitization before and after the recording.
+indicate acquisition of the same data. For
+example, this could be the recording of electrode positions with a different
+electrode position recording device, or repeated digitization before and after
+the recording.
 
 ## Coordinate System JSON (`*_coordsystem.json`)
 
@@ -355,31 +344,29 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["eeg"], suffixes=["coordsystem"]) }}
 
 A `*_coordsystem.json` file is used to specify the fiducials, the location of
 anatomical landmarks, and the coordinate system and units in which the position
-of electrodes and landmarks is expressed. **The `*_coordsystem.json` is REQUIRED
-if the optional `*_electrodes.tsv` is specified**. If a corresponding anatomical
-MRI is available, the locations of landmarks and fiducials according to that
-scan should also be stored in the
-[`*_T1w.json`](./magnetic-resonance-imaging-data.md) file which goes alongside
-the MRI data.
+of electrodes and landmarks is expressed. **The `*_coordsystem.json` is
+REQUIRED if the optional `*_electrodes.tsv` is specified**. If a corresponding
+anatomical MRI is available, the locations of landmarks and fiducials according
+to that scan should also be stored in the [`*_T1w.json`](./magnetic-resonance-imaging-data.md)
+file which goes alongside the MRI data.
 
 For disambiguation, we employ the following definitions for fiducials and
 anatomical landmarks respectively:
 
-- **Fiducials** are objects with a well defined location used to facilitate the
-  localization of electrodes and co-registration with other geometric data such
-  as the participant's own T1 weighted magnetic resonance head image, a T1
-  weighted template head image, or a spherical head model. Commonly used
-  fiducials are vitamin-E pills, which show clearly in an MRI, or reflective
-  spheres that are localized with an infrared optical tracking system.
+-   **Fiducials** are objects with a well defined location used to facilitate the
+    localization of electrodes and co-registration with other geometric data
+    such as the participant's own T1 weighted magnetic resonance head image, a
+    T1 weighted template head image, or a spherical head model. Commonly used
+    fiducials are vitamin-E pills, which show clearly in an MRI, or reflective
+    spheres that are localized with an infrared optical tracking system.
 
-- **Anatomical landmarks** are locations on a research subject such as the
-  nasion, which is the intersection of the frontal bone and two nasal bones of
-  the human skull.
+-   **Anatomical landmarks** are locations on a research subject such as the nasion,
+    which is the intersection of the frontal bone and two nasal bones of the
+    human skull.
 
 Fiducials are typically used in conjunction with anatomical landmarks. An
 example would be the placement of vitamin-E pills on top of anatomical
@@ -387,11 +374,11 @@ landmarks, or the placement of LEDs on the nasion and preauricular points to
 triangulate the position of other LED-lit electrodes on a research subject's
 head.
 
-- For more information on the definition of anatomical landmarks, please visit:
-  [How are the Left and Right Pre-Auricular (LPA and RPA) points defined? - FieldTrip Toolbox](https://www.fieldtriptoolbox.org/faq/how_are_the_lpa_and_rpa_points_defined/)
+-   For more information on the definition of anatomical landmarks, please visit:
+    [How are the Left and Right Pre-Auricular (LPA and RPA) points defined? - FieldTrip Toolbox](https://www.fieldtriptoolbox.org/faq/how_are_the_lpa_and_rpa_points_defined/)
 
-- For more information on coordinate systems for coregistration, please visit:
-  [How are the different head and MRI coordinate systems defined? - FieldTrip Toolbox](https://www.fieldtriptoolbox.org/faq/coordsys/)
+-   For more information on coordinate systems for coregistration, please visit:
+    [How are the different head and MRI coordinate systems defined? - FieldTrip Toolbox](https://www.fieldtriptoolbox.org/faq/coordsys/)
 
 General fields:
 
@@ -403,7 +390,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_json_table("json.eeg.EEGCoordsystemGeneral") }}
 
 Fields relating to the EEG electrode positions:
@@ -416,7 +402,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_json_table("json.eeg.EEGCoordsystemPositions") }}
 
 Fields relating to the position of fiducials measured during an EEG session/run:
@@ -429,11 +414,9 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_json_table("json.eeg.EEGCoordsystemFiducials") }}
 
-Fields relating to the position of anatomical landmark measured during an EEG
-session/run:
+Fields relating to the position of anatomical landmark measured during an EEG session/run:
 
 <!-- This block generates a metadata table.
 These tables are defined in
@@ -443,7 +426,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_json_table(["json.eeg.EEGCoordsystemLandmark", "json.eeg.EEGCoordsystemLandmarkDescriptionRec"]) }}
 
 If the position of anatomical landmarks is measured using the same system or
@@ -452,17 +434,16 @@ landmarks are expressed in the same coordinates, the coordinates of the
 anatomical landmarks can be specified in `electrodes.tsv`. The same applies to
 the coordinates of the fiducials.
 
-Anatomical landmarks or fiducials measured on an anatomical MRI that match the
+Anatomical landmarks or fiducials measured on an anatomical MRI  that match the
 landmarks or fiducials during an EEG session/run, must be stored separately in
 the corresponding `*_T1w.json` or `*_T2w.json` file and should be expressed in
 voxels (starting from `[0, 0, 0]`).
 
-`*_coordsystem.json` files SHOULD NOT be duplicated for each data file, for
-example, across multiple tasks. The
-[inheritance principle](../common-principles.md#the-inheritance-principle) MUST
-be used to find the appropriate coordinate system description for a given data
-file. If electrodes are repositioned, it is RECOMMENDED to use multiple sessions
-to indicate this.
+`*_coordsystem.json` files SHOULD NOT be duplicated for each data file,
+for example, across multiple tasks.
+The [inheritance principle](../common-principles.md#the-inheritance-principle) MUST
+be used to find the appropriate coordinate system description for a given data file.
+If electrodes are repositioned, it is RECOMMENDED to use multiple sessions to indicate this.
 
 ### Example `*_coordsystem.json`
 
@@ -487,27 +468,25 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["eeg"], suffixes=["photo"]) }}
 
-Photos of the anatomical landmarks and/or fiducials are OPTIONAL. Please note
-that the photos may need to be cropped or blurred to conceal identifying
-features prior to sharing, depending on the terms of the consent given by the
-participant.
+Photos of the anatomical landmarks and/or fiducials are OPTIONAL.
+Please note that the photos may need to be cropped or blurred to conceal
+identifying features prior to sharing, depending on the terms of the consent
+given by the participant.
 
 The [`acq-<label>`](../appendices/entities.md#acq) entity can be used to
-indicate acquisition of different photos of the same face (or other body part in
-different angles to show, for example, the location of the nasion (NAS) as
-opposed to the right periauricular point (RPA).
+indicate acquisition of different photos of
+the same face (or other body part in different angles to show, for example, the
+location of the nasion (NAS) as opposed to the right periauricular point (RPA).
 
 ### Example `*_photo.<extension>`
 
-Picture of a NAS fiducial placed between the eyebrows, rather than at the actual
-anatomical nasion: `sub-0001_ses-001_acq-NAS_photo.jpg`
+Picture of a NAS fiducial placed between the eyebrows, rather than at the
+actual anatomical nasion: `sub-0001_ses-001_acq-NAS_photo.jpg`
 
 ![placement of NAS fiducial](images/sub-0001_ses-001_acq-NAS_photo.jpg "placement of NAS fiducial")
 
 <!-- Link Definitions -->
 
-[bvformat]:
-  https://www.brainproducts.com/support-resources/brainvision-core-data-format-1-0/
+[bvformat]: https://www.brainproducts.com/support-resources/brainvision-core-data-format-1-0/
diff --git a/src/modality-specific-files/magnetic-resonance-imaging-data.md b/src/modality-specific-files/magnetic-resonance-imaging-data.md
index c245a6d8b1..2b2078fe04 100644
--- a/src/modality-specific-files/magnetic-resonance-imaging-data.md
+++ b/src/modality-specific-files/magnetic-resonance-imaging-data.md
@@ -2,16 +2,16 @@
 
 ## Common metadata fields
 
-MR Data described in the following sections share the following RECOMMENDED
-metadata fields (stored in sidecar JSON files). MRI acquisition parameters are
-divided into several categories based on "A checklist for fMRI acquisition
-methods reporting in the literature"
+MR Data described in the following sections share the following RECOMMENDED metadata
+fields (stored in sidecar JSON files).
+MRI acquisition parameters are divided into several categories based on
+"A checklist for fMRI acquisition methods reporting in the literature"
 ([article](https://doi.org/10.15200/winn.143191.17127)) by Ben Inglis.
 
 When adding additional metadata please use the CamelCase version of
 [DICOM ontology terms](https://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_d.html)
 whenever possible. See also
-[recommendations on JSON files](../common-principles.md#key-value-files-dictionaries).
+[recommendations on JSON files](../common-principles.md#keyvalue-files-dictionaries).
 
 ### Hardware information
 
@@ -23,23 +23,22 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("mri.MRIHardware") }}
 
 Example for `ReceiveCoilActiveElements`:
 
 For Siemens, coil channels are typically not activated/selected individually,
-but rather in pre-defined selectable "groups" of individual channels, and the
-list of the "groups" of elements that are active/selected in any given scan
-populates the `Coil String` entry in Siemens' private DICOM fields (for example,
-`HEA;HEP` for the Siemens standard 32 ch coil when both the anterior and
-posterior groups are activated). This is a flexible field that can be used as
-most appropriate for a given vendor and coil to define the "active" coil
-elements. Since individual scans can sometimes not have the intended coil
-elements selected, it is preferable for this field to be populated directly from
-the DICOM for each individual scan, so that it can be used as a mechanism for
-checking that a given scan was collected with the intended coil elements
-selected.
+but rather in pre-defined selectable "groups" of individual channels,
+and the list of the "groups" of elements that are active/selected in any
+given scan populates the `Coil String` entry in Siemens' private DICOM fields
+(for example, `HEA;HEP` for the Siemens standard 32 ch coil
+when both the anterior and posterior groups are activated).
+This is a flexible field that can be used as most appropriate for a given
+vendor and coil to define the "active" coil elements.
+Since individual scans can sometimes not have the intended coil elements selected,
+it is preferable for this field to be populated directly from the DICOM
+for each individual scan, so that it can be used as a mechanism for checking
+that a given scan was collected with the intended coil elements selected.
 
 ### Institution information
 
@@ -51,7 +50,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("mri.MRIInstitutionInformation") }}
 
 ### Sequence Specifics
@@ -64,7 +62,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("mri.MRISequenceSpecifics") }}
 
 ### In- and Out-of-Plane Spatial Encoding
@@ -77,21 +74,19 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table(["mri.MRISpatialEncoding", "mri.PhaseEncodingDirectionRec"]) }}
 
 <sup>2</sup>Conveniently, for Siemens data, this value is easily obtained as
 `1 / (BWPPPE * ReconMatrixPE)`, where BWPPPE is the
-"BandwidthPerPixelPhaseEncode" in DICOM Tag 0019, 1028 and ReconMatrixPE is the
-size of the actual reconstructed data in the phase direction (which is NOT
+"BandwidthPerPixelPhaseEncode" in DICOM Tag 0019, 1028 and ReconMatrixPE is
+the size of the actual reconstructed data in the phase direction (which is NOT
 reflected in a single DICOM Tag for all possible aforementioned scan
 manipulations). See
 [Acquiring and using field maps - LCNI](https://lcni.uoregon.edu/wiki/acquiring-and-using-field-maps/)
-and
-[TotalReadoutTime - dcm_qa](https://github.com/neurolabusc/dcm_qa/tree/master/In/TotalReadoutTime).
+and [TotalReadoutTime - dcm\_qa](https://github.com/neurolabusc/dcm_qa/tree/master/In/TotalReadoutTime).
 
-<sup>3</sup>We use the time between the center of the first "effective" echo and
-the center of the last "effective" echo, sometimes called the "FSL definition".
+<sup>3</sup>We use the time between the center of the first "effective" echo
+and the center of the last "effective" echo, sometimes called the "FSL definition".
 
 ### Timing Parameters
 
@@ -103,7 +98,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table(["mri.MRITimingParameters", "mri.SliceTimingMRI"]) }}
 
 ### RF & Contrast
@@ -116,7 +110,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table(["mri.MRIFlipAngleLookLockerFalse", "mri.MRIRFandContrast" ]) }}
 
 ### Slice Acceleration
@@ -129,7 +122,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("mri.MRISliceAcceleration") }}
 
 ### Anatomical landmarks
@@ -144,22 +136,21 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("mri.MRIAnatomicalLandmarks") }}
 
-### Echo-Planar Imaging and _B<sub>0</sub>_ mapping
+### Echo-Planar Imaging and *B<sub>0</sub>* mapping
 
-Echo-Planar Imaging (EPI) schemes typically used in the acquisition of diffusion
-and functional MRI may also be _intended for_ estimating the _B<sub>0</sub>_
-field nonuniformity inside the scanner (in other words, _mapping the field_)
-without the acquisition of additional MRI schemes such as gradient-recalled echo
-(GRE) sequences that are stored under the `fmap/` directory of the BIDS
-structure.
+Echo-Planar Imaging (EPI) schemes typically used in the acquisition of
+diffusion and functional MRI may also be *intended for* estimating the
+*B<sub>0</sub>* field nonuniformity inside the scanner (in other words,
+*mapping the field*) without the acquisition of additional MRI schemes
+such as gradient-recalled echo (GRE) sequences that are stored under the
+`fmap/` directory of the BIDS structure.
 
-The modality labels `dwi` (under `dwi/`), `bold` (under `func/`), `asl` (under
-`perf/`), `sbref` (under `dwi/`, `func/` or `perf/`), and any modality under
-`fmap/` are allowed to encode the MR protocol intent for fieldmap estimation
-using the following metadata:
+The modality labels `dwi` (under `dwi/`), `bold` (under `func/`),
+`asl` (under `perf/`), `sbref` (under `dwi/`, `func/` or `perf/`), and
+any modality under `fmap/` are allowed to encode the MR protocol intent for
+fieldmap estimation using the following metadata:
 
 <!-- This block generates a metadata table.
 These tables are defined in
@@ -169,7 +160,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table([
      "mri.MRIB0FieldIdentifier",
      "mri.MRIEchoPlanarImagingAndB0FieldSource",
@@ -186,13 +176,12 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("mri.MRISample") }}
 
 ### Deidentification information
 
-Describes the mechanism or method used to modify or remove metadata and/or pixel
-data to protect the patient or participant's identity.
+Describes the mechanism or method used to modify or remove metadata
+and/or pixel data to protect the patient or participant's identity.
 
 <!-- This block generates a metadata table.
 These tables are defined in
@@ -202,11 +191,9 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("mri.DeidentificationMethod") }}
 
-Each object in the `DeidentificationMethodCodeSequence` array includes the
-following RECOMMENDED keys:
+Each object in the `DeidentificationMethodCodeSequence` array includes the following RECOMMENDED keys:
 
 <!-- This block generates a table describing subfields within a metadata field.
 The definitions of these fields can be found in
@@ -214,20 +201,21 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_subobject_table("metadata.DeidentificationMethodCodeSequence.items") }}
 
 ## Anatomy imaging data
 
 Anatomy MRI sequences measure static, structural features of the brain.
 
-This datatype is divided into two groups: non-parametric and parametric.
+This datatype is divided into two groups:
+non-parametric and parametric.
 
-Non-parametric structural images have an arbitrary scale. For example, T1w data
-are T1-weighted, but the values do not correspond to actual T1 value estimates.
+Non-parametric structural images have an arbitrary scale.
+For example, T1w data are T1-weighted,
+but the values do not correspond to actual T1 value estimates.
 
-Parametric structural imaging, on the other hand, use a non-arbitrary scale. For
-example, a T1map file contains T1 value estimates, in seconds.
+Parametric structural imaging, on the other hand, use a non-arbitrary scale.
+For example, a T1map file contains T1 value estimates, in seconds.
 
 ### Non-parametric structural MR images
 
@@ -238,7 +226,6 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["anat"], suffixes=[
          "T1w",
          "T2w",
@@ -262,7 +249,6 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_suffix_table(
       [
          "T1w",
@@ -279,18 +265,19 @@ and a guide for using macros can be found at
    )
 }}
 
-The [`part-<label>`](../appendices/entities.md#part) entity is used to indicate
-which component of the complex representation of the MRI signal is represented
-in voxel data. This entity is associated with the DICOM Tag `0008, 9208`.
+The [`part-<label>`](../appendices/entities.md#part) entity is
+used to indicate which component of the complex representation of the MRI
+signal is represented in voxel data.
+This entity is associated with the DICOM Tag `0008, 9208`.
 Allowed label values for this entity are `phase`, `mag`, `real` and `imag`,
 which are typically used in `part-mag`/`part-phase` or `part-real`/`part-imag`
-pairs of files. For example:
+pairs of files.
+For example:
 
 <!-- This block generates a file tree.
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
    "sub-01": {
@@ -305,9 +292,9 @@ A guide for using macros can be found at
 )
 }}
 
-Phase images MAY be in radians or in arbitrary units. The sidecar JSON file MUST
-include the units of the `phase` image. The possible options are `rad` or
-`arbitrary`.
+Phase images MAY be in radians or in arbitrary units.
+The sidecar JSON file MUST include the units of the `phase` image.
+The possible options are `rad` or `arbitrary`.
 
 For example, for `sub-01_part-phase_T1w.json`:
 
@@ -317,8 +304,7 @@ For example, for `sub-01_part-phase_T1w.json`:
 }
 ```
 
-When there is only a magnitude image of a given type, the `part` entity MAY be
-omitted.
+When there is only a magnitude image of a given type, the `part` entity MAY be omitted.
 
 ### Parametric structural MR images
 
@@ -332,7 +318,6 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["anat"], suffixes=[
          "T1map",
          "R1map",
@@ -355,13 +340,13 @@ and a guide for using macros can be found at
 }}
 
 Parametric images listed in the table below are typically generated by
-processing a
-[file collection](../common-principles.md#entity-linked-file-collections).
-Please visit the [file collections appendix](../appendices/file-collections.md)
-to see the list of suffixes available for quantitative MRI (qMRI) applications
-associated with these maps (for example, [MPM](../glossary.md#mpm-suffixes),
-[MP2RAGE](../glossary.md#mp2rage-suffixes), and
-[MTR](../glossary.md#mtransfer-entities)).
+processing a [file collection](../common-principles.md#entity-linked-file-collections).
+Please visit the [file collections appendix](../appendices/file-collections.md) to see the
+list of suffixes available for quantitative MRI (qMRI) applications associated
+with these maps
+(for example, [MPM](../glossary.md#mpm-suffixes),
+[MP2RAGE](../glossary.md#mp2rage-suffixes),
+and [MTR](../glossary.md#mtransfer-entities)).
 
 Currently supported parametric maps include:
 
@@ -372,7 +357,6 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_suffix_table(
       [
          "T1map",
@@ -396,19 +380,20 @@ and a guide for using macros can be found at
    )
 }}
 
-For any other details on the organization of parametric maps, their recommended
-metadata fields, and the application specific entity or metadata requirement
-levels of [file collections](../appendices/file-collections.md) that can
-generate them, visit the [qMRI appendix](../appendices/qmri.md).
+For any other details on the organization of parametric maps, their
+recommended metadata fields, and the application specific entity or
+metadata requirement levels of [file collections](../appendices/file-collections.md) that can generate
+them, visit the [qMRI appendix](../appendices/qmri.md).
 
 ### Defacing masks
 
 If the structural images included in the dataset were defaced (to protect
 identity of participants) one MAY provide the binary mask that was used to
-remove facial features in the form of `_defacemask` files. In such cases, the
-OPTIONAL [`mod-<label>`](../appendices/entities.md#mod) entity corresponds to
-modality suffix, such as `T1w` or `inplaneT1`, referenced by the defacemask
-image. For example, `sub-01_mod-T1w_defacemask.nii.gz`.
+remove facial features in the form of `_defacemask` files.
+In such cases, the OPTIONAL [`mod-<label>`](../appendices/entities.md#mod)
+entity corresponds to modality suffix,
+such as `T1w` or `inplaneT1`, referenced by the defacemask image.
+For example, `sub-01_mod-T1w_defacemask.nii.gz`.
 
 <!--
 This block generates a filename templates.
@@ -417,7 +402,6 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["anat"], suffixes=[
          "defacemask",
       ])
@@ -426,8 +410,8 @@ and a guide for using macros can be found at
 ### Task metadata for anatomical scans
 
 The OPTIONAL [`task-<label>`](../appendices/entities.md#task) entity can be used
-in order to allow tasks during structural MR acquisitions, for example
-pre-described motion paradigms such as nodding, to be described.
+in order to allow tasks during structural MR acquisitions,
+for example pre-described motion paradigms such as nodding, to be described.
 
 <!-- This block generates a metadata table.
 The definitions of these fields can be found in
@@ -435,13 +419,12 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("anat.TaskMetadata") }}
 
 Some meta information about the acquisition MAY be provided in an additional
-JSON file. See [Common metadata fields](#common-metadata-fields) for a list of
-terms and their definitions. There are also some OPTIONAL JSON fields specific
-to anatomical scans:
+JSON file. See [Common metadata fields](#common-metadata-fields) for a
+list of terms and their definitions. There are also some OPTIONAL JSON
+fields specific to anatomical scans:
 
 <!-- This block generates a metadata table.
 These tables are defined in
@@ -451,16 +434,15 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("anat.MRIAnatomyCommonMetadataFields") }}
 
 ### Deprecated suffixes
 
 Some suffixes that were available in versions of the specification prior to
-1.5.0 have been deprecated. These suffixes are ambiguous and have been
-superseded by more precise conventions. Therefore, they are not recommended for
-use in new datasets. They are, however, still valid suffixes, to maintain
-backwards compatibility.
+1.5.0 have been deprecated.
+These suffixes are ambiguous and have been superseded by more precise conventions.
+Therefore, they are not recommended for use in new datasets.
+They are, however, still valid suffixes, to maintain backwards compatibility.
 
 The following suffixes are valid, but SHOULD NOT be used for new BIDS compatible
 datasets (created after version 1.5.0.):
@@ -472,7 +454,6 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_suffix_table(
       [
          "T2star",
@@ -493,7 +474,6 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_suffix_table(
       [
          "bold",
@@ -510,16 +490,14 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["func"]) }}
 
-Functional imaging consists of techniques that support rapid temporal
-repetition. This includes, but is not limited to, task based fMRI, as well as
-resting state fMRI, which is treated like any other task. For task based fMRI, a
-corresponding task events file (see below) MUST be provided (please note that
-this file is not necessary for resting state scans). For multiband acquisitions,
-one MAY also save the single-band reference image with the `sbref` suffix (for
-example, `sub-control01_task-nback_sbref.nii.gz`).
+Functional imaging consists of techniques that support rapid temporal repetition.
+This includes, but is not limited to, task based fMRI, as well as resting state fMRI, which is treated like any other task.
+For task based fMRI, a corresponding task events file (see below) MUST be provided
+(please note that this file is not necessary for resting state scans).
+For multiband acquisitions, one MAY also save the single-band reference image with the `sbref` suffix
+(for example, `sub-control01_task-nback_sbref.nii.gz`).
 
 Multi-echo data MUST be split into one file per echo using the
 [`echo-<index>`](../appendices/entities.md#echo) entity. For example:
@@ -528,7 +506,6 @@ Multi-echo data MUST be split into one file per echo using the
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
    "sub-01": {
@@ -545,18 +522,17 @@ A guide for using macros can be found at
 ) }}
 
 Please note that the `<index>` denotes the number/index (in the form of a
-nonnegative integer) of the echo not the echo time value which needs to be
-stored in the field EchoTime of the separate JSON file.
-
-Complex-valued data MUST be split into one file for each data type. For BOLD
-data, there are separate suffixes for magnitude (`_bold`) and phase (`_phase`)
-data, but the `_phase` suffix is
-[deprecated](../common-principles.md#definitions). Newly generated datasets
-SHOULD NOT use the `_phase` suffix, and the suffix will be removed from the
-specification in the next major release. For backwards compatibility, `_phase`
-is considered equivalent to `_part-phase_bold`. When the `_phase` suffix is not
-used, each file shares the same name with the exception of the
-`part-<mag|phase>` or `part-<real|imag>` entity.
+nonnegative integer) of the echo not the echo time value which needs to be stored in the
+field EchoTime of the separate JSON file.
+
+Complex-valued data MUST be split into one file for each data type.
+For BOLD data, there are separate suffixes for magnitude (`_bold`) and phase
+(`_phase`) data, but the `_phase` suffix is [deprecated](../common-principles.md#definitions).
+Newly generated datasets SHOULD NOT use the `_phase` suffix, and the suffix will be removed
+from the specification in the next major release.
+For backwards compatibility, `_phase` is considered equivalent to `_part-phase_bold`.
+When the `_phase` suffix is not used, each file shares the same
+name with the exception of the `part-<mag|phase>` or `part-<real|imag>` entity.
 
 For example:
 
@@ -564,7 +540,6 @@ For example:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
    "sub-01": {
@@ -582,8 +557,7 @@ A guide for using macros can be found at
    }
 ) }}
 
-Some meta information about the acquisition MUST be provided in an additional
-JSON file.
+Some meta information about the acquisition MUST be provided in an additional JSON file.
 
 ### Required fields
 
@@ -595,7 +569,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table([
        "func.MRIFuncRepetitionTime",
        "func.MRIFuncVolumeTiming",
@@ -604,9 +577,9 @@ A guide for using macros can be found at
 }}
 
 For the fields described above and in the following section, the term "Volume"
-refers to a reconstruction of the object being imaged (for example, brain or
-part of a brain). In case of multiple channels in a coil, the term "Volume"
-refers to a combined image rather than an image from each coil.
+refers to a reconstruction of the object being imaged (for example, brain or part of a
+brain). In case of multiple channels in a coil, the term "Volume" refers to a
+combined image rather than an image from each coil.
 
 ### Other RECOMMENDED metadata
 
@@ -620,7 +593,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("func.MRIFuncTimingParameters") }}
 
 The following table recapitulates the different ways that specific fields have
@@ -638,9 +610,9 @@ sparse sequences.
 
 **Legend**
 
-- \[ X ] --> MUST be defined
-- \[ \] --> MUST NOT be defined
-- empty cell --> MAY be specified
+-   \[ X ] --> MUST be defined
+-   \[  \] --> MUST NOT be defined
+-   empty cell --> MAY be specified
 
 #### fMRI task information
 
@@ -652,11 +624,10 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("func.MRIFuncTaskInformation") }}
 
-See [Common metadata fields](#common-metadata-fields) for a list of additional
-terms and their definitions.
+See [Common metadata fields](#common-metadata-fields) for a list of
+additional terms and their definitions.
 
 Example:
 
@@ -664,7 +635,6 @@ Example:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
    "sub-01": {
@@ -705,8 +675,8 @@ A guide for using macros can be found at
     -   [`ds114`](https://github.com/bids-standard/bids-examples/tree/master/ds114)
     -   [`ds000117`](https://github.com/bids-standard/bids-examples/tree/master/ds000117)
 
-Diffusion-weighted imaging data acquired for a participant. Currently supported
-image types include:
+Diffusion-weighted imaging data acquired for a participant.
+Currently supported image types include:
 
 <!--
 This block generates a suffix table.
@@ -715,7 +685,6 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_suffix_table(["dwi", "sbref"]) }}
 
 Additionally, the following suffixes are used for scanner-generated images:
@@ -727,7 +696,6 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_suffix_table(["ADC", "expADC", "trace", "FA", "colFA", "S0map"]) }}
 
 <!--
@@ -737,102 +705,102 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["dwi"]) }}
 
-The [`run-<index>`](../appendices/entities.md#run) entity is RECOMMENDED to
-encode the splits of multipart DWI scans (see
-[below](#multipart-split-dwi-schemes) for more information on multipart DWI
-schemes).
+The [`run-<index>`](../appendices/entities.md#run) entity is RECOMMENDED
+to encode the splits of multipart DWI scans
+(see [below](#multipart-split-dwi-schemes) for more information on multipart DWI schemes).
 
-**Combining multi- and single-band acquisitions**. The single-band reference
-image MAY be stored with suffix `sbref` (for example,
+**Combining multi- and single-band acquisitions**.
+The single-band reference image MAY be stored with suffix `sbref` (for example,
 `dwi/sub-control01_sbref.nii[.gz]`) as long as the image has no corresponding
 [gradient information (`[*_]dwi.bval` and `[*_]dwi.bvec` sidecar files)](#required-gradient-orientation-information)
 to be stored.
 
-Otherwise, if some gradient information is associated to the single-band
-diffusion image and a multi-band diffusion image also exists, the `acq-<label>`
-entity MUST be used to distinguish both images. In such a case, two files could
-have the following names: `sub-01_acq-singleband_dwi.nii.gz` and
-`sub-01_acq-multiband_dwi.nii.gz`. The user is free to choose any other label
-than `singleband` and `multiband`, as long as they are consistent across
-subjects and sessions.
-
-Scanner-generated derivative images, such as trace-weighted, ADC, exponentiated
-ADC, fractional anisotropy (FA and colFA), and estimated unweighted signal
-intensity, MAY be included using the `trace`, `ADC`, `expADC`, `FA`, `colFA` and
-`S0map` suffixes, respectively. If trace, ADC, expADC, FA, colFA, or S0 volume
-filenames match a diffusion series with all applicable entities, such volumes
-SHOULD have been computed from that series. Otherwise, some entity, such as
-[`acq-<label>`](../appendices/entities.md#acq), SHOULD be used to indicate that
-the files are unrelated.
+Otherwise, if some gradient information is associated to the single-band diffusion
+image and a multi-band diffusion image also exists, the `acq-<label>` entity
+MUST be used to distinguish both images.
+In such a case, two files could have the following names:
+`sub-01_acq-singleband_dwi.nii.gz` and `sub-01_acq-multiband_dwi.nii.gz`.
+The user is free to choose any other label than `singleband` and
+`multiband`, as long as they are consistent across subjects and sessions.
+
+Scanner-generated derivative images,
+such as trace-weighted, ADC, exponentiated ADC,
+fractional anisotropy (FA and colFA), and estimated unweighted signal intensity,
+MAY be included using the `trace`, `ADC`, `expADC`, `FA`, `colFA` and `S0map` suffixes, respectively.
+If trace, ADC, expADC, FA, colFA, or S0 volume filenames match a diffusion series with all applicable entities,
+such volumes SHOULD have been computed from that series.
+Otherwise, some entity, such as [`acq-<label>`](../appendices/entities.md#acq),
+SHOULD be used to indicate that the files are unrelated.
 
 ### REQUIRED gradient orientation information
 
 The REQUIRED gradient orientation information corresponding to a DWI acquisition
-MUST be stored using `[*_]dwi.bval` and `[*_]dwi.bvec` pairs of files. The
-`[*_]dwi.bval` and `[*_]dwi.bvec` files MAY be saved on any level of the
-directory structure and thus define those values for all sessions and/or
-subjects in one place (see
+MUST be stored using `[*_]dwi.bval` and `[*_]dwi.bvec` pairs of files.
+The `[*_]dwi.bval` and `[*_]dwi.bvec` files MAY be saved on any level of the directory structure
+and thus define those values for all sessions and/or subjects in one place (see
 [the inheritance principle](../common-principles.md#the-inheritance-principle)).
 
 As an exception to the [common principles](../common-principles.md#definitions)
 that parameters are constant across runs, the gradient table information (stored
 within the `[*_]dwi.bval` and `[*_]dwi.bvec` files) MAY change across DWI runs.
 
-**Gradient orientation file formats**. The `[*_]dwi.bval` and `[*_]dwi.bvec`
-files MUST follow the
+**Gradient orientation file formats**.
+The `[*_]dwi.bval` and `[*_]dwi.bvec` files MUST follow the
 [FSL format](https://fsl.fmrib.ox.ac.uk/fsl/docs/#/diffusion/index?id=diffusion-data-in-fsl).
 
-The `[*_]dwi.bvec` file contains 3 rows with _N_ space-delimited floating-point
-numbers, corresponding to the _N_ volumes in the corresponding NIfTI file.
-Across these three rows, each column encodes three elements of a 3-vector for
-the corresponding image volume; each vector MUST be either of unit norm, or
-optionally the vector `[0.0,0.0,0.0]` for _non-diffusion-weighted_ (also called
-_b_=0 or _low-b_) volumes. These values are to be interpreted as cosine values
-with respect to the image axis orientations as defined by the corresponding
-NIfTI image header transformation; _unless_ the image axes defined in the
-corresponding NIfTI image header form a right-handed coordinate system (that is,
-the 3x3 matrix of direction cosines has a positive determinant), in which case
-the sign of the first element of each 3-vector must be inverted for this
-interpretation to be valid. Note that this definition of orientations with
-respect to the NIfTI image axes is _not_ equivalent to the DICOM convention,
-where orientations are instead defined with respect to the scanner device's
-coordinate system (see
-[Coordinate systems](../appendices/coordinate-systems.md)).
-
-The `[*_]dwi.bval` file contains the _b_-values (in s/mm<sup>2</sup>)
-corresponding to the volumes in the relevant NIfTI file, with 0 designating
-_b_=0 volumes; space-delimited.
-
-Examples of `[*_]dwi.bvec` and `[*_]dwi.bval` files, corresponding to a NIfTI
-image with 6 volumes with the first two volumes having no diffusion
-sensitization:
-
-- `[*_]dwi.bvec`:
-
-  ```Text
-  0 0 0.021828 -0.015425 -0.70918 -0.2465
-  0 0 0.80242 0.22098 -0.00063106 0.1043
-  0 0 -0.59636 0.97516 -0.70503 -0.96351
-  ```
-
-- `[_]dwi.bval`:
-  ```Text
-  0 0 2000 2000 1000 1000
-  ```
+The `[*_]dwi.bvec` file contains 3 rows with *N* space-delimited floating-point numbers,
+corresponding to the *N* volumes in the corresponding NIfTI file.
+Across these three rows,
+each column encodes three elements of a 3-vector for the corresponding image volume;
+each vector MUST be either of unit norm,
+or optionally the vector `[0.0,0.0,0.0]`
+for *non-diffusion-weighted* (also called *b*=0 or *low-b*) volumes.
+These values are to be interpreted as cosine values with respect to the image axis orientations
+as defined by the corresponding NIfTI image header transformation;
+*unless* the image axes defined in the corresponding NIfTI image header
+form a right-handed coordinate system
+(that is, the 3x3 matrix of direction cosines has a positive determinant),
+in which case the sign of the first element of each 3-vector must be inverted
+for this interpretation to be valid.
+Note that this definition of orientations with respect to the NIfTI image axes
+is *not* equivalent to the DICOM convention,
+where orientations are instead defined with respect to the scanner device's coordinate system
+(see [Coordinate systems](../appendices/coordinate-systems.md)).
+
+The `[*_]dwi.bval` file contains the *b*-values (in s/mm<sup>2</sup>)
+corresponding to the volumes in the relevant NIfTI file,
+with 0 designating *b*=0 volumes; space-delimited.
+
+Examples of `[*_]dwi.bvec` and `[*_]dwi.bval` files,
+corresponding to a NIfTI image with 6 volumes
+with the first two volumes having no diffusion sensitization:
+
+-   `[*_]dwi.bvec`:
+    ```Text
+    0 0 0.021828 -0.015425 -0.70918 -0.2465
+    0 0 0.80242 0.22098 -0.00063106 0.1043
+    0 0 -0.59636 0.97516 -0.70503 -0.96351
+    ```
+
+-   `[_]dwi.bval`:
+    ```Text
+    0 0 2000 2000 1000 1000
+    ```
 
 ### Multipart (split) DWI schemes
 
-Some MR schemes cannot be acquired directly by some scanner devices, requiring
-to generate several DWI runs that were originally meant to belong in a single
-one. For instance, some GE scanners cannot collect more than &asymp;160 volumes
-in a single run under fast-changing gradients, so acquiring _HCP-style_
-diffusion images will require splitting the DWI scheme in several runs. Because
-researchers will generally optimize the data splits, these will likely not be
-able to be directly concatenated. BIDS permits defining arbitrary groupings of
-these multipart scans with the following metadata:
+Some MR schemes cannot be acquired directly by some scanner devices,
+requiring to generate several DWI runs that were originally meant to belong
+in a single one.
+For instance, some GE scanners cannot collect more than &asymp;160 volumes
+in a single run under fast-changing gradients, so acquiring *HCP-style*
+diffusion images will require splitting the DWI scheme in several runs.
+Because researchers will generally optimize the data splits, these will likely
+not be able to be directly concatenated.
+BIDS permits defining arbitrary groupings of these multipart scans with the
+following metadata:
 
 <!-- This block generates a metadata table.
 These tables are defined in
@@ -842,7 +810,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("dwi.MRIDiffusionMultipart") }}
 
 JSON example:
@@ -853,16 +820,15 @@ JSON example:
 }
 ```
 
-For instance, if there are two phase-encoding directions (`AP`, `PA`), and two
-runs each, and the intent of the researcher is that all of them are part of a
-unique multipart scan, then they will tag all four runs with the same
-`MultipartID` (shown at the right-hand side of the file listing):
+For instance, if there are two phase-encoding directions (`AP`, `PA`), and
+two runs each, and the intent of the researcher is that all of them are
+part of a unique multipart scan, then they will tag all four runs with the
+same `MultipartID` (shown at the right-hand side of the file listing):
 
 <!-- This block generates a file tree.
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
    "sub-1": {
@@ -876,14 +842,13 @@ A guide for using macros can be found at
    }
 ) }}
 
-If, conversely, the researcher wanted to store two multipart scans, one
-possibility is to combine matching phase-encoding directions:
+If, conversely, the researcher wanted to store two multipart scans, one possibility
+is to combine matching phase-encoding directions:
 
 <!-- This block generates a file tree.
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
    "sub-1": {
@@ -904,7 +869,6 @@ runs instead:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
    "sub-1": {
@@ -925,7 +889,6 @@ The `MultipartID` metadata MAY be used with the
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
    "sub-1": {
@@ -941,11 +904,11 @@ A guide for using macros can be found at
 
 ### Other RECOMMENDED metadata
 
-The `PhaseEncodingDirection` and `TotalReadoutTime` metadata fields are
-RECOMMENDED to enable the correction of geometrical distortions with
-[fieldmap information](#fieldmap-data). See
-[Common metadata fields](#common-metadata-fields) for a list of additional terms
-that can be included in the corresponding JSON file.
+The `PhaseEncodingDirection` and `TotalReadoutTime` metadata
+fields are RECOMMENDED to enable the correction of geometrical distortions
+with [fieldmap information](#fieldmap-data).
+See [Common metadata fields](#common-metadata-fields) for a list of
+additional terms that can be included in the corresponding JSON file.
 
 JSON example:
 
@@ -972,23 +935,20 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["perf"]) }}
 
-The complete ASL time series should be stored as a 4D NIfTI file in the original
-acquisition order, accompanied by two ancillary files: `*_asl.json` and
-`*_aslcontext.tsv`.
+The complete ASL time series should be stored as a 4D NIfTI file in the original acquisition order,
+accompanied by two ancillary files: `*_asl.json` and `*_aslcontext.tsv`.
 
 ### `*_aslcontext.tsv`
 
-The `*_aslcontext.tsv` table consists of a single column of labels identifying
-the `volume_type` of each volume in the corresponding `*_asl.nii[.gz]` file.
-Volume types are defined in the following table, based on DICOM Tag 0018, 9257
-`ASL Context`. Note that the volume_types `control` and `label` within BIDS only
-serve to specify the magnetization state of the blood and thus the ASL
-subtraction order. See the
-[ASL Appendix](../appendices/arterial-spin-labeling.md#which-image-is-control-and-which-is-label)
-for more information on `control` and `label`.
+The `*_aslcontext.tsv` table consists of a single column of labels identifying the
+`volume_type` of each volume in the corresponding `*_asl.nii[.gz]` file.
+Volume types are defined in the following table, based on DICOM Tag 0018, 9257 `ASL Context`.
+Note that the volume_types `control` and  `label` within BIDS only serve
+to specify the magnetization state of the blood and thus the ASL subtraction order.
+See the [ASL Appendix](../appendices/arterial-spin-labeling.md#which-image-is-control-and-which-is-label)
+for more information on `control` and  `label`.
 
 | **volume_type** | **Definition**                                                                                                                                                                         |
 | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -1000,52 +960,50 @@ for more information on `control` and `label`.
 | `noRF`          | No radio frequency excitation (noRF) images are produced by disabling the radio frequency excitation, while maintaining all other parameters from the associated scan.                 |
 | `n/a`           | In some cases, there may be volume types that are not yet supported by BIDS, or which cannot be used by tools.                                                                         |
 
-If the `control` and `label` images are not available, their derivative `deltam`
-should be stored within the `*_asl.nii[.gz]` and specified in the
-`*_aslcontext.tsv` instead. If the `deltam` is not available, `cbf` should be
-stored within the `*_asl.nii[.gz]` and specified in the `*_aslcontext.tsv`. When
-`cbf` is stored within the `*_asl.nii[.gz]`, its units need to be specified in
-the `*_asl.json` as well. Note that the raw images, including the `m0scan`, may
-also be used for quality control. See the
-[ASL Appendix](../appendices/arterial-spin-labeling.md#_aslcontexttsv-three-possible-cases)
+If the `control` and `label` images are not available,
+their derivative `deltam` should be stored within the `*_asl.nii[.gz]`
+and specified in the `*_aslcontext.tsv` instead.
+If the `deltam` is not available,
+`cbf` should be stored within the `*_asl.nii[.gz]` and specified in the `*_aslcontext.tsv`.
+When `cbf` is stored within the `*_asl.nii[.gz]`,
+its units need to be specified in the `*_asl.json` as well.
+Note that the raw images, including the `m0scan`, may also be used for quality control.
+See the [ASL Appendix](../appendices/arterial-spin-labeling.md#_aslcontexttsv-three-possible-cases)
 for examples of the three possible cases, in order of decreasing preference.
 
 ### Scaling
 
-The `*_asl.nii.gz` and `*_m0scan.nii.gz` should contain appropriately scaled
-data, and no additional scaling factors are allowed other than the scale slope
-in the respective NIfTI headers.
+The `*_asl.nii.gz` and `*_m0scan.nii.gz` should contain appropriately scaled data,
+and no additional scaling factors are allowed other than the scale slope in the respective
+NIfTI headers.
 
 ### `*_asllabeling.*`
 
-A deidentified screenshot of the planning of the labeling slab/plane with
-respect to the imaging slab or slices. This screenshot is based on DICOM macro
-C.8.13.5.14.
+A deidentified screenshot of the planning of the labeling slab/plane
+with respect to the imaging slab or slices.
+This screenshot is based on DICOM macro C.8.13.5.14.
 
-See
-[`LabelingLocationDescription`](../glossary.md#labelinglocationdescription-metadata)
-for more details.
+See [`LabelingLocationDescription`](../glossary.md#labelinglocationdescription-metadata) for more details.
 
 ### M0
 
-The `m0scan` can either be stored inside the 4D ASL time-series NIfTI file or as
-a separate NIfTI file, depending on whether it was acquired within the ASL
-time-series or as a separate scan. These and other M0 options are specified in
-the REQUIRED `M0Type` field of the `*_asl.json` file. It can also be stored
-under
+The `m0scan` can either be stored inside the 4D ASL time-series NIfTI file
+or as a separate NIfTI file,
+depending on whether it was acquired within the ASL time-series or as a separate scan.
+These and other M0 options are specified in the REQUIRED `M0Type` field of the `*_asl.json` file.
+It can also be stored under
 `fmap/sub-<label>[_ses-<label>][_acq-<label>][_ce-<label>]_dir-<label>[_run-<index>]_m0scan.nii[.gz]`,
-when the [pepolar approach](#case-4-multiple-phase-encoded-directions-pepolar)
-is used.
+when the [pepolar approach](#case-4-multiple-phase-encoded-directions-pepolar) is used.
 
 ### `*_asl.json` file
 
-Depending on the method used for ASL acquisition ((P)CASL or PASL) different
-metadata fields are applicable. Additionally, some common metadata fields are
-REQUIRED for the `*_asl.json`: `MagneticFieldStrength`, `MRAcquisitionType`,
-`EchoTime`, `SliceTiming` in case `MRAcquisitionType` is defined as 2D,
-`RepetitionTimePreparation`, and `FlipAngle` in case `LookLocker` is `true`. See
-the
-[ASL Appendix](../appendices/arterial-spin-labeling.md#summary-image-of-the-most-common-asl-sequences)
+Depending on the method used for ASL acquisition ((P)CASL or PASL)
+different metadata fields are applicable.
+Additionally, some common metadata fields are REQUIRED for the `*_asl.json`:
+`MagneticFieldStrength`, `MRAcquisitionType`, `EchoTime`,
+`SliceTiming` in case `MRAcquisitionType` is defined as 2D,
+`RepetitionTimePreparation`, and `FlipAngle` in case `LookLocker` is `true`.
+See the [ASL Appendix](../appendices/arterial-spin-labeling.md#summary-image-of-the-most-common-asl-sequences)
 for more information on the most common ASL sequences.
 
 #### Common metadata fields applicable to both (P)CASL and PASL
@@ -1058,15 +1016,11 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table(["asl.MRIASLCommonMetadataFields", "asl.MRIASLCommonMetadataFieldsM0TypeRec", "asl.MRIASLCommonMetadataFieldsBackgroundSuppressionOpt", "asl.MRIASLCommonMetadataFieldsVascularCrushingOpt", ]) }}
 
 #### (P)CASL-specific metadata fields
 
-These fields can only be used when `ArterialSpinLabelingType` is `"CASL"` or
-`"PCASL"`. See the
-[ASL Appendix](../appendices/arterial-spin-labeling.md#pcasl-sequence) for more
-information on the (P)CASL sequence and the Labeling Pulse fields.
+These fields can only be used when `ArterialSpinLabelingType` is `"CASL"` or `"PCASL"`. See the [ASL Appendix](../appendices/arterial-spin-labeling.md#pcasl-sequence) for more information on the (P)CASL sequence and the Labeling Pulse fields.
 
 <!-- This block generates a metadata table.
 These tables are defined in
@@ -1076,7 +1030,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table([
        "asl.MRIASLPcaslSpecific",
        "asl.MRIASLCaslSpecific",
@@ -1085,9 +1038,9 @@ A guide for using macros can be found at
 
 #### PASL-specific metadata fields
 
-These fields can only be used when `ArterialSpinLabelingType` is `PASL`. See the
-[ASL Appendix](../appendices/arterial-spin-labeling.md#pasl-sequence) for more
-information on the PASL sequence and the BolusCutOff fields.
+These fields can only be used when `ArterialSpinLabelingType` is `PASL`.
+See the [ASL Appendix](../appendices/arterial-spin-labeling.md#pasl-sequence)
+for more information on the PASL sequence and the BolusCutOff fields.
 
 <!-- This block generates a metadata table.
 These tables are defined in
@@ -1097,13 +1050,11 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table(["asl.MRIASLPaslSpecific", "asl.MRIASLPASLSpecificBolusCutOffFlagFalse"]) }}
 
 ### `m0scan` metadata fields
 
-Some common metadata fields are REQUIRED for the `*_m0scan.json`: `EchoTime`,
-`RepetitionTimePreparation`, and `FlipAngle` in case `LookLocker` is `true`.
+Some common metadata fields are REQUIRED for the `*_m0scan.json`: `EchoTime`, `RepetitionTimePreparation`, and `FlipAngle` in case `LookLocker` is `true`.
 
 <!-- This block generates a metadata table.
 These tables are defined in
@@ -1113,14 +1064,11 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("asl.MRIASLM0Scan") }}
 
-The following table recapitulates the ASL field dependencies. If Source field
-(column 1) contains the Value specified in column 2, then the Requirements in
-column 4 are imposed on the Dependent fields in column 3. See the
-[ASL Appendix](../appendices/arterial-spin-labeling.md#flowchart-based-on-dependency-table)
-for this information in the form of flowcharts.
+The following table recapitulates the ASL field dependencies. If Source field (column 1) contains the Value specified in column 2, then the Requirements in column 4 are
+imposed on the Dependent fields in column 3. See the [ASL Appendix](../appendices/arterial-spin-labeling.md#flowchart-based-on-dependency-table) for this information in the
+form of flowcharts.
 
 | **Source field**         | **Value**    | **Dependent field**  | **Requirements**                                 |
 | ------------------------ | ------------ | -------------------- | ------------------------------------------------ |
@@ -1130,29 +1078,28 @@ for this information in the form of flowcharts.
 | ArterialSpinLabelingType | PASL         | BolusCutOffFlag      | \[X\]                                            |
 | BolusCutOffFlag          | true / false | BolusCutOffDelayTime | \[X\] / \[\]                                     |
 | BolusCutOffFlag          | true / false | BolusCutOffTechnique | \[X\] / \[\]                                     |
-| M0Type                   | Separate     | \*/perf/             | contains `*_m0scan.nii[.gz]` and `*_m0scan.json` |
-| M0Type                   | Included     | \*\_aslcontext.tsv   | contains m0scan                                  |
+| M0Type                   | Separate     | */perf/              | contains `*_m0scan.nii[.gz]` and `*_m0scan.json` |
+| M0Type                   | Included     | *_aslcontext.tsv     | contains m0scan                                  |
 | M0Type                   | Estimate     | M0Estimate           | \[X\]                                            |
 | `*_aslcontext.tsv`       | cbf          | Units                | \[X\]                                            |
 
 **Legend**
 
-- \[ X ] --> MUST be defined
-- \[ \] --> MUST NOT be defined
+-   \[ X ] --> MUST be defined
+-   \[   \] --> MUST NOT be defined
 
 ## Fieldmap data
 
-Data acquired to correct for _B<sub>0</sub>_ inhomogeneities can come in
-different forms. The current version of this standard considers four different
-scenarios:
+Data acquired to correct for *B<sub>0</sub>* inhomogeneities can come in different forms.
+The current version of this standard considers four different scenarios:
 
 1.  [Phase-difference map](#case-1-phase-difference-map-and-at-least-one-magnitude-image)
 1.  [Two phase maps](#case-2-two-phase-maps-and-two-magnitude-images)
-1.  [Direct _field mapping_](#case-3-direct-field-mapping)
-1.  ["_PEpolar_" fieldmaps](#case-4-multiple-phase-encoded-directions-pepolar)
+1.  [Direct *field mapping*](#case-3-direct-field-mapping)
+1.  ["*PEpolar*" fieldmaps](#case-4-multiple-phase-encoded-directions-pepolar)
 
-These four different types of field mapping strategies can be encoded using the
-following image types:
+These four different types of field mapping strategies can be encoded
+using the following image types:
 
 <!--
 This block generates a suffix table.
@@ -1161,7 +1108,6 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_suffix_table(
       [
          "magnitude",
@@ -1179,18 +1125,19 @@ and a guide for using macros can be found at
 ### Expressing the MR protocol intent for fieldmaps
 
 Fieldmaps are typically acquired with the purpose of correcting one or more EPI
-scans under `dwi/`, `func/`, or `perf/` for distortions derived from
-_B<sub>0</sub>_ nonuniformity.
+scans under `dwi/`, `func/`, or `perf/` for distortions derived from *B<sub>0</sub>*
+nonuniformity.
 
 #### Using `B0FieldIdentifier` metadata
 
-The general purpose
-[`B0FieldIdentifier` MRI metadata](#echo-planar-imaging-and-b0-mapping) is
-RECOMMENDED for the prescription of the _B<sub>0</sub>_ field estimation intent
-of the original acquisition protocol. `B0FieldIdentifier` and `B0FieldSource`
-duplicate the capabilities of the original `IntendedFor` approach (see below),
-while permitting more complex use cases. It is RECOMMENDED to use both
-approaches to maintain compatibility with tools that support older datasets.
+The general purpose [`B0FieldIdentifier` MRI metadata](#echo-planar-imaging-and-b0-mapping)
+is RECOMMENDED for the prescription of the *B<sub>0</sub>* field estimation intent of the
+original acquisition protocol.
+`B0FieldIdentifier` and `B0FieldSource` duplicate the capabilities of
+the original `IntendedFor` approach (see below), while permitting more
+complex use cases.
+It is RECOMMENDED to use both approaches to maintain compatibility with
+tools that support older datasets.
 
 #### Using `IntendedFor` metadata
 
@@ -1205,7 +1152,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("fmap.MRIFieldmapIntendedFor") }}
 
 For example:
@@ -1239,12 +1185,12 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["fmap"], suffixes=["phasediff", "magnitude1", "magnitude2"]) }}
 
-where the REQUIRED `_phasediff` image corresponds to the phase-drift map between
-echo times, the REQUIRED `_magnitude1` image corresponds to the shorter echo
-time, and the OPTIONAL `_magnitude2` image to the longer echo time.
+where
+the REQUIRED `_phasediff` image corresponds to the phase-drift map between echo times,
+the REQUIRED `_magnitude1` image corresponds to the shorter echo time, and
+the OPTIONAL `_magnitude2` image to the longer echo time.
 
 Required fields:
 
@@ -1256,13 +1202,13 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("fmap.MRIFieldmapPhaseDifferencePhasediff") }}
 
 In this particular case, the sidecar JSON file
-`sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_phasediff.json` MUST
-define the time of two echos used to map the phase and finally calculate the
-phase-difference map. For example:
+`sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_phasediff.json`
+MUST define the time of two echos used to map the phase and finally calculate
+the phase-difference map.
+For example:
 
 ```JSON
 {
@@ -1275,8 +1221,8 @@ phase-difference map. For example:
 #### Case 2: Two phase maps and two magnitude images
 
 Similar to case 1, but instead of a precomputed phase-difference map, two
-separate phase images and two magnitude images corresponding to first and second
-echos are available.
+separate phase images and two magnitude images corresponding to first and
+second echos are available.
 
 <!--
 This block generates a filename templates.
@@ -1285,7 +1231,6 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["fmap"], suffixes=["phase1", "phase2", "magnitude1", "magnitude2"]) }}
 
 Required fields:
@@ -1298,12 +1243,10 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("fmap.MRIFieldmapTwoPhase") }}
 
-Each phase map has a corresponding sidecar JSON file to specify its
-corresponding `EchoTime`. For example,
-`sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_phase2.json` may read:
+Each phase map has a corresponding sidecar JSON file to specify its corresponding `EchoTime`.
+For example, `sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_phase2.json` may read:
 
 ```JSON
 {
@@ -1312,11 +1255,10 @@ corresponding `EchoTime`. For example,
 }
 ```
 
-#### Case 3: Direct _field mapping_
+#### Case 3: Direct *field mapping*
 
 In some cases (for example GE), the scanner software will directly reconstruct a
-_B<sub>0</sub>_ field map along with a magnitude image used for anatomical
-reference.
+*B<sub>0</sub>* field map along with a magnitude image used for anatomical reference.
 
 <!--
 This block generates a filename templates.
@@ -1325,7 +1267,6 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["fmap"], suffixes=["fieldmap", "magnitude"]) }}
 
 Required fields:
@@ -1338,7 +1279,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("fmap.MRIFieldmapDirectFieldMapping") }}
 
 For example:
@@ -1351,8 +1291,8 @@ For example:
 }
 ```
 
-See [Using `IntendedFor` metadata](#using-intendedfor-metadata) for details on
-the `IntendedFor` field.
+See [Using `IntendedFor` metadata](#using-intendedfor-metadata)
+for details on the `IntendedFor` field.
 
 #### Case 4: Multiple phase encoded directions ("pepolar")
 
@@ -1365,12 +1305,12 @@ the `IntendedFor` field.
 
 The phase-encoding polarity (PEpolar) technique combines two or more Spin Echo
 EPI scans with different phase encoding directions to estimate the distortion
-map corresponding to the nonuniformities of the _B<sub>0</sub>_ field. These
-`*_epi.nii[.gz]` - or `*_m0scan.nii[.gz]` for arterial spin labeling perfusion
-data - files can be 3D or 4D -- in the latter case, all timepoints share the
-same scanning parameters. Some 4D scans intended for correcting DWIs may have
-accompanying `*_epi.bval` and `*_epi.bvec` files. Examples of software tools
-using these kinds of images are FSL TOPUP and AFNI `3dqwarp`.
+map corresponding to the nonuniformities of the *B<sub>0</sub>* field.
+These `*_epi.nii[.gz]` - or `*_m0scan.nii[.gz]` for arterial spin labeling perfusion data - files can be 3D or 4D --
+in the latter case, all timepoints share the same scanning parameters.
+Some 4D scans intended for correcting DWIs may have accompanying `*_epi.bval` and `*_epi.bvec` files.
+Examples of software tools using these kinds of images are FSL TOPUP and
+AFNI `3dqwarp`.
 
 <!--
 This block generates a filename templates.
@@ -1379,13 +1319,13 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["fmap"], suffixes=["epi"]) }}
 
-The [`dir-<label>`](../appendices/entities.md#dir) entity is REQUIRED for these
-files. This entity MUST be used in addition to the REQUIRED
-`PhaseEncodingDirection` metadata field (see
-[Filename structure](../common-principles.md#filenames)).
+The [`dir-<label>`](../appendices/entities.md#dir) entity is REQUIRED
+for these files.
+This entity MUST be used in addition to
+the REQUIRED `PhaseEncodingDirection` metadata field
+(see [Filename structure](../common-principles.md#filenames)).
 
 Required fields:
 
@@ -1397,7 +1337,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("fmap.MRIFieldmapPepolar") }}
 
 For example:
@@ -1411,10 +1350,10 @@ For example:
 }
 ```
 
-See [Using `IntendedFor` metadata](#using-intendedfor-metadata) for details on
-the `IntendedFor` field.
+See [Using `IntendedFor` metadata](#using-intendedfor-metadata)
+for details on the `IntendedFor` field.
 
 As for other EPI sequences, these field mapping sequences may have any of the
-[in-plane spatial encoding](#in-and-out-of-plane-spatial-encoding) metadata
-keys. However, please note that `PhaseEncodingDirection` and `TotalReadoutTime`
-keys are REQUIRED for these field mapping sequences.
+[in-plane spatial encoding](#in-plane-spatial-encoding) metadata keys.
+However, please note that `PhaseEncodingDirection` and `TotalReadoutTime` keys
+are REQUIRED for these field mapping sequences.
diff --git a/src/modality-specific-files/magnetoencephalography.md b/src/modality-specific-files/magnetoencephalography.md
index 197924b271..ced4d6f3e7 100644
--- a/src/modality-specific-files/magnetoencephalography.md
+++ b/src/modality-specific-files/magnetoencephalography.md
@@ -1,9 +1,10 @@
 # Magnetoencephalography
 
 Support for Magnetoencephalography (MEG) was developed as a
-[BIDS Extension Proposal](../extensions.md#bids-extension-proposals). Please see
-[Citing BIDS](../introduction.md#citing-bids) on how to appropriately credit
-this extension when referring to it in the context of the academic literature.
+[BIDS Extension Proposal](../extensions.md#bids-extension-proposals).
+Please see [Citing BIDS](../introduction.md#citing-bids)
+on how to appropriately credit this extension when referring to it in the
+context of the academic literature.
 
 !!! example "Example datasets"
 
@@ -24,7 +25,6 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template(
    "raw",
    datatypes=["meg"],
@@ -32,13 +32,14 @@ and a guide for using macros can be found at
 }}
 
 Unprocessed MEG data MUST be stored in the native file format of the MEG
-instrument with which the data was collected. With the MEG specification of
-BIDS, we wish to promote the adoption of good practices in the management of
-scientific data. Hence, the emphasis is not to impose a new, generic data format
-for the modality, but rather to standardize the way data is stored in
-repositories. Further, there is currently no widely accepted standard file
-format for MEG, but major software applications, including free and open-source
-solutions for MEG data analysis, provide readers of such raw files.
+instrument with which the data was collected.
+With the MEG specification of BIDS, we wish to promote the adoption of good
+practices in the management of scientific data.
+Hence, the emphasis is not to impose a new, generic data format for the
+modality, but rather to standardize the way data is stored in repositories.
+Further, there is currently no widely accepted standard file format for MEG, but
+major software applications, including free and open-source solutions for MEG
+data analysis, provide readers of such raw files.
 
 Some software readers may skip important metadata that is specific to MEG system
 manufacturers. It is therefore RECOMMENDED that users provide additional meta
@@ -48,69 +49,69 @@ without the need to parse files in proprietary data format. Other relevant files
 MAY be included alongside the MEG data; examples are provided below.
 
 This template is for MEG data of any kind, including but not limited to
-task-based, resting-state, and noise recordings. If multiple _Tasks_ were
-performed within a single _Run_, the task description can be set to
-`task-multitask`. The `*_meg.json` file SHOULD contain details on the _Tasks_.
+task-based, resting-state, and noise recordings.
+If multiple *Tasks* were performed within a single *Run*,
+the task description can be set to `task-multitask`.
+The `*_meg.json` file SHOULD contain details on the *Tasks*.
 
 Some manufacturers' data storage conventions use directories which contain data
-files of various nature: for example, CTF's `.ds` format, or BTi/4D's data
-directory. Yet other manufacturers split their files once they exceed a certain
-size limit. For example Neuromag/Elekta/Megin, which can produce several files
-for a single recording. Both `some_file.fif` and `some_file-1.fif` would belong
-to a single recording. In BIDS, the [`split`](../appendices/entities.md#split)
-entity is RECOMMENDED to deal with split files. If there are multiple parts of a
-recording and the optional `scans.tsv` is provided, remember to list all files
-separately in `scans.tsv` and that the entries for the `acq_time` column in
-`scans.tsv` MUST all be identical, as described in
+files of various nature: for example, CTF's `.ds` format, or BTi/4D's data directory.
+Yet other manufacturers split their files once they exceed a certain size
+limit.
+For example Neuromag/Elekta/Megin, which can produce several files
+for a single recording.
+Both `some_file.fif` and `some_file-1.fif` would belong to a single recording.
+In BIDS, the [`split`](../appendices/entities.md#split) entity is RECOMMENDED to deal
+with split files.
+If there are multiple parts of a recording and the optional `scans.tsv` is provided,
+remember to list all files separately in `scans.tsv` and that the entries for the
+`acq_time` column in `scans.tsv` MUST all be identical, as described in
 [Scans file](../modality-agnostic-files.md#scans-file).
 
 The Neuromag/Elekta/Megin system may also produce datasets that require a set of
-`crosstalk` and `calibration` files to be used properly (see also filename
-templates above). Please refer to
+`crosstalk` and `calibration` files to be used properly (see also filename templates above).
+Please refer to
 [Cross-talk and fine-calibration files](../appendices/meg-file-formats.md#cross-talk-and-fine-calibration-files)
 for more information on this detail.
 
 Another manufacturer-specific detail pertains to the KIT/Yokogawa/Ricoh system,
-which saves the MEG sensor coil positions in a separate file with two possible
-filename extensions (`.sqd`, `.mrk`). For these files, the `markers` suffix MUST
-be used. For example: `sub-01_task-nback_markers.sqd`
+which saves the MEG sensor coil positions in a separate file with two possible filename extensions  (`.sqd`, `.mrk`).
+For these files, the `markers` suffix MUST be used.
+For example: `sub-01_task-nback_markers.sqd`
 
-Please refer to the
-[MEG File Formats Appendix](../appendices/meg-file-formats.md) for general
-information on how to deal with such manufacturer specifics and to see more
-examples.
+Please refer to the [MEG File Formats Appendix](../appendices/meg-file-formats.md)
+for general information on how to deal with such manufacturer specifics and to see more examples.
 
 The [`proc-<label>`](../appendices/entities.md#proc) entity is analogous to the
-[`rec-<label>`](../appendices/entities.md#rec) entity for MRI, and denotes a
-variant of a file that was a result of particular processing performed on the
-device. This is useful for files produced in particular by
-Neuromag/Elekta/MEGIN's MaxFilter (for example, sss, tsss, trans, quat, mc),
-which some installations impose to be run on raw data prior to analysis. Such
-processing steps are needed for example because of active shielding software
-corrections that have to be performed to before the MEG data can actually be
-exploited.
+[`rec-<label>`](../appendices/entities.md#rec) entity for MRI,
+and denotes a variant of a file that was a result of particular processing performed on the device.
+This is useful for files produced in particular by Neuromag/Elekta/MEGIN's MaxFilter
+(for example, sss, tsss, trans, quat, mc),
+which some installations impose to be run on raw data prior to analysis.
+Such processing steps are needed for example because of active shielding software corrections
+that have to be performed to before the MEG data can actually be exploited.
 
 ### Recording (i)EEG simultaneously with MEG
 
-Note that if (i)EEG is recorded with a separate amplifier, it SHOULD be stored
-separately under a new `/eeg` data type (see the
-[EEG](electroencephalography.md) and
+Note that if (i)EEG is recorded with a separate amplifier,
+it SHOULD be stored separately under a new `/eeg` data type
+(see the [EEG](electroencephalography.md) and
 [iEEG](intracranial-electroencephalography.md) specifications).
 
-If however (i)EEG is recorded simultaneously **with the same MEG system**, it
-MAY be stored under the `/meg` data type. In that case, it SHOULD have the same
-sampling frequency as MEG (see `SamplingFrequency` field below). Furthermore,
-(i)EEG sensor coordinates MAY be recorded in an
+If however (i)EEG is recorded simultaneously **with the same MEG system**,
+it MAY be stored under the `/meg` data type.
+In that case, it SHOULD have the same sampling frequency as MEG (see `SamplingFrequency` field below).
+Furthermore, (i)EEG sensor coordinates MAY be recorded in an
 [`electrodes.tsv`](electroencephalography.md#electrodes-description-_electrodestsv)
-file using MEG-specific coordinate systems (see
-[Coordinate System JSON](#coordinate-system-json-_coordsystemjson) below and the
-[Coordinate Systems Appendix](../appendices/coordinate-systems.md)).
+file using MEG-specific coordinate systems
+(see [Coordinate System JSON](#coordinate-system-json-_coordsystemjson) below and
+the [Coordinate Systems Appendix](../appendices/coordinate-systems.md)).
 
 ### Sidecar JSON (`*_meg.json`)
 
-For consistency between studies and institutions, we encourage users to extract
-the values of metadata fields from the actual raw data. Whenever possible,
-please avoid using ad hoc wording.
+For consistency between studies and institutions,
+we encourage users to extract the values of metadata fields from the actual raw data.
+Whenever possible, please avoid using ad hoc wording.
 
 Those fields MUST be present:
 
@@ -122,7 +123,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("meg.MEGRequired") }}
 
 Those fields SHOULD be present:
@@ -135,7 +135,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("meg.MEGRecommended") }}
 
 These fields MAY be present:
@@ -148,7 +147,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("meg.MEGOptional") }}
 
 #### Hardware information
@@ -161,7 +159,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("meg.MEGHardware") }}
 
 #### Task information
@@ -174,7 +171,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("meg.MEGTaskInformation") }}
 
 #### Institution information
@@ -187,13 +183,11 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("meg.MEGInstitutionInformation") }}
 
 #### Specific EEG fields
 
-If recorded with MEG, see
-[Recording EEG simultaneously with MEG](#recording-ieeg-simultaneously-with-meg)
+If recorded with MEG, see [Recording EEG simultaneously with MEG](#recording-eeg-simultaneously-with-meg)
 SHOULD be present:
 
 <!-- This block generates a metadata table.
@@ -204,7 +198,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_sidecar_table("meg.MEGwithEEG") }}
 
 #### Example `*_meg.json`
@@ -241,9 +234,8 @@ A guide for using macros can be found at
 ```
 
 Note that the date and time information SHOULD be stored in the Study key file
-(`scans.tsv`), see [Scans file](../modality-agnostic-files.md#scans-file). Date
-time information MUST be expressed as indicated in
-[Units](../common-principles.md#units)
+(`scans.tsv`), see [Scans file](../modality-agnostic-files.md#scans-file).
+Date time information MUST be expressed as indicated in [Units](../common-principles.md#units)
 
 ## Channels description (`*_channels.tsv`)
 
@@ -254,15 +246,13 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["meg"], suffixes=["channels"]) }}
 
-This file is RECOMMENDED as it provides easily searchable information across
-BIDS datasets. For example for general curation, response to queries, or for
-batch analysis. To avoid confusion, the channels SHOULD be listed in the order
-they appear in the MEG data file. Any number of additional columns MAY be added
-to provide additional information about the channels. Missing values MUST be
-indicated with `"n/a"`.
+This file is RECOMMENDED as it provides easily searchable information across BIDS datasets.
+For example for general curation, response to queries, or for batch analysis.
+To avoid confusion, the channels SHOULD be listed in the order they appear in the MEG data file.
+Any number of additional columns MAY be added to provide additional information about the channels.
+Missing values MUST be indicated with `"n/a"`.
 
 The columns of the channels description table stored in `*_channels.tsv` are:
 
@@ -272,10 +262,10 @@ The definitions of these fields can be found in
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_columns_table("meg.MEGChannels") }}
 
-Restricted keyword list for field `type`. Note that upper-case is REQUIRED:
+Restricted keyword list for field `type`.
+Note that upper-case is REQUIRED:
 
 | **Keyword**      | **Description**                                              |
 | ---------------- | ------------------------------------------------------------ |
@@ -310,14 +300,14 @@ Restricted keyword list for field `type`. Note that upper-case is REQUIRED:
 
 Examples of free text for field `description`:
 
-- stimulus
-- response
-- vertical EOG
-- horizontal EOG
-- skin conductance
-- sats
-- intracranial
-- eyetracker
+-   stimulus
+-   response
+-   vertical EOG
+-   horizontal EOG
+-   skin conductance
+-   sats
+-   intracranial
+-   eyetracker
 
 ### Example `*_channels.tsv`
 
@@ -338,7 +328,6 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["meg"], suffixes=["coordsystem"]) }}
 
 OPTIONAL. A JSON document specifying the coordinate system(s) used for the MEG,
@@ -354,7 +343,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_json_table("json.meg.MEGCoordsystemWithEEG") }}
 
 Head localization coils:
@@ -367,7 +355,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_json_table("json.meg.MEGCoordsystemHeadLocalizationCoils") }}
 
 Digitized head points:
@@ -380,7 +367,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_json_table("json.meg.MEGCoordsystemDigitizedHeadPoints") }}
 
 Anatomical MRI:
@@ -393,7 +379,6 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_json_table("json.meg.MEGCoordsystemAnatomicalMRI") }}
 
 Anatomical landmarks:
@@ -406,24 +391,23 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_json_table("json.meg.MEGCoordsystemAnatomicalLandmarks") }}
 
 It is also RECOMMENDED that the MRI voxel coordinates of the actual anatomical
 landmarks for co-registration of MEG with structural MRI are stored in the
 `AnatomicalLandmarkCoordinates` field in the JSON sidecar of the corresponding
-T1w MRI anatomical data of the subject seen in the MEG session (see
-[Anatomy Imaging Data](magnetic-resonance-imaging-data.md#anatomy-imaging-data)).
+T1w MRI anatomical data of the subject seen in the MEG session
+(see [Anatomy Imaging Data](magnetic-resonance-imaging-data.md#anatomy-imaging-data)).
 
 For example: `"sub-01/ses-mri/anat/sub-01_ses-mri_acq-mprage_T1w.json"`
 
 In principle, these locations are those of absolute anatomical markers. However,
-the marking of NAS, LPA and RPA is more ambiguous than that of for example, AC
-and PC. This may result in some variability in their 3-D digitization from
-session to session, even for the same participant. The solution would be to use
-only one T1w file and populate the `AnatomicalLandmarkCoordinates` field with
-session-specific labels for example, "NAS-session1":
-`[127,213,139]`,"NAS-session2": `[123,220,142]`.
+the marking of NAS, LPA and RPA is more ambiguous than that of for example, AC and PC.
+This may result in some variability in their 3-D digitization from session to
+session, even for the same participant. The solution would be to use only one
+T1w file and populate the `AnatomicalLandmarkCoordinates` field with
+session-specific labels for example, "NAS-session1": `[127,213,139]`,"NAS-session2":
+`[123,220,142]`.
 
 Fiducials information:
 
@@ -435,22 +419,20 @@ The definitions of the fields specified in these tables may be found in
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_json_table("json.meg.MEGCoordsystemFiducialsInformation") }}
 
 For more information on the definition of anatomical landmarks, please visit:
-[How are the Left and Right Pre-Auricular (LPA and RPA) points defined? - FieldTrip Toolbox](https://www.fieldtriptoolbox.org/faq/how_are_the_lpa_and_rpa_points_defined/)
+    [How are the Left and Right Pre-Auricular (LPA and RPA) points defined? - FieldTrip Toolbox](https://www.fieldtriptoolbox.org/faq/how_are_the_lpa_and_rpa_points_defined/)
 
 For more information on typical coordinate systems for MEG-MRI coregistration:
-[How are the different head and MRI coordinate systems defined? - FieldTrip Toolbox](https://www.fieldtriptoolbox.org/faq/coordsys/)
+    [How are the different head and MRI coordinate systems defined? - FieldTrip Toolbox](https://www.fieldtriptoolbox.org/faq/coordsys/)
 or:
 [Coordinate Systems - Brainstorm toolbox](https://neuroimage.usc.edu/brainstorm/CoordinateSystems)
 
-`*_coordsystem.json` files SHOULD NOT be duplicated for each data file, for
-example, across multiple tasks. The
-[inheritance principle](../common-principles.md#the-inheritance-principle) MUST
-be used to find the appropriate coordinate system description for a given data
-file.
+`*_coordsystem.json` files SHOULD NOT be duplicated for each data file,
+for example, across multiple tasks.
+The [inheritance principle](../common-principles.md#the-inheritance-principle) MUST
+be used to find the appropriate coordinate system description for a given data file.
 
 ## Landmark photos (`*_photo.<extension>`)
 
@@ -464,7 +446,6 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["meg"], suffixes=["photo"]) }}
 
 Photos of the anatomical landmarks and/or head localization coils on the
@@ -474,10 +455,9 @@ taped to the skin. Please note that the photos may need to be cropped or blurred
 to conceal identifying features prior to sharing, depending on the terms of the
 consent given by the participant.
 
-The [`acq-<label>`](../appendices/entities.md#acq) entity can be used to
-indicate acquisition of different photos of the same face (or other body part in
-different angles to show, for example, the location of the nasion (NAS) as
-opposed to the right periauricular point (RPA)).
+The [`acq-<label>`](../appendices/entities.md#acq) entity can be used to indicate acquisition of different photos of
+the same face (or other body part in different angles to show, for example, the
+location of the nasion (NAS) as opposed to the right periauricular point (RPA)).
 
 ### Example `*_photo.<extension>`
 
@@ -495,18 +475,16 @@ The inputs for this macro can be found in the directory
 and a guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filename_template("raw", datatypes=["meg"], suffixes=["headshape"]) }}
 
 This file is RECOMMENDED.
 
-The 3-D locations of points that describe the head shape and/or EEG electrode
-locations can be digitized and stored in separate files. The
-[`acq-<label>`](../appendices/entities.md#acq) entity can be used when more than
-one type of digitization in done for a session, for example when the head points
-are in a separate file from the EEG locations. These files are stored in the
-specific format of the 3-D digitizer's manufacturer (see the
-[MEG File Formats Appendix](../appendices/meg-file-formats.md)).
+The 3-D locations of points that describe the head shape and/or EEG
+electrode locations can be digitized and stored in separate files. The
+[`acq-<label>`](../appendices/entities.md#acq) entity can be used when more than one type of digitization in done for
+a session, for example when the head points are in a separate file from the EEG
+locations. These files are stored in the specific format of the 3-D digitizer's
+manufacturer (see the [MEG File Formats Appendix](../appendices/meg-file-formats.md)).
 
 For example:
 
@@ -514,7 +492,6 @@ For example:
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
    "sub-control01": {
@@ -532,43 +509,30 @@ has to be updated, then for MEG it could be considered to be a new session.
 
 ## Empty-room MEG recordings
 
-Empty-room MEG recordings capture the environmental and recording system's
-noise.
+Empty-room MEG recordings capture the environmental and recording system's noise.
 
-It is RECOMMENDED to explicitly specify which empty-room recording should be
-used with which experimental run(s) or session(s). This can be done via the
-[`AssociatedEmptyRoom`](../glossary.md#associatedemptyroom-metadata) field in
-the `*_meg.json` sidecar files.
+It is RECOMMENDED to explicitly specify which empty-room recording should be used with which experimental run(s) or session(s).
+This can be done via the [`AssociatedEmptyRoom`](../glossary.md#associatedemptyroom-metadata) field in the `*_meg.json` sidecar files.
 
-Empty-room recordings may be collected once per day, where a single empty-room
-recording may be shared between multiple subjects and/or sessions (see
-[Example 1](#example-1)). Empty-room recordings may also be collected for each
-individual experimental session (see [Example 2](#example-2)). In either case,
-the label for the [`task-<label>`](../appendices/entities.md#task) entity in the
-empty-room recording SHOULD be set to `noise`.
+Empty-room recordings may be collected once per day, where a single empty-room recording may be shared between multiple subjects and/or sessions (see [Example 1](#example-1)).
+Empty-room recordings may also be collected for each individual experimental session (see [Example 2](#example-2)).
+In either case, the label for the [`task-<label>`](../appendices/entities.md#task) entity in the empty-room recording SHOULD be set to `noise`.
 
 ### Example 1
 
 One empty-room recording per day, applying to all subjects for that day.
 
-In the case of empty-room recordings being associated with multiple subjects
-and/or sessions, it is RECOMMENDED to store the empty-room recording inside a
-subject directory named `sub-emptyroom`. If a
-[`session-<label>`](../appendices/entities.md#ses) entity is present, its label
-SHOULD be the date of the empty-room recording in the format `YYYYMMDD`, that is
-`ses-YYYYMMDD`. The `scans.tsv` file containing the date and time of the
-acquisition SHOULD also be included. The rationale is that this naming scheme
-will allow users to easily retrieve the empty-room recording that best matches a
-particular experimental session, based on date and time of the recording. It
-should be possible to query empty-room recordings just like usual subject
-recordings, hence all metadata sidecar files (such as the `channels.tsv`) file
-SHOULD be present as well.
+In the case of empty-room recordings being associated with multiple subjects and/or sessions,
+it is RECOMMENDED to store the empty-room recording inside a subject directory named `sub-emptyroom`.
+If a [`session-<label>`](../appendices/entities.md#ses) entity is present, its label SHOULD be the date of the empty-room recording in the format `YYYYMMDD`, that is `ses-YYYYMMDD`.
+The `scans.tsv` file containing the date and time of the acquisition SHOULD also be included.
+The rationale is that this naming scheme will allow users to easily retrieve the empty-room recording that best matches a particular experimental session, based on date and time of the recording.
+It should be possible to query empty-room recordings just like usual subject recordings, hence all metadata sidecar files (such as the `channels.tsv`) file SHOULD be present as well.
 
 <!-- This block generates a file tree.
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
    "sub-control01": {},
@@ -588,18 +552,15 @@ A guide for using macros can be found at
 
 ### Example 2
 
-One empty-room recording per each participant's session, stored within the
-session directory.
+One empty-room recording per each participant's session, stored within the session directory.
 
-In the case of empty-room recordings being collected for the individual
-experimental session, it is RECOMMENDED to store the empty-room recording along
-with that subject and session.
+In the case of empty-room recordings being collected for the individual experimental session,
+it is RECOMMENDED to store the empty-room recording along with that subject and session.
 
 <!-- This block generates a file tree.
 A guide for using macros can be found at
  https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
 -->
-
 {{ MACROS___make_filetree_example(
    {
    "sub-control01": {