Metadata field to clarify relative timing of concurrently-acquired data groups

[m-miedema]

An issue that we've discussed in our physiological BEP is that the current specification's use of StartTime relies on the data's relation to a poorly-specified corresponding neural dataset. This leads to several potential problems:

• Physiological data may be accompanied by several neural datasets (e.g. simultaneous EEG-fMRI or EEG-fNIRS)
• Physiological data may be acquired separately from other modalities (our BEP proposes the treatment of physiological data as its own modality)

Our proposed solution would be to introduce a novel non-modality-specific metadata key "ConcurrenceGroup", semi-inspired by the B0FieldIdentifier metadata. The relevant definition and updated definition for StartTime can be found in our BEP document here. [add summary or link to section of our repo's schema]

This would solve several issues in the wider BIDS eco-system:

• Nonphysiological modalities could equally benefit from the use of the StartTime metadata key
• The requirement level of the StartTime metadata could be conditional based on the definition of the ConcurrenceGroup metadata

We'd like to discuss this idea with the wider BIDS community, since we're still trying to understand how this idea could complement or conflict with the wider eco-system. Some previous issues that may provide complementary context are:

• Discussion of the use of time stamps and latency here. We'd like to discuss this with the [add tags for motion BEP] team especially, since we believe that the definition of the metadata field ConcurrenceGroup would complement that of Latency (which essentially to our understanding performs the same function as StartTime but with a channel-specific scope)
• Discussion of timing offsets here, which mentions PET's ScanStart and TimeZero metadata

[m-miedema]

https://bids-specification.readthedocs.io/en/stable/glossary.html#acq_time-sense-1-columns

As per our current interpretation, the use of acq_time could point to the reference (StartTime=0) within a ConcurrenceGroup, but doesn't address the temporal relationship of files within a ConcurrenceGroup.

The handling of multimodal recordings in scans.tsv is currently poorly documented - it's not obvious how to handle that. @smoia is bringing up the example of a multi-echo multi-component recording where all files are listed (and could have acq_time defined), which brings up the example of whether to list all files within a ConcurrenceGroup in the scans.tsv file or to only include the reference.

https://bids-specification.readthedocs.io/en/stable/modality-agnostic-files/data-summary-files.html#scans-file
(Currently, simultaneously-acquired EEG-fMRI for example could each have an acq_time specified - but we're not breaking anything by suggesting not doing this.)

[m-miedema]

@me-pic what is the best example to use?

[m-miedema]

To do: update the content of this issue and the section in the BEP doc based on the discussion we had here #8 (hyper-scanning example!)

[smoia]

We might want to specify the main rationale behind ConcurrenceGroup, in particular if it is meant to (A) group together the "main" file in different modalities (e.g. EEG & fNIRS or physio and first echo of multi-echo fMRI) that relates to the same run or if it (B) should group together ANY file that relates to the same run (thus including e.g. multi-echo files .

In the former case, it would be sufficient for one file to be defined in the scan.tsv, with every other file in the same ConcurrenceGroup to be related via the StartTime. However, how would this match the fact that you have e.g. multi-echo files that must all be listed in scan.tsv? Are they not equally concurrent? Why?

In the latter case, ALL files would have to be included in the ConcurrenceGroup AND listed in the scan.tsv file (similarly to what is the current behaviour for e.g. qMRI or multi-echo) with their correct acq_time that might be similar but jittered to one another (this will be the case for many specs where it's easier to mark the beginning of an acquisition rather than making everything start at the exact same time). Then, scan.tsv is not sufficient to describe concurrent acquisitions and ConcurrenceGroup specifies which of the jittered files are meant to be used in a concurrent multimodal scenario, later realigned with StartTime.

This also helps truly realigning hyperscanning data. (See #8)

Latency from Motion BIDS seems to be column specific and better suited for non-uniform sampling rates, so it does not seem to solve the issue better than ConcurrenceGroup and StartTime.

[me-pic]

@m-miedema For the dataset example: https://github.com/physiopy/bids-specification-physio/tree/ds-examples/physio_rest_fmri

@smoia @Sourav-Kulkarni @ShiyuBelleWang if any of you would have time to double check the example dataset, it would be amazing 🚀

@smoia @m-miedema I was not sure if the inclusion of anat/ and fmap/ folders were necessary. There are some example in the bids-examples repo with only func/, but if you think it would be more complete, I could add those folders

[m-miedema]

I did a deeper crawl through previous BIDS issues trying to clarify the relationship between our proposed metadata field and the use of acq_time in the scans.tsv and found this very relevant hibernating issue: bids-standard#86

As well, in trying to understand LATENCY better, I found this issue: bids-standard#1462. I'm still quite confused about whether it is channel or sample-specific (since it seems to itself be a column?), so hopefully the EMG folks will be able to clarify once we migrate this conversation to the main BIDS spec. This issue makes me think it is indeed a channel with sample-specific information.