Overarching agenda for 2.0

[yarikoptic]

Short description of overarching theme/goals behind BIDS 2.0 . To make BIDS

• more flexible as capable to accommodate new fields of neuroscience and use cases and possibly avoid breeding of "BIDS-like" offsprings
  • Use-cases:
    • Use-case(s): BIDS-inspired/like standards #62
    • Use-case: AIND schema #60
• more consistent:
  • added from below by @tsalo: address any inconsistencies or inefficiencies that we had to incorporate into BIDS to maintain backwards compatibility. For example:
    • dropping either IntendedFor or B0FieldIdentifier/B0FieldSource,
    • removing deprecated elements like the phase suffix,
    • and addressing how space is used inconsistently across modalities.
  • see issues labeled with "deprecation" (most should get addressed)
  • see issues labeled with "consistency" (many should get addressed)
• more modular
  • see issues labeled with "modularity" (some should get addressed)
• more tools-friendly
  • even more assumptions should migrate from human written documentation into machine-readable form (schema, and auxilary metadata, such as DatasetType etc)
• more user-friendly
  • largely via "more consistent"
  • some rules could be relaxed or made more stringent to again reduce ambiguity
• easy to adopt/migrate to: analogy could be "python 2 to 3 migration" -
  • it should largely remain the same
  • "migration" helper should be provided to automagically upgrade from 1.x to 2.x. Ref: Develop bids-migration script #67 .

Some operating principles

• do not touch/modify supported data file types -- that would simplify migration (e.g. simply via their symlinks)

With that in mind, not all issues in this repository will be approached for 2.0. Please vote with 👍 or 👎 on existing issues

some items which were removed etc

Postponed/reconsidered from initial composition:

• make BIDS better "integrated" in the Web ecosystem, i.e. to become part of the linked web data

Removed/heavily rephrased:

• should either remain compatible with BIDS 1.0 as any BIDS 1.0 dataset would remain compatible with BIDS 2.0. (Exclusions might happen, should be weighted through usage)

Robert: What would be selling points for users to migrate to BIDS 2.0?

• some BIDS-like standards would get "one step closer" so may be some users jump over to BIDS from non-BIDS
• new tools would be supporting BIDS 2.0
• easy to migrate with migration script
• some new features (e.g. modular composition Allow composition of a BIDS dataset (dataset level) from smaller (subj or subj/ses) level #59) would allow for easier distributed processing

Ariel: User concern -- "should I now duplicate my dataset?"

• @yarikoptic: in dandi-cli (dandi organize) we solved it in part via "symlinks"
• @effigies : git branches could be used as well if datalad is used

[poldrack]

I would suggest some discussion that is focused on use cases and user stories. What are the most important use cases for the current version of the standard, and how would the proposed changes impact the different users?  Conversely, what are the use cases/user stories that are currently impeded by the standard and how would the changes enable those?  

[yarikoptic]

Note that many issues collected in this repository already come from users and their cases/stories. We had a few dozens of them IIRC.
For an "overarching" agenda I wanted to really see high(er) level goals. The ones I have stated might have got overfitted to the issues I had in mind, so may be people could suggest even better generalizations and more overarching?

NB. I think I should refactor this issue as a PR so we could have better means to adjust wording/statement...

[tsalo]

Rather than remaining compatible with BIDS 1.0, one goal should, I think, be to address any inconsistencies or inefficiencies that we had to incorporate into BIDS to maintain backwards compatibility. For example, dropping either IntendedFor or B0FieldIdentifier/B0FieldSource, removing deprecated elements like the phase suffix, and addressing how space is used inconsistently across modalities.

[yarikoptic]

sounds good -- that is why I mentioned "Exclusions" so it could sound like "Remove kludges from the growth pains of the BIDS 1.0". ;-)
What I meant is that we are unlikely to introduce as radical changes as sub- to par- (for "participant") or the other way change participants.tsv to subjects.tsv to bring consistency in that entity, which would break virtually every BIDS dataset... WDYT?

[yarikoptic]

In recent @bids-standard/steering meeting we decided to announce 2024 is the "The year of BIDS adoption". And thus it could be one of the guiding principles -- what we need to do for BIDS 2.0 to increase adoption. And IMHO it is the issues like

• Multi-site/center studies #11
• Extended BIDS for animals #38
• Use-case: AIND schema #60

and proposed approaches

• Make it possible to specify folders layout to be other than sub-{label}/[ses-{label}/] #54
• Allow composition of a BIDS dataset (dataset level) from smaller (subj or subj/ses) level #59