Comments regarding “ConcurrentWith” and "StartTime" metadata field

[ShiyuBelleWang]

1. We want to introduce metadata field "ConcurrentWith" as a unique identifier shared between all concurrently acquired data. However, scans.tsv (link) might be able to achieve the same task (comment here).
2. The Latency channel introduced by motion-bids (link) might be similar to "StartTime" field we proposed to adapt for clarifying the temporal offsets among concurrent channels (comment here)

[ShiyuBelleWang]

3. If a recording starts after another recording finishes(comment here), how does the current scope of "StartTime" address that
4. If we have suboptimal physio data, for example manually recorded SpO2 signals at regular intervals (without triggers), can "ConcurrentWith" and/or "StartTime" cope with such recordings? (comment here)

[ShiyuBelleWang]

Regarding comment 3:
@m-miedema, @Sourav-Kulkarni, @me-pic, @mrikasper : we could have a universal start time field, regardless of whether the recording is interrupted/restarted (the length of the recording would make it clear); it is just a way to align these recordings

[ShiyuBelleWang]

Regarding comment 4:
@m-miedema: Should still indicate the "ConcurrentWith" and "StartTime", but need to specify in the description (how recordings are started, if the recording was obtained manually, etc)
@mrikasper: Is there a field that describes how the trigger was obtained? -> triggers are always recommended to be saved with the recording as one of the channels, and are the best way to align the data

[me-pic]

Regarding comment 3: potentially consider using the split key to separate files that are associated with the same run (e.g., in the case of recording interruption during the run, for example software crash)

[ShiyuBelleWang]

For comment 1: we will clarify the distinction between scans.tsv and "ConcurrentWith" field in the document
For comment 2: "StartTime" is a field that already exists, and we would like to keep the consistency with previously defined fields

[mrikasper]

We also considered replacing the field name ConcurrentWith by ConcurrencyGroup or ConcurrentGroup to emphasize that different recordings with the same value here don't have to be completely concurrent (e.g., start a bit later or end earlier, or one recording type is split into different file, whereas the other is not), but rather have some overlap in time that makes analyzing them together plausible.

[m-miedema]

To do: bring back to BIDS community for discussion.