Separate standards under BIDS

[franklin-feingold]

As BIDS extends into more modalities, derivatives, and models it is being clear that more potential infrastructure could be implemented to better capture these advancements. An idea that has been raised is potentially having multiple standards under the umbrella of BIDS. To expand on this - potentially it could begin with having two BIDS standards: BIDS Core and BIDS Models (perhaps better naming of them). The BIDS Core would capture the file name and organization and the BIDS Models capture the models and "processing" (credit: @effigies) This process of splitting up can make it easier navigating the standard as it expands and allow for more room of expansion into spaces not defined

Interested to hear what we think of this and other potential proposals.

Thank you! Franklin

[nicholst]

I am (and was) in favor of a modular BIDS, creating distinct standards documents for the core, modality-specific and derivative specifications. It is already the case that the peer-reviewed publications that underpin MEG, EEG & iEEG extensions, and I think it would be easier for use, maintenance and giving credit to have distinct documents/entities. (This would also force us to acknowledge the MRI-centric nature of BIDS which, if is unsatisfactory to many, can lead to a refactoring of the BIDS Core standard to be more modality agnostic.)

[sappelhoff]

@franklin-feingold @effigies

To expand on this - potentially it could begin with having two BIDS standards

In concrete terms, is the suggestion to have two repositories like bids-standard/bids-core and bids-standard/bids-models? Or are the implications more far reaching?

@nicholst

This would also force us to acknowledge the MRI-centric nature of BIDS which, if is unsatisfactory to many, can lead to a refactoring of the BIDS Core standard to be more modality agnostic

This is a very good point, and is something to consider for BIDS 2.0, because a refactoring of BIDS-core would be hard (impossible?) without making backwards compatiblity breaking changes. Mainly due to the strong MRI bias.

---

Thinking about it, I could see the benefits of having separate specifications (concretely: repositories and associated sub-communities) that work on ... say:

• bids-standard/bids-raw (all raw data for all modalities)
• bids-standard/bids-derivatives (all derivative data for all modalities)
• bids-standard/bids-processing (models, etc.)

This division might not be perfect, but it's something that could be done now ... instead of having to wait for BIDS 2.0 ... because currently, neither derivatives, nor processing (statsmodels, ...) is merged.

[effigies]

My main comment to @franklin-feingold had been that there's a sufficiently strong distinction in terms of what is being specified between data and models that treating keeping them in separate documents would be reasonable. There are a few common principles adjoining them (e.g., variable names, and model files would need a BIDS-compatible file name) but that's about it.

To move to practical terms, I see a couple options:

1. Create data and processing sub-trees in the spec. Pretty much everything in the current spec would go under data, except for maybe a bit of common principles (possibly what @nicholst is referring to as BIDS Core).
2. Create a separate processing spec that has a statement of "This is compatible with BIDS-data versions 1.x", and separately maintain and version it.

I haven't thought through the notion of BIDS-core, but this seems like a valid effort. If somebody has the energy to put into it, it might be worth seeing what can be done without breaking compatibility, which would allow the specification to be refactored prior to BIDS 2.0. On the other hand, my impression at OHBM is that we may be getting to the point where BIDS 2.0 needs to start being an object of active development, as concerns about backwards compatibility seem to be a source of the derivatives paralysis.

[emdupre]

Sorry, just to make sure I understand this proposal

creating distinct standards documents for the core, modality-specific and derivative specifications

Would there still be interactions across modalities, then, or would it be that everyone looks to BIDS core for principles and implements in their own modalities ?

The reason I ask is I think there are some problems that end up being "re-discovered" across modalities (like re-annotating ephys time series vs re-annotating naturalistic stimuli, already shared with MRI data) and I'm curious how those conversations would happen in this framework !

[franklin-feingold]

I like @nicholst's idea of having the three distinct standards: Core, Modality-specific, and derivatives (perhaps a fourth in Models?)

The implications I think would be far-reaching. This would be separating the main standard out. An idea could be to have them rendered together for ease of navigating and finding the information you are looking for. A concern of splitting them into individual pieces is the ease of navigating across them and maintaining them all concurrently.

This can be a BIDS 2.0 idea though I think we are in a good position to implement some of this before discussions for 2.0 start growing. As Chris said - there is a need forming for 2.0 to be discussed and considered (not sure the time frame)

There would still be interaction across the modalities and keeping them consistent with each other ensuring one does not violate another. Re-discovering commonalities across modalities I think is really good and this shows the need for the different modalities to talk with each other and stay up to date on those that are close to them. I think this is addressed in the governance structure with the BEP Leads group. Hopefully in practice as each know where the other is at can spark the discussion and collaboration.