Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How is case-sensitivity handled for BIDS entity matching? #46

Open
VisLab opened this issue Dec 13, 2021 · 6 comments
Open

How is case-sensitivity handled for BIDS entity matching? #46

VisLab opened this issue Dec 13, 2021 · 6 comments

Comments

@VisLab
Copy link
Member

VisLab commented Dec 13, 2021

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.)

@sappelhoff
Copy link
Member

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

@yarikoptic
Copy link
Contributor

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.

@VisLab
Copy link
Member Author

VisLab commented Dec 17, 2021

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.

@Remi-Gau
Copy link
Contributor

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?

@sappelhoff sappelhoff transferred this issue from bids-standard/bids-specification Jan 18, 2022
@VisLab
Copy link
Member Author

VisLab commented Jan 18, 2022

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.

@effigies
Copy link
Contributor

effigies commented Nov 4, 2024

This should be made into a test case, if it's a concern.

@effigies effigies transferred this issue from bids-standard/legacy-validator Nov 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants