From d8b75ccdb6f64e699c0962a869b73854e9a39165 Mon Sep 17 00:00:00 2001 From: Andrew Janke Date: Fri, 20 Dec 2019 20:41:02 -0500 Subject: [PATCH 1/3] [FIX] Fix some typos and prose style issues --- src/02-common-principles.md | 10 +++++----- .../01-magnetic-resonance-imaging-data.md | 4 ++-- .../02-magnetoencephalography.md | 4 ++-- src/05-longitudinal-and-multi-site-studies.md | 2 +- src/06-extensions.md | 2 +- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/02-common-principles.md b/src/02-common-principles.md index d9d90f9b4c..c7253fcafd 100644 --- a/src/02-common-principles.md +++ b/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 diff --git a/src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md b/src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md index 802e875254..cecd645ecd 100644 --- a/src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md +++ b/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-