-
Notifications
You must be signed in to change notification settings - Fork 25
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
bids dataset detection #1073
Comments
generally BIDS is recursive through |
i don't think |
no but it could be e.g. |
I guess we could restrict "search" for BIDS (sub)datasets to some pre-defined set of sub-directories paths, but for that we should start with a promise that the top of the dandiset then must be a BIDS dataset then, as identified by having |
for a dandiset if you start with first detecting dandiset.yaml, then everything else should flow from that. however, for 26, i would indeed like to reorganize that one into a better bids structure, but mostly it would be removing rawdata as a prefix from any asset that has it. derivatives would stay at the same place. |
Since the last BIDS asset redesign, we traverse the directory tree until we find the topmost |
let's do so unless proven otherwise |
transferring thought process to new issue from #1069
shouldn't this only look up towards root from current location (and obviously not look if allow any path is used).
find dandiset.yaml to determine where to look for bids dataset_description.json files
also i'm assuming 26 is a culprit in the thinking, so any depth traversal could be a heuristic depth based on where dandiset.yaml is. (as in a dataset_description.json has to be either at the level of dandiset.yaml, or perhaps at most 2-3 directories down from dandiset.yaml).
even with our hacked setup, there shouldn't be a need to traverse everything. i can't offhand think of other scenarios that violate this.
and we could formalize this into our validator.
The text was updated successfully, but these errors were encountered: