bids-validator

bids-validator copied to clipboard

Most of the examples in the specification give relative file paths that are lower case. I was wondering what the case requirements were for matching files for inheritance? Is there something in the specification about it? Do entity names have to be lower case?

For example, does sub-01_task_blimey_eeg.set inherit metadata from sub-01_task_BLIMey_eeg.json or sub-01_Task_blimey_eeg.json of SUB-01_task_blimey_eeg.set?

Also, are the values in the key value pairs of "entities" allowed to be hyphenated? What happens if these values have underbars line my_blimey for the task name? Are entities required to be lowercase (e.g., SUB is not allowed).?

I am asking this because I think that software relies on splitting by the underbars and then by the hyphens. It would be useful to spell out these rules somewhere. (This is related to PR bids-standard/bids-specification#946 and PR bids-standard/bids-specification#947.)

Just a quick drive-by answer: I think this may answer some of your questions --> https://bids-specification.readthedocs.io/en/latest/02-common-principles.html#case-collision-intolerance

Also:

• values for entities can be either label or index, both are defined under: https://bids-specification.readthedocs.io/en/latest/02-common-principles.html#definitions --> basically, "labels" must be alphanumeric (so no hyphens or underscores allowed), indices are non-negative integers - optionally prefixed by zeros
• entities MUST be as defined in the spec (conforming to the defined case), so sub-<label> is valid, SUB-<label> is undefined and hence invalid

Thanks @VisLab for extracting this question from bids-standard/bids-specification#946. And thanks @sappelhoff for pointing to the "case collision intolerance" principle introduced only recently in bids-standard/bids-specification#858 . So, if I got it right, only <label>s are in question here, and if colliding casing is encountered, e.g. anentity-value on top level, and anentity-Value somewhere deeper, it should violate such a principle, and validator must detect that.

This issue was answered very satisfactorily and can now be closed (thank you!). However, I just wanted to verify that this principle has been incorporated into the BIDS-validator.

This issue was answered very satisfactorily and can now be closed (thank you!). However, I just wanted to verify that this principle has been incorporated into the BIDS-validator.

Should we then transfer this issue on the validator repo?

I would appreciate it. I am not positive at this point that all case sensitivity issues are caught by the validator. It would be nice for downstream tool developers to be able to rely on the rules being followed.