Bids-specification: hyperscanning data storage

[manipulative]

Does bids have any idea or planning about storing hyperscanning data?

[effigies]

I haven't seen anybody discussing it up to this point, but BIDS is open to contributions. What sort of additional data/metadata would be needed to support hyperscanning?

For others who might not be familiar with the term, it's simultaneous fMRI with multiple subjects, introduced in https://doi.org/10.1006/nimg.2002.1150.

[manipulative]

I haven't seen anybody discussing it up to this point, but BIDS is open to contributions. What sort of additional data/metadata would be needed to support hyperscanning?

For others who might not be familiar with the term, it's simultaneous fMRI with multiple subjects, introduced in https://doi.org/10.1006/nimg.2002.1150.

the most important thing I concerned is the unit of data. Basiclly, the unit of hyperscanning design is dydic — two participants have shared experiment parameters, timing and duration. So, it is easy to think store data in dyadic unit. But most BIDS specifications' unit are individual.
do you have any idea about this unit problem?

[chrisgorgo]

There was a discussion and a proposal for covering hyper scanning back in the mailing list days. See https://groups.google.com/d/msg/bids-discussion/53i7ZKSo8eo/i3bTw96TCAAJ. Sadly it was not finalized due to lack of interest, but maybe @manipulative could lead this effort.

[yarikoptic]

Bids already has a session, so I would just place all participants data from the same hyperscanning session under the same session, and have minimally sufficient way to group them properly.

[manipulative]

@yarikoptic do you mean you group participants under a dyadic by session?

[yarikoptic]

Yeap, why not? ;-)

[manipulative]

@yarikoptic Hi Yarikoptic~
Normally data with sessions in bids are stored in the form of:

sub-01/
    ses-01/
        sub-01_ses-01_task-<label>_<contrast_label>.nii[.gz]
    ses-02/
        sub-01_ses-02_task-<label>_<contrast_label>.nii[.gz]
sub-02/
    ses-01/
        sub-02_ses-01_task-<label>_<contrast_label>.nii[.gz]
    ses-02/
        sub-02_ses-02_task-<label>_<contrast_label>.nii[.gz]

and you regard session as dyadic and switch subject and session into this form:

ses-01/
    sub-01/
        sub-01_ses-01_task-<label>_<contrast_label>.nii[.gz]
    sub-02/
        sub-02_ses-01_task-<label>_<contrast_label>.nii[.gz]
ses-02
    sub-03/
        sub-03_ses-02_task-<label>_<contrast_label>.nii[.gz]
    sub-04/
        sub-04_ses-02_task-<label>_<contrast_label>.nii[.gz]

Do I understand it right? Thanks for your attention

[effigies]

You can't invert the sub-*/ses-* directory structure, but you can still do something like:

sub-01/
    ses-dyadic1/
        sub-01_ses-dyadic1_*
sub-02/
    ses-dyadic1/
        sub-02_ses-dyadic1_*
sub-03/
    ses-dyadic2/
        sub-03_ses-dyadic2_*
sub-04/
    ses-dyadic2/
        sub-04_ses-dyadic2_*

[manipulative]

Thanks for your advice~ @effigies
But in some naturalistic hyperscanning study (for some fnirs or eeg-based study), there are some shared large data files across dyadic like video-recording.
Storeing them twice in two subject subfolder is obviously a waste of space. Should I add a specific dyadic folder to store such data?
Like:

rawdata/
    singledata/
        sub-01/
            ses-dyadic1/
                sub-01_ses-dyadic1_*
        sub-02/
            ses-dyadic1/
                sub-02_ses-dyadic1_*
        sub-03/
            ses-dyadic2/
                sub-03_ses-dyadic2_*
        sub-04/
            ses-dyadic2/
                sub-04_ses-dyadic2_*
    dyadicdata/
        ses-dyadic1/
                ses-dyadic1_video.mp4
        ses-dyadic2/
                ses-dyadic2_video.mp4

[tsalo]

Video data isn't supported in the specification, so I think you'd just put that in sourcedata. For any supported file types (e.g., an events file) where the data are identical within dyad, I think you could leverage the inheritance principle so you're storing only one copy:

rawdata/
    ses-dyadic1_task-X_events.tsv
    ses-dyadic1_task-X_events.json
    ses-dyadic2_task-X_events.tsv
    ses-dyadic2_task-X_events.json
    sub-01/
        ses-dyadic1/
            sub-01_ses-dyadic1_task-X_*
    sub-02/
        ses-dyadic1/
            sub-02_ses-dyadic1_task-X_*
    sub-03/
        ses-dyadic2/
            sub-03_ses-dyadic2_task-X_*
    sub-04/
        ses-dyadic2/
            sub-04_ses-dyadic2_task-X_*
sourcedata/
    ses-dyadic1/
        ses-dyadic1_video.mp4
    ses-dyadic2/
        ses-dyadic2_video.mp4

[effigies]

If it's a stimulus video, it can go in stimuli.

[manipulative]

Video data isn't supported in the specification, so I think you'd just put that in sourcedata. For any supported file types (e.g., an events file) where the data are identical within dyad, I think you could leverage the inheritance principle so you're storing only one copy:

rawdata/
    ses-dyadic1_task-X_events.tsv
    ses-dyadic1_task-X_events.json
    ses-dyadic2_task-X_events.tsv
    ses-dyadic2_task-X_events.json
    sub-01/
        ses-dyadic1/
            sub-01_ses-dyadic1_task-X_*
    sub-02/
        ses-dyadic1/
            sub-02_ses-dyadic1_task-X_*
    sub-03/
        ses-dyadic2/
            sub-03_ses-dyadic2_task-X_*
    sub-04/
        ses-dyadic2/
            sub-04_ses-dyadic2_task-X_*
sourcedata/
    ses-dyadic1/
        ses-dyadic1_video.mp4
    ses-dyadic2/
        ses-dyadic2_video.mp4

I finally applied the way like you said. v
Videos in my experiment are recordings of participants' behaviors, and their sizes are large. So I just put them in sourcedata and only store coded video data in BIDS