Merge pull request #259 from yarikoptic/enh-reproin

ENH: add pointer to ReproIn and ReproIn namer for consistent protocols naming convention

Author: marcelzwiers

docs/preparation.rst

@@ -148,4 +148,4 @@ The above layouts are supported by the (default) `dcm2niix2bids <./plugins.html#
 Recommended data acquisition conventions
 ----------------------------------------
 
-BIDScoin can automatically recognize source data types on the basis of it's properties and attributes. Typically, in the DCCN users name their MR scan protocols in a meaningful way, which is therefore used as a basis for intelligent source data type identification. For instance, if a functional MRI protocol is named "StopTask" or "fMRI_Stroop", the default bidsmap_dccn template will yield a positive 'func/bold' match, as it has the "task" and "fMRI" keywords in it's run-item regular expression: ``{ProtocolName: (?i).*(f.?MRI|task|BOLD|func|rest|RSN|CMRR.*_TR).*}``. Similarly, anatomical scans that have ``T1w`` or ``MPRAGE`` in their protocol name are identified as anat/T1w items, and field maps that have ``fmap``, ``fieldmap`` or ``B0map`` in their protocol name are identified as field maps. On the other hand, if a functional scan is just named ``Stop``, the data type cannot be correctly identified (at least not by the default template) and needs to be manually changed in the bidseditor from ``extra_data`` to ``func``. A robust way to acquire and convert your data is hence to use (BIDS-like) descriptive names for your protocols, or for any other attribute or property (such as filenames) that you may use to manage your data. For more details and keywords, see e.g. the `DCCN template bidsmap <https://github.com/Donders-Institute/bidscoin/blob/master/bidscoin/heuristics/bidsmap_dccn.yaml>`__.
+BIDScoin can automatically recognize source data types on the basis of it's properties and attributes. Typically, in the DCCN users name their MR scan protocols in a meaningful way, which is therefore used as a basis for intelligent source data type identification. For instance, if a functional MRI protocol is named "StopTask" or "fMRI_Stroop", the default bidsmap_dccn template will yield a positive 'func/bold' match, as it has the "task" and "fMRI" keywords in it's run-item regular expression: ``{ProtocolName: (?i).*(f.?MRI|task|BOLD|func|rest|RSN|CMRR.*_TR).*}``. Similarly, anatomical scans that have ``T1w`` or ``MPRAGE`` in their protocol name are identified as anat/T1w items, and field maps that have ``fmap``, ``fieldmap`` or ``B0map`` in their protocol name are identified as field maps. On the other hand, if a functional scan is just named ``Stop``, the data type cannot be correctly identified (at least not by the default template) and needs to be manually changed in the bidseditor from ``extra_data`` to ``func``. A robust way to acquire and convert your data is hence to use (BIDS-like) descriptive names for your protocols, or for any other attribute or property (such as filenames) that you may use to manage your data. For more details and keywords, see e.g. the `DCCN template bidsmap <https://github.com/Donders-Institute/bidscoin/blob/master/bidscoin/heuristics/bidsmap_dccn.yaml>`__, or consider `BIDS-like ReproIn convention <https://reproin.repronim.org>`__ with `ReproIn namer <https://npacore.github.io/reproin-namer/#>`__ for organizing and naming protocol names.