Ambiguity in example used for inheritance principle

[Lestropie]

From Common principles:

Example 2: Multiple runs and recs with same acquisition (acq) parameters

sub-01/
    anat/
    func/
        sub-01_task-xyz_acq-test1_run-1_bold.nii.gz
        sub-01_task-xyz_acq-test1_run-2_bold.nii.gz
        sub-01_task-xyz_acq-test1_rec-recon1_bold.nii.gz
        sub-01_task-xyz_acq-test1_rec-recon2_bold.nii.gz
        sub-01_task-xyz_acq-test1_bold.json

For the above example, all NIfTI files are acquired with same scanning parameters (acq-test1). Hence a JSON file describing the acq parameters will 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.

The NIfTI files here indicate that there are:

• Two different "runs", i.e. the protocol acquisition was executed twice;
• Two different "recs", i.e. reconstruction algorithms.

However what is not clear from this example is: what data were provided as input to the two distinct reconstructions? Given they don't include "_run-#", should it be assumed that both reconstructions used as input the concatenation of all data across the two runs?

Moreover, the specific details of "_run-" and "_rec-" aren't provided until a later section (Modality specific - MRI).

I would propose that an alternative, more simple example may be preferable here: one that does not introduce such potential ambiguity or dependence on other sections.

[sappelhoff]

I agree that this example is more complicated than necessary. +1 from my side to work on a simpler one.

[yarikoptic]

As to me inheritance principle lacks necessary formal algorithmic definition and thus is ambiguous for any (like here) but trivial scenario, thus examples indeed need to be dumbed down more. More of formalized whining in #102 .

[sappelhoff]

@Lestropie do you want to open a PR to improve the example?