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

[rob-luke]

Hi @effigies and @manipulative (& FYI @lpollonini),

The topic of hyperscanning has been raised in the fNIRS BEP30 as it is a common experimental paradigm with this technique. The approach proposed by @effigies above (#402 (comment)) appears suitable and I will add reference to this in BEP30.

But the topic of hyperscanning seems relevant across a number of modalities, and as such, seems like it should have a common definition in BIDS. For this reason I think we will avoid putting an explicit definition of hyperscanning in to BEP30 as this would lock us in to a specific scheme and may complicate a common hyperscanning BEP in the future. Has there been any further work on this topic that I can link to in BEP30?

I am not suitable to lead an effort in this as I don't do hyperscaning.