Defining Criteria for Data Types and Modalities in BIDS

[neuromechanist]

Background

The Brain Imaging Data Structure (BIDS) specification currently distinguishes between data types (represented as subdirectories under each subject) and modalities (represented as file suffixes). However, there appears to be inconsistency in how these distinctions are made across different kinds of data.

Some examples of the current state:

• anat is a data type for MRI anatomical recordings, with t1w, t2w, etc, as modalities
• eeg, ieeg, and meg are separate data types and modalities for different neural recording methods
• motion exists as its own data type and modality
• physio exists as a modality but not yet as a data type (being addressed in BEP045, BEP about non-neuronal physiological (cardiac, respiratory, skin conductance, gastro, ...) data and physiological data derivatives #1675)
• Eye tracking is being added as a recording type under the physio modality (BEP020, [ENH] BEP020 - Eye Tracking #1128), with standalone eye tracking placed under the beh data type
• emg data type and modality is being proposed (BEP042, [ENH] BEP042 - extension for electromyography (EMG) #1998)

Current Discussion

There is an ongoing discussion under #1998 about whether certain data should:

1. Have their own dedicated data type and modality
2. Be incorporated under an existing umbrella data type
3. Be embedded within other modalities when appropriate

The discussion initiated as to whether EMG should:

• Have its own data type and modality (similar to EEG/MEG/iEEG)
• Be incorporated under the physio modality (similar to eye tracking in BEP020)

However, I believe that the scope of the issue is larger than EMG, and appreciate the community to provide their inputs.

Key Considerations

When determining whether a data category deserves its own data type/modality or should be incorporated under an existing umbrella, the following factors have been raised:

1. Signal source and nature: Is the signal brain-derived vs. peripheral? Neural vs. non-neural?

2. Data dimensionality and complexity: Does the data have unique requirements in terms of channel count, sampling rate, or format that make existing structures insufficient?

3. Research usage patterns: Is the data commonly used as a standalone dataset, or primarily as an auxiliary measurement to other data types?

4. Technical requirements: Does the data require specific metadata fields, coordinate systems, or other specifications that don't align with existing structures?

5. Community needs: Is there sufficient research activity and community interest to warrant a dedicated structure?

6. Fragmentation concerns: Does creating a new data type/modality risk fragmenting the BIDS ecosystem unnecessarily?

7. Consistency with existing structures: How would the decision align with precedents set by other data types?

The case of EMG-BIDS

For EMG data (BEP042), arguments for a dedicated data type include:

• EMG data is often high-dimensional (>200 channels with 2+ kHz sampling)
• EMG can target multiple muscles and requires specific placement information
• EMG can directly derive/estimate neural discharges
• There is significant standalone EMG research
• Multiple EMG devices can record simultaneously
• EMG closely follows other electrophysiology data types (EEG/iEEG/MEG) and current research closely relates the signals to neural activity.
• Motion-BIDS is a standalone data type and modality suggesting that not all BIDS datatypes and modalities should be "brain-related."

Arguments for incorporating EMG under physio:

• Creating new modality suffixes can fragment BIDS
• Similar physiological signals (e.g., eye-tracking) are managed under physio
• The BEP020 approach with PhysioType field could accommodate EMG-specific metadata
• Consistency with how other non-brain physiological recordings are handled (EKG, Eyetracking under physio)

Questions for the Community

1. What should be the threshold criteria for creating a new data type vs. using an existing one?

2. Should brain-derived signals be treated differently from other physiological signals? If yes, how this differentiation applies to the current specifications, including Motion-BIDS and ongoing PRs.

3. How should we balance the need for specificity against the risk of fragmentation?

4. Should we establish a formal policy for what constitutes grounds for a new data type/modality?

5. How can we ensure that similar types of data (e.g., various physiological recordings) are treated consistently across the specification?

6. What is the threshold or recommendation for using the data specific modality/recording versus embedding data under other modalities for example, Eye-tracking and EMG can be embedded under EEG as channels.

Next Steps

This discussion has implications beyond just EMG data and could affect how future data types are incorporated into BIDS. We could also consider whether:

1. A formal policy document should be developed
2. Existing data types should be reviewed for consistency
3. A dedicated BEP should address this foundational question

Community input from researchers working with diverse data types, and stakeholders @bids-standard/steering, @bids-standard/maintainers, @bids-standard/raw-eyetracking, @bids-standard/bep042, @smoia, @m-miedema, @arnodelorme is essential to ensure BIDS remains both comprehensive and coherent.

[robertoostenveld]

Hi Yahya,

This is something I also raised back in 2020, but then rather from the perspective of the instruments used to record the data, rather than the features of the data. See this google doc, with good comments from various people. Looking back at this and considering the EMG use-case that triggered it for you, I would say that EMG is recorded with a "biopotential amplifier".

Back then I did not manage to come up with an answer to the issues that were raised then and that you also raise here, but perhaps the arguments provided in the google doc might still be helpful.

best regards,
Robert

[julia-pfarr]

Hi @neuromechanist, following up on todays discussion in the maintainers meeting: We are going to draft an email with the most important points and pointing to existing issue(s)/doc(s) to send out to the BIDS community for discussion. We believe this is an important first step to gather more substance for forming a decision in the near future. Hope this is in your interest!

[neuromechanist]

Thanks very much @julia-pfarr. Yes please.
I agree that we might not be able to reconcile years long discussion in a short time period. But, we have the EMG-BIDS to help consider the issue with concrete example, use-cases and consequences.

I tried to generalize the points from EMG-BIDS discussion above to consider the larger picture. I think both ways (discussing the general case or just this special case) works well.

[m-miedema]

This is a great start to considering this issue with a broader lens, thank you!

One of the main points we discussed in the case of physio data is that it can be unclear to know where to look for this data if it is not treated as a data type as well as a modality. For example, we can consider a dataset in which simultaneous EEG-fMRI were recorded, along with concurrent physiological data. Currently, as an auxiliary measure, we understand that the physiological data could be arbitrarily placed in either the eeg or func folder. We think that a good reason to treat physio as a data type is to reduce this ambiguity, but it would be good to understand if similar concerns are being raised in this or other discussions!

[Hboni]

We faced a similar issue in BEP024 regarding Computed Tomography (CT). We asked if CT data might fall under the anat data type, as it is anatomical data, or under a specific ct data type (we did not address the possibility of using the pet data type for PET/CT acquisitions, as we want to handle CT data acquired without PET). Since the anat data type is used for MRI data, we concluded that using a new data type would be more consistent, as CT is a different imaging modality. This makes MRI treated differently than other imaging modalities.

Having a policy document on existing data types and what to consider when adding a new data type is important, as it has been mentioned.

[ericearl]

I love this discussion and discussion points. Though I am concerned a GitHub issue may not be the best place to explore the answers? I think if we want to get to the bottom of this without a huge GitHub issue discussion post (that makes it hard to read and follow along), we should consider something like a CryptPad survey or Google Form for the 6 major questions above, where all responses are public to catch all the context.

Then I think we (the BIDS maintainers) could host a more organized open meeting for the BIDS community to hear the results of the survey and discuss each point and proposed solutions one by one. Either that or perhaps bring the proposed solutions back to the community here on the https://github.com/bids-standard/bids-specification/discussions page? One discussion for each of the 6 key questions above.

Respond with a thumbs-up emoji here if you would prefer that method to try and resolve these key questions. Otherwise, of course, I am still open to continuing the discussion here if that is the community's preference.

[mszinte]

Dear Yahya,

I'm in charge of the BEP020 about eyetracking (I hope we can finish it very soon).
However these answers reflect just my opinion and not necessarily the one of the BEP020 group.

What should be the threshold criteria for creating a new data type vs. using an existing one?
That could be nice indeed, as when we started the BEP020 we first just looked at what was done before and indeed decided to create a new type, before realizing that in our case it wasn't really necessary nor optimal.

Should brain-derived signals be treated differently from other physiological signals? If yes, how this differentiation applies to the current specifications, including Motion-BIDS and ongoing PRs.
I think this is a tricky point, as what is a brain-derived signals, in the case of eyetracking it is the position of the eyes but researchers believe that eye position and pupil is a proxy to brain states, eyes are themselves part of the brain... I'm not sure this is where the debate should go.

How should we balance the need for specificity against the risk of fragmentation?
Such a tricky question, fragmentation in long run will potentially be a very big burden, my opinion that motivate our decision of not creating the new eyetrack entity was purely simplicity. Also eyetracking these days, is a particular modality that often is the additional measure, together with fMRI, EEG, behavior, etc... it was another argument in favor of putting it with the "main" recording modality.

Should we establish a formal policy for what constitutes grounds for a new data type/modality?
Yes

How can we ensure that similar types of data (e.g., various physiological recordings) are treated consistently across the specification?
What is the threshold or recommendation for using the data specific modality/recording versus embedding data under other modalities for example, Eye-tracking and EMG can be embedded under EEG as channels.
These are specific questions I will not try to answer at that point.

In general my opinion is just that as long as it is possible to do with the minimum of changes (no data type), it is the way to go.
Note that eyetracking is specific. I feel that the choice we made was the good one. I first wasn't convinced, as I felt it was a bit reducing the impact of that BEP, but at the end what matters is to optain a standard for open science.

Best,

[neuromechanist]

we should consider something like a CryptPad survey or Google Form for the 6 major questions above, where all responses are public to catch all the context.

Either that or perhaps bring the proposed solutions back to the community here on the https://github.com/bids-standard/bids-specification/discussions page?

+1, Reaching out to the community with the questions as a Google Forms etc surely adds to the visibility. The downside is that people can't read each others opinion, but I think we can link the discussions to this issue, so that everyone can follow up and contribute.

Still, everyone is welcome to point out your views here, if you don't want to wait for the Google Form to come in.

[markmikkelsen]

I, alongside @wtclarke and @martin3141, worked on BEP022 for MRS. While it was clear to us from the outset that MRS, despite being a nuclear magnetic resonance technique like MRI, should be its own data type in BIDS. Discussions centered more on modalities, specifically whether single-voxel MRS and MRS imaging should have separate suffixes. Ultimately, we decided that they should, given that single-voxel MRS and MRSI are normally utilized as standalone MRS modalities in experiments.

1. What should be the threshold criteria for creating a new data type vs. using an existing one?

If a method is sufficiently used and reported on in the literature to be considered a standalone biophysical data collection technique. For example, if an entire subdiscipline has grown out of this method; there are specialist journals, textbooks, and scientific meetings focused on that method; one could reasonably call oneself an "x" scientist when speaking in lay terms, e.g., "I'm an MRI scientist" as opposed to "I'm a diffusion MRI scientist" (though the latter does make sense if you're in MR research); etc. (These are just examples and not meant to be firm criteria.)

2. Should brain-derived signals be treated differently from other physiological signals? If yes, how this differentiation applies to the current specifications, including Motion-BIDS and ongoing PRs.

I'm not entirely sure what this question is getting at. I'm assuming they will be because the methods to detect them are technologically distinct?

3. How should we balance the need for specificity against the risk of fragmentation?

This one's tricky. I wonder if user demand will determine the balance. That is, if a method user makes the case that a certain method should be its own data type in BIDS, demonstrating why an affiliated method's BIDS specification does not share important characteristics of the user's method's data and metadata.

4. Should we establish a formal policy for what constitutes grounds for a new data type/modality?

Yes.

5. How can we ensure that similar types of data (e.g., various physiological recordings) are treated consistently across the specification?

I'd say @effigies and I went back and forth a number of times on just this for MRI and MRS. I think the review of BEPs from those outside the BEP team handles this well enough. But it's essential that an expert user of a related modality, who may not necessarily be a BIDS maintainer, also reviews the BEP.

6. What is the threshold or recommendation for using the data specific modality/recording versus embedding data under other modalities for example, Eye-tracking and EMG can be embedded under EEG as channels.

Tricky. I think my answer to this follows my answer to question 1.

[arnodelorme]

I suggest that a data type in BIDS should warrant its own folder if it can be distributed and meaningfully interpreted independently of other modalities. By this criterion, both EMG and eye tracking merit their own folders. Using two mechanisms—sometimes assigning standalone folders, other times embedding as modalities—introduces inconsistency and complicates data reuse.

A key challenge remains synchronized acquisition across modalities. Without a formalized BIDS mechanism to declare temporal alignment between folders, it’s difficult to ensure data integrity when modalities are split. A potential solution is to define a standard for synchronization markers or events shared across modalities, allowing cross-referencing in a principled way as for BIDS motion capture. Formalizing such criteria and synchronization strategies would enhance clarity, consistency, and interoperability within BIDS.