From 81d5ccc2ca951c01d48c5fd08bbf22d3764e20c2 Mon Sep 17 00:00:00 2001 From: melanieganz Date: Tue, 23 Jan 2024 16:14:16 +0100 Subject: [PATCH] Fixed details Fixed details such as linking to entities and suffixes as well as clarified some of the example text. The tables need still to be fixed. --- src/atlas.md | 129 +++++++++++++++++++++++++-------------------------- 1 file changed, 62 insertions(+), 67 deletions(-) diff --git a/src/atlas.md b/src/atlas.md index 2fa10e6fd6..226fdfb020 100644 --- a/src/atlas.md +++ b/src/atlas.md @@ -2,7 +2,7 @@ In the following we describe how an [atlas](schema/objects/entities.yaml#atlas) can be shared within BIDS. We describe a broad set of atlases and use cases thereof. -More specifically, this entails providing and referring to existing atlas datasets, describing atlases that were newly derived within an analysis, and providing information for derivatives that were obtained through them. The first would comprise (publicly) available atlases, for example, Destrieux et al. [doi.org/10.1016/j.neuroimage.2010.06.010](https://doi.org/10.1016/j.neuroimage.2010.06.010), AAL [doi.org/10.1006/nimg.2001.0978](https://doi.org/10.1006/nimg.2001.0978), Yeo [doi.org/10.1152/jn.00338.2011](https://doi.org/10.1152/jn.00338.2011) and JHU DTI-based white-matter atlases [eBook ISBN: 9780080456164](https://shop.elsevier.com/books/mri-atlas-of-human-white-matter/mori/978-0-444-51741-8) [doi.org/10.1016/j.neuroimage.2007.07.053](https://doi.org/10.1016/j.neuroimage.2007.07.053), while the second would include atlases obtained through analyses within a dataset at hand, for example, resting-state networks and functional localizers. Importantly, the latter can also be utilized as existing atlases if made available. The third would entail referencing an atlas and its properties used to derive e.g. parcellated time series or a connectivity matrix. +More specifically, this entails providing and referring to existing atlas datasets, describing atlases that were newly derived within an analysis, and providing information for derivatives that were obtained through them. The first would comprise (publicly) available atlases, for example, Destrieux et al. [doi.org/10.1016/j.neuroimage.2010.06.010](https://doi.org/10.1016/j.neuroimage.2010.06.010), AAL [doi.org/10.1006/nimg.2001.0978](https://doi.org/10.1006/nimg.2001.0978), Yeo [doi.org/10.1152/jn.00338.2011](https://doi.org/10.1152/jn.00338.2011) and JHU DTI-based white-matter atlases [eBook ISBN: 9780080456164](https://shop.elsevier.com/books/mri-atlas-of-human-white-matter/mori/978-0-444-51741-8) and [doi.org/10.1016/j.neuroimage.2007.07.053](https://doi.org/10.1016/j.neuroimage.2007.07.053), while the second would include atlases obtained through analyses within a dataset at hand, for example, resting-state networks and functional localizers. Importantly, the latter can also be utilized as existing atlases if made available. The third would entail referencing an atlas and its properties used to derive e.g. parcellated time series or a connectivity matrix. ## Atlas as new DatasetType Here we introduce an additional value to the DatasetType field of dataset_description.json. If a dataset declares its DatasetType to be [atlas](schema/objects/entities.yaml#atlas), the top-level directories MUST be `atlas-` instead of `sub-`. This will allow sharing existing atlases as stand-alone datasets, validating them via the BIDS validator and enabling their integration as sub-datasets of other BIDS datasets. @@ -23,7 +23,7 @@ The first option refers to atlases that were not altered, e.g. via spatial trans /atlas/ ``` -using the BIDS validator. Importantly, only this case uses the “atlas-” identifier, following the same directory structure as “sub”, i.e., one dedicated directory for each atlas within a given dataset. +using the BIDS validator. Importantly, only this case uses the [atlas](schema/objects/entities.yaml#atlas) identifier, following the same directory structure as [atlas](schema/objects/entities.yaml#sub), i.e., one dedicated directory for each atlas within a given dataset. The default way of storage of the non-altered atlas at the root directory looks like this: ```Text @@ -35,11 +35,11 @@ The default way of storage of the non-altered atlas at the root directory looks ### Representing the atlas at the subject level -Besides this default and required storage of the non-altered atlas at the root directory, the second use case provides three options to store atlases that were either altered, applied, or derived within a given dataset. While option 1 also uses the “atlas” identifier, options 2 and 3 use the “seg” identifier, as outlined in the next paragraphs. +Besides this default and required storage of the non-altered atlas at the root directory, the second use case provides three cases to store atlases that were either altered, applied, or derived within a given dataset. While case 1 also uses the [atlas](schema/objects/entities.yaml#atlas) identifier, case 2 and 3 use the [seg](schema/objects/entities.yaml#seg) identifier, as outlined in the next paragraphs. #### Case 1 -First, a given atlas underwent modifications before its utilization, specifically spatial transformations to a template space and is used in this form within a given pipeline. In this case, the respective BIDS-Atlas files will be stored at both the BIDS root level and the given pipeline directory under “derivatives”. Files stored at the BIDS root level will follow the structure outlined in option 1, while files stored at the pipeline level will follow the respective naming conventions. For example, if an atlas was spatially transformed to a certain MNI template, then the BIDS-Atlas files will be stored within the respective pipeline directory and the corresponding space-