Skip to content

Common data types and metadata

Common file level metadata fields

Each derivative data file SHOULD be described by a JSON file provided as a sidecar or higher up in the hierarchy of the derived dataset (according to the Inheritance Principle) unless a particular derivative includes REQUIRED metadata fields, in which case a JSON file is also REQUIRED. Each derivative type defines their own set of fields, but all of them share the following (non-required) ones:

Key name Requirement level Data type Description
Description RECOMMENDED string Free-form natural language description of the nature of the file.
Sources OPTIONAL array of strings A list of files with the paths specified relative to dataset root; these files were directly used in the creation of this derivative data file. For example, if a derivative A is used in the creation of another derivative B, which is in turn used to generate C in a chain of A->B->C, C should only list B in Sources, and B should only list A in Sources. However, in case both X and Y are directly used in the creation of Z, then Z should list X and Y in Sources, regardless of whether X was used to generate Y.
RawSources OPTIONAL array of strings A list of paths relative to dataset root pointing to the BIDS-Raw file(s) that were used in the creation of this derivative.


Preprocessed bold NIfTI file in the original coordinate space of the original run. The location of the file in the original datasets is encoded in the RawSources metadata, and desc-<label> is used to prevent clashing with the original file name.

    "RawSources": ["sub-01/func/sub-01_task-rest_bold.nii.gz"]

If this file was generated with prior knowledge from additional sources, such as the same subject's T1w, then both files MAY be included in RawSources.

    "RawSources": [

On the other hand, if a preprocessed version of the T1w image was used, and it also occurs in the derivatives, Sources and RawSources can both be specified.

    "Sources": [
    "RawSources": [

Spatial references

Derivatives are often aligned to a common spatial reference to allow for the comparison of acquired data across runs, sessions, subjects or datasets. A file may indicate the spatial reference to which it has been aligned using the space entity and/or the SpatialReference metadata.

The space entity may take any value in Image-Based Coordinate Systems.

If the space entity is omitted, or the space is not in the Standard template identifiers table, then the SpatialReference metadata is REQUIRED.

Key name Requirement level Data type Description
SpatialReference RECOMMENDED if the derivative is aligned to a standard template listed in Standard template identifiers. REQUIRED otherwise. string or object For images with a single reference, the value MUST be a single string. For images with multiple references, such as surface and volume references, a JSON object MUST be used. See examples below.

SpatialReference key allowed values

Value Description
orig A (potentially unique) per-image space. Useful for describing the source of transforms from an input image to a target space.
URI or path This can be used to point to a specific file. Paths are written relative to the root of the derivative dataset.

In the case of images with multiple references, an object must link the relevant structures to reference files. If a single volumetric reference is used for multiple structures, the VolumeReference key MAY be used to reduce duplication. For CIFTI-2 images, the relevant structures are BrainStructure values defined in the BrainModel elements found in the CIFTI-2 header.


Preprocessed bold NIfTI file in individual coordinate space. Please mind that in this case SpatialReference key is REQUIRED.

    "SpatialReference": "sub-01/anat/sub-01_desc-combined_T1w.nii.gz"

Preprocessed bold CIFTI-2 files that have been sampled to the fsLR surface meshes defined in the Conte69 atlas along with the MNI152NLin6Asym template. In this example, because all volumetric structures are sampled to the same reference, the VolumeReference key is used as a default, and only the surface references need to be specified by BrainStructure names.

    "SpatialReference": {
        "VolumeReference": "",

Preprocessed or cleaned data



Data is considered to be preprocessed or cleaned if the data type of the input, as expressed by the BIDS suffix, is unchanged. By contrast, processing steps that change the number of dimensions are likely to disrupt the propagation of the input's suffix and generally, the outcomes of such transformation cannot be considered preprocessed or cleaned data.

Examples of preprocessing:

  • Motion-corrected, temporally denoised, and transformed to MNI space BOLD series
  • Inhomogeneity corrected and skull stripped T1w files
  • Motion-corrected DWI files
  • Time-domain filtered EEG data
  • MaxFilter (for example, SSS) cleaned MEG data

The space keyword is recommended to distinguish files with different underlying coordinate systems or registered to different reference maps. See Spatial references for details. The desc (description) keyword is a general purpose field with freeform values, which SHOULD be used to distinguish between multiple different versions of processing for the same input data.

Examples of preprocessed data:


All REQUIRED metadata fields coming from a derivative file’s source file(s) MUST be propagated to the JSON description of the derivative unless the processing makes them invalid (for example, if a source 4D image is averaged to create a single static volume, a RepetitionTime property would no longer be relevant).