BIDS related: potential change of .fif file split naming

TL;DR

would it be a big problem to change the FIF file “bids-style” split naming from _part-X to something else? (see: https://github.com/mne-tools/mne-python/blob/861e82505ce59e7ea84887227d6066776bdc6401/mne/io/utils.py#L298-L310)

---

When .fif files grow too large, they need to be split into chunks. In a BIDS context, where each file name follows a structure, we need some way to deal with this.

In 2017 or 2018 @jasmainak and @teonbrooks (I think? … somebody else?) suggested to use *_part-X_meg.fif with the X being a number to define different parts of the same .fif recording.

Some context before the issue: The _part- syntax was (accidentally) not fully introduced into the specification: It is only a non-elaborated example in an appendix, see:

https://bids-specification.readthedocs.io/en/stable/99-appendices/06-meg-file-formats.html#neuromagelektamegin

This leads to the issue that now several other BIDS extension proposals want to use _part- and have started using it --> because they were not aware that it is already being used in MNE (because as I said, _part- is only mentioned in a non-elaborated example in an appendix).

The complete issue is here: https://github.com/bids-standard/bids-specification/issues/429

The fight is essentially whether or not it’s OK for MEG/MNE to claim _part- for themselves although it was never properly introduced into the spec.

One pragmatic solution is to

1. drop the non-elaborated _part- example from the appendix of the BIDS spec
2. properly introduce a new way to name split .fif files with a new PR to the BIDS spec (e.g., _split-X
3. adapt MNE-Python to use that new, proper way (e.g., _split-X), and deprecating MNE support for the now invalid _part-X

This part of MNE would have to change:

https://github.com/mne-tools/mne-python/blob/861e82505ce59e7ea84887227d6066776bdc6401/mne/io/utils.py#L298-L310

There are other solutions described in the BIDS issue thread (I summarized them in this comment) but there are several parties with strong opinions, and if the pragmatic solution proposed in THIS issue is not a big deal for MNE folks, then going with this solution would resolve the BIDS issue in a straight forward way.

cc @robertoostenveld @effigies @yarikoptic

[robertoostenveld]

| I have no strong feelings there, but it does seem that the term “segment” is often being used interchangeably with “epoch” …

Agreed, using “segment” for recordings that are split over multiple files because of technical reasons (i.e. 2GB file size limits) has the risk that people would confuse it with “segment” for task-related reasons, where repeated trials (in the task) are analyzed by cutting the data into segments (or epochs) corresponding to those trials. We don’t want an epoched .fif file to be represented in a whole bunch of files, one per trial.

Hereby I also upvote split in favour of segment.

Perhaps we should (somewhere) clarify this terminology of split, segment, epoch, and trial.

[hoechenberger]

I have no strong feelings there, but it does seem that the term “segment” is often being used interchangeably with “epoch”, see e.g.:

https://mne.tools/dev/auto_tutorials/index.html?highlight=segmented#segmenting-continuous-data-into-epochs

https://mne.tools/dev/auto_tutorials/raw/plot_30_annotate_raw.html?highlight=segment#creating-annotations-programmatically