[DISCUSSION] Redundancy in the specification

[Remi-Gau]

Open-ended discussion to see how people feel about the presence of redundancy in the specification.

For a bunch of reasons (how the specifcation got built, how each datatype section aims to be more "standalone"...) there is a certain amount of redundancy in the specification. That comes with pros and cons (that may be different for readers and maintainers).

That being said, I wonder if some redundancy could not be removed.

One example from https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/01-magnetic-resonance-imaging-data.html#task-including-resting-state-imaging-data

The following passage just re-explains the inheritance principle without mentioning.

If this information is the same for all participants, sessions and runs it can be provided in task-_bold.json (in the root directory of the dataset). However, if the information differs between subjects/runs it can be specified in the sub-/func/sub-_task-[_acq-][_run-]_bold.json file. If both files are specified fields from the file corresponding to a particular participant, task and run takes precedence.

I would be tempted this paragraph because of its redundant character. Others may feel otherwise as it gives an in-context short concrete "example" of the inheritance principle. However other datatypes do not get similar example so it feels very uneven on the whole and feels like it'd be simpler to not have this example at all.

This is just one random snippet of something that occurs in several places in the spec.

Would be curious how people feel about this?

[sappelhoff]

I think we can remove redundancy on a case-by-case basis, one PR at a time. If we concisely explain principles and use cross-links, then this should not impede the reading flow by too much (maybe on the contrary).