-
Notifications
You must be signed in to change notification settings - Fork 169
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
[ENH] schema - specify what is valid at the root of a dataset #1108
Open
rwblair
wants to merge
15
commits into
bids-standard:master
Choose a base branch
from
rwblair:schema/dataset_root
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rwblair
changed the title
[ENH] specify schem
[ENH] schema - specify what is valid at the root of a dataset
May 26, 2022
All rules describing valid filenames could also be moved into a single directory to help keep everything together. |
rwblair
commented
May 26, 2022
yarikoptic
reviewed
May 26, 2022
remove name of root rule
…cation into schema/dataset_root
…into schema/dataset_root
…cation into schema/dataset_root
Remi-Gau
added
the
schema
Issues related to the YAML schema representation of the specification. Patch version release.
label
Dec 22, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
schema
Issues related to the YAML schema representation of the specification. Patch version release.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
prior art:
#884
https://github.com/ANCPLabOldenburg/ancp-bids/blob/main/ancpbids/data/bids_graph_schema.yaml
Problems
new keys used in rules to help resolve issues:
type: directory
we currently have no way of saying the thing I'm describing is a directory. If omitted we could assume its a file, or we could make every file use
type: file
children:
this would specify what valid file and directory names inside a given directory are
Decided to use pattern to cover this use case.literal:
some files in datatypes are simple singleword suffixes with an extension. When interpreting entity-suffix-extension pattern rules we use the underscore as the split character separating entities from each other and entities from the suffix.
There are files like 'dataset_description.json' whose preextension string have an underscore, so using suffix-extension with no entity would need to be understood as 'dont split on _'
literal gets around that by saying hey just look for this exact thing, forget about entities or suffixes and splitting.
pattern:
pipelines can have any name. would be interpreted as a regex to match against the directory or filename literal and pattern could be merged, regex matches literals just fine.
A file or directory name could then be described with one of the following patterns:
literalliteral + extensionsAnother issue maybe, not for this PR, is how implicit references to other parts of the schema are handled, they're context sensitive. If I have an entry under an entities key I know to go look in objects.entities. Here with children I've referenced keys that appear in the same file without a $ref tag.