Add another example to inheritance principle for .json without entities

[yarikoptic]

Upon re-reading current Inheritance principle formulation, nothing seems to forbid that, and such use in general is great since allows to generalize common metadata across all files of that datatype.

Notes on possible side-effects from "embracing" such approach (which in principle I think is not disallowed ATM).

• per rule 4, presence of bold.json forbids presence of another _bold.json (i.e with entity) on the same level. So if further specialization e.g. per each task- is needed, common metadata needs to be duplicated across them (that is what heudiconv does ATM).

  Such restrictions could potentially be elevated if we adopt "summarization" refactoring of inheritance principle https://github.com/bids-standard/bids-2-devel/issues/65 since order would stop to matter and thus multiple files can apply.

• I think that bids-validators are fine as checked on a single ds000248/T1w.json in bids-examples and modified 7t_trt.

• I do not know if tools implement it though but since there was precedence for ds000248/T1w.json - they better do ;-)

[effigies]

To save other reviewers time:

link

[yarikoptic]

ping @Lestropie . Also @dorahermes - would you be interested to review as this use case might be relevant to you as well?

[Lestropie]

I don't find "Generalization of Examples 1 and 4 for a sidecar file without entities" to be an accurate description here:

• It is I believe accepted parlance---though notably currently missing from the list of definitions---that a "sidecar file" is a metadata file that possess the same stem as a data file, and only has a different extension. Which means that the proposed example describing "a sidecar file without entities" has no sidecar files.

• What distinguishes example 5 from 4 is that 5 applies if there are zero metadata fields that are unique even to the subject, let alone to each of the two runs. The contents of file "/bold.json" are applicable to all "*_bold.nii.gz" in the dataset, including all subjects.

• What's being presented as novel in each of Examples 4 and 5 are not mutually exclusive. One can have both "/bold.json" containing subject-agnostic metadata, and "/sub-01/fmri/sub-01_task-xyz_acq-test1_bold.json" containing subject-specific but run-agnostic metadata.

If the goal is to exemplify how a metadata field can be inherited from the dataset root, I would do so as an addition to an existing example rather than as a substitute alternative. Eg. Have "/bold.json" but also a sidecar for each data file. Unless software is already generating datasets that are completely absent of sidecars, and that's why you're wanting to present it as an example? If that's the case, I'm not against presenting it, but it needs more accurate description.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 82.15%. Comparing base (56159a1) to head (9227843).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2019   +/-   ##
=======================================
  Coverage   82.15%   82.15%           
=======================================
  Files          17       17           
  Lines        1530     1530           
=======================================
  Hits         1257     1257           
  Misses        273      273           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.