Inheritance: Further Relaxation allowing multiple files per directory

[yarikoptic]

Follow up/continuation to #1003 as suggested/discussed in #1003 (comment) . Extracting here:

For that latter case (e.g. task-rest_bold.json and acq-tricky_bold.json) we could have removed this requirement ("subsequent ... is a strict superset ...") and require that for such cases of unclear ordering, order is arbitrary but metadata files MUST NOT have identical metadata fields overloaded (thus order would not matter).

        if multiple applicable files have the same number of entities,
        they could be ordered arbitrarily among themselves and they MUST NOT
        contain overlapping metadata.

It would be up for validator to ensure adherence to such a principle. This would "relax" inheritance principle further and allow for arbitrary combinatorics if so desired for some studies, e.g. mix in of _task-rest_bold.json and ses-pilot_bold.json, _space-X and _desc-Y in bids-standard/bids-bep016#32 etc.

[Lestropie]

@yarikoptic Finally got around to this; see Lestropie#5.

[effigies]

There does not seem to be clear consensus on either relaxing or tightening up the inheritance principle. I can report, however, a practical difficulty with the current rule and derivatives as written. Example:

sub-01/
  anat/
    sub-01_desc-preproc_T1w.json
    sub-01_desc-preproc_T1w.nii.gz
    sub-01_space-MNI_desc-preproc_T1w.json
    sub-01_space-MNI_desc-preproc_T1w.nii.gz

According to the current rule, both JSON files apply to the MNI-space T1w.nii.gz, which violates

4. There MUST NOT be multiple metadata files applicable to a data file at one level of the directory hierarchy.

One way of relaxing this would be:

4. Multiple metadata files may not apply to a data file at a single level of the directory hierarchy. If multiple applicable metadata files exist at the same level of the hierarchy and one file shares all entities with the data file, then only that metadata file that shares all entities with the data file applies to the data file at that level of the hierarchy.

This is what is implemented in https://github.com/bids-standard/bids-validator/pull/1773, which is needed to handle fMRIPrep derivatives right now. The alternative is to clarify derivatives to figure out what fMRIPrep should be doing differently. We have been trying to avoid inheritance principle ambiguities, and yet we ran into this.

[effigies]

Possibly this should have been a new thread, as it's a different proposal, but it seemed worth consolidating discussion for the moment. For what it's worth, the proposal above comports with PyBIDS' current behavior, which was intended to support the current reading of inheritance, and has not changed for several years.

[Remi-Gau]

• agree to start a separate thread because this sounds actionable
• maybe just me but I think that the rephrasing is just making more explicit what was in the original point 4.

[effigies]

Okay. New issue created. Will hide these posts.

[yarikoptic]

FWIW, this is inline with

• Replace "inheritance" with "summarization" principle bids-2-devel#65

and if implemented, would close this issue. With that in hope/mind - I would not bother addressing this for BIDS 1.0 since would require changes to tools etc, but would better be made more explicit in BIDS 2.0 formulation.