[FIX] Typos and clarifications

src/02-common-principles.md

@@ -152,8 +152,8 @@ my_dataset/
     ...
 ```
 
-In this example **only the `rawdata` subfolder needs to be BIDS compliant**
-dataset. This specification does not prescribe anything about the contents of
+In this example **only the `rawdata` subfolder needs to a be BIDS compliant
+dataset**. This specification does not prescribe anything about the contents of
 `sourcedata` and `derivatives` folders in the above example - nor does it
 prescribe the `sourcedata`, `derivatives`, or `rawdata` folder names. The above
 example is just a convention that can be useful for organizing raw, source, and
@@ -218,7 +218,7 @@ apply to different runs and rec files. Also if the JSON file
 (`task-xyz_acq-test1_bold.json`) is defined at dataset top level directory, it
 will be applicable to all task runs with `test1` acquisition parameter.
 
-Example 3: Multiple json files at different levels for same task and acquisition parameters
+Example 3: Multiple JSON files at different levels for same task and acquisition parameters
 
 ```Text
 task-xyz_acq-test1_bold.json
@@ -236,7 +236,7 @@ at the top directory will apply to all bold runs. However, if there is a key
 with different value in the
 `sub-01/func/sub-01_task-xyz_acq-test1_bold.json` file defined at a
 deeper level, that value will be applicable for that particular run/task NIfTI
-file/s. In other words, the `json` file at the deeper level overrides values
+file/s. In other words, the `.json` file at the deeper level overrides values
 that are potentially also defined in the `.json` at a more shallow level. If the
 `.json` file at the more shallow level contains key-value-pairs that are not
 present in the `.json` file at the deeper level, these key-value-pairs are
@@ -271,7 +271,7 @@ NIfTI header.
 
 ### Tabular files
 
-Tabular data MUST be saved as tab delimited values (`.tsv`) files, i.e., csv
+Tabular data MUST be saved as tab delimited values (`.tsv`) files, i.e., CSV
 files where commas are replaced by tabs. Tabs MUST be true tab characters and
 MUST NOT be a series of space characters. Each TSV file MUST start with a header
 line listing the names of all columns (with the exception of physiological and

src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md

@@ -290,7 +290,7 @@ combined image rather than an image from each coil.
 | NumberOfVolumesDiscardedByScanner | RECOMMENDED. Number of volumes ("dummy scans") discarded by the scanner (as opposed to those discarded by the user post hoc) before saving the imaging file. For example, a sequence that automatically discards the first 4 volumes before saving would have this field as 4. A sequence that doesn't discard dummy scans would have this set to 0. Please note that the onsets recorded in the \_event.tsv file should always refer to the beginning of the acquisition of the first volume in the corresponding imaging file - independent of the value of `NumberOfVolumesDiscardedByScanner` field. |
 | NumberOfVolumesDiscardedByUser    | RECOMMENDED. Number of volumes ("dummy scans") discarded by the user before including the file in the dataset. If possible, including all of the volumes is strongly recommended. Please note that the onsets recorded in the \_event.tsv file should always refer to the beginning of the acquisition of the first volume in the corresponding imaging file - independent of the value of `NumberOfVolumesDiscardedByUser` field.                                                                                                                                                                       |
 | DelayTime                         | RECOMMENDED. User specified time (in seconds) to delay the acquisition of data for the following volume. If the field is not present it is assumed to be set to zero. Corresponds to Siemens CSA header field `lDelayTimeInTR`. This field is REQUIRED for sparse sequences using the `RepetitionTime` field that do not have the `SliceTiming` field set to allowed for accurate calculation of "acquisition time". This field is mutually exclusive with `VolumeTiming`.                                                                                                                               |
-| AcquisitionDuration               | RECOMMENDED. Duration (in seconds) of volume acquisition. Corresponds to DICOM Tag 0018,9073 `Acquisition Duration`. This field is REQUIRED for sequences that are described with the `VolumeTiming` field and that not have the `SliceTiming` field set to allowed for accurate calculation of "acquisition time". This field is mutually exclusive with `RepetitionTime`.                                                                                                                                                                                                                              |
+| AcquisitionDuration               | RECOMMENDED. Duration (in seconds) of volume acquisition. Corresponds to DICOM Tag 0018,9073 `Acquisition Duration`. This field is REQUIRED for sequences that are described with the `VolumeTiming` field and that do not have the `SliceTiming` field set to allowed for accurate calculation of "acquisition time". This field is mutually exclusive with `RepetitionTime`.                                                                                                                                                                                                                           |
 | DelayAfterTrigger                 | RECOMMENDED. Duration (in seconds) from trigger delivery to scan onset. This delay is commonly caused by adjustments and loading times. This specification is entirely independent of `NumberOfVolumesDiscardedByScanner` or `NumberOfVolumesDiscardedByUser`, as the delay precedes the acquisition.                                                                                                                                                                                                                                                                                                    |
 
 The following table recapitulates the different ways that specific fields have
@@ -510,7 +510,7 @@ sub-<label>/[ses-<label>/]
 ```
 
 Similar to the case above, but instead of a precomputed phase difference map two
-separate phase images are presented. The two sidecar JSON file need to specify
+separate phase images are presented. The two sidecar JSON files need to specify
 corresponding `EchoTime` values. For example:
 
 ```JSON

src/04-modality-specific-files/02-magnetoencephalography.md

@@ -30,9 +30,9 @@ 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.
+data analysis, provide readers of such raw files.
 
-Some software reader may skip important metadata that is specific to MEG system
+Some software readers may skip important metadata that is specific to MEG system
 manufacturers. It is therefore RECOMMENDED that users provide additional meta
 information extracted from the manufacturer raw data files in a sidecar JSON
 file. This allows for easy searching and indexing of key metadata elements

src/05-longitudinal-and-multi-site-studies.md

@@ -70,7 +70,7 @@ sub-<label>/
 
 Optional: Yes
 
-In case of multiple sessions there is an option of adding an additional
+In case of multiple sessions there is an option of adding additional
 participant key files describing variables changing between sessions. In such
 case one file per participant should be added. These files need to include
 compulsory `session_id` column and describe each session by one and only one

src/06-extensions.md

@@ -23,7 +23,7 @@ community.
 ## BIDS Extension Proposals
 
 The BIDS specification can be extended in a backwards compatible way and will
-evolve over time. These are accomplished with BIDS Extension Proposals (BEPs),
+evolve over time. This is accomplished with BIDS Extension Proposals (BEPs),
 which are community-driven processes.
 
 Below is a table of currently-active BEPs. The "Extension label" column