Automatically calculate BIDSVersion

[CodyCBakerPhD]

Currently is hardcoded to the old 1.10, but this has since been released upstream and so is not correct

[asmacdo]

How automatic can it be? I assume manual steps would need to be taken to verify that nwb2bids actually follows the changes? I suppose we could automate filing an issue if out of date though?

[CodyCBakerPhD]

Either issue or pure email notification could work for notifying devs if you'd prefer we hard-code what version(s) we claim to support

[CodyCBakerPhD]

That or add BIDS validation tests to various outputs in the test suite and instruct that to use latest BIDS version (after BEP32 merged) which would fail if something broke - either way we claim to always use 'latest' and attempt to pull version dynamically in the code

[CodyCBakerPhD]

Plan is to

• attempt to query the BIDS schema for the latest version
• fallback to using the first official version following BEP32 merge

[yarikoptic]

I think hardcoding BIDS version is the correct thing to do since with that we code the statement on what result is compatible with to our knowledge! But then what should the value be?

I think we should even aim for something what we did for microscopy while it was still a BEP. I would need to recover detail but it was using custom bids version hinting on bep along similar lines:

In our case we can use 1.10.1+PR2307 or alike which would then instruct to take from

• [ENH]: BEP032 formal review bids-standard/bids-specification#2307
  in particular from https://bids-specification--2307.org.readthedocs.build/en/2307/schema.json .

An alternative, to avoid situations where site build failed in a PR, we could use 1.10.1+BEP032 and take from https://github.com/bids-standard/bids-schema/tree/main/BEPs#readme i.e https://raw.githubusercontent.com/bids-standard/bids-schema/refs/heads/enh-prs-and-beps/BEPs/32/schema.json where at least prior version if build fails I think should persist.

And to make it even more 'rigid' given fluidity of BEP032, we could even make it
1.10.1+BEP032#416ec0aca33371b4ca651dbb34e2bd1bf8abe3fa if to point to specific commit in that repo, hence hardcoding our expectations fulfilled in the nwb2bids. Then dandi-cli could parse it, fetch corresponding schema, and do validation. There could even be env var 'DANDI_USE_BEP_SCHEMA=latest' to force validation against most recent known BEP state (as if no committish was specified).

[CodyCBakerPhD]

I think hardcoding BIDS version is the correct thing to do since with that we code the statement on what result is compatible with to our knowledge!

OK, but maybe with a CRON test to inform us when there is a 'new' version, that we should check it and ensure we remain compatible?

But then what should the value be?

The first official version following BEP32 merge.

Between now and then, any of your suggestions work, with preference to the full hash since there are (and could still be) changes that affect validation results as observed on BIDS-Dandisets

Then dandi-cli could parse it, fetch corresponding schema, and do validation.

I assume that takes some DANDI-CLI work, which might just make more sense to wait until formal BEP merge to actually integrate as an 'official' feature, but you are welcome to start a draft dev branch for it

What you do not want is a bunch of transiently invalid BIDS Dandisets to get uploaded or published in the interim

[yarikoptic]

OK, but maybe with a CRON test to inform us when there is a 'new' version, that we should check it and ensure we remain compatible?

who is "we" here -- dataset or nwb2bids, and what would mean "compatible"? I see at least 2 aspects

• nwb2bids reflecting / supporting changes in the new version, which could be addition of new properties and nwb2bids not yet extracting them;
• dataset should remain "valid" in its version; for migration into new additional tools planned to be developed -- per our ongoing discussion etc in https://github.com/bids-standard/bids-utils/pull/4/changes#diff-68da6d0a6818ee87101f0e2220e30cfa038e7deeb68c2a35344636db6d6da2bcR38 ; so we might upgrade then dataset to new version and see if still valid and it should be -- new versions should not add restrictions (like we did in DANDI ;) )

The first official version following BEP32 merge.

yeah -- testing those against "released" BEP version would be useful indeed. May be we could make DANDI_USE_BIDS_SCHEMA=dataset,latest,latest-bep,released-bep,{explicit_version} as modes of which version to use.

Then dandi-cli could parse it, fetch corresponding schema, and do validation.

I assume that takes some DANDI-CLI work, which might just make more sense to wait until formal BEP merge to actually integrate as an 'official' feature, but you are welcome to start a draft dev branch for it

yeah, if I do not forget... let's may be decide on what modes we want and how to specify.

What you do not want is a bunch of transiently invalid BIDS Dandisets to get uploaded or published in the interim

Frankly those might be more standardized than most of the other DANDI ones ;) so I would not really worry about that too much.

[CodyCBakerPhD]

who is "we" here

The long-term maintaners of nwb2bids

dataset or nwb2bids? I see at least 2 aspects

A dataset that ran nwb2bids at one point in time would have a BIDS version attached to it by nwb2bids.

and what would mean "compatible"

Exactly - we would want to have some kind of check that the outputs of nwb2bids remain valid with respect to future releases of nwb2bids. That could be in the test suite and we 'sign-off' on support of future releases automatically based on the suite passing, or we could base it off of some success rate from BIDS-Dandiset testing

The case to imagine is if someone other than us proposes a bug fix or other change to the microephys schema on BIDS a year from now, and no one notices until the next BIDS release cycle. Then if that introduces some unexpected change or other unintentional bug. In that case we wouldn't want to sign off on nwb2bids supporting that newest BIDS version since it would produce invalid datasets under that BIDS version

Frankly those might be more standardized than most of the other DANDI ones ;) so I would not really worry about that too much.

I wouldn't worry about the uploading if server-side validation actually prevented formal publication, which would not be a good thing for long-term re-use.

Frankly those might be more standardized than most of the other DANDI ones ;)

We're supposed to be alleviating that problem, not continuing the practice and/or making it worse

It's not a big ask to be patient for another month. Perhaps the community review may actually change certain things in significant ways, who knows

(BTW I told the Allen Institute people about your idea for asset linkage and they seemed to like it, so I invited them to take a look at the BEP. They will likely want to add a reference to their current BICAN atlas and review if the coordinate space system works well for their icephys cases, which they are back-filling at Satras request)