How to handle sessions involving multiple subjects

[niksirbi]

Sometimes experiments are performed with multiple subjects in a single session (e.g. videos of two mice interacting). Given BIDS' emphasis on always putting the subject-level directory at the top, I don't see an easy way to resolve this. I think multi-animal experiments will get increasingly common, so it makes sense to support them somehow.

This problem has been discussed a lot in this issue.

Any thoughts on this @JoeZiminski ?

[JoeZiminski]

This is a good point, argree it is not clear how best to support this without somehow breaking BIDS. It would be interesting to see how these experiments work in practice (I don't have much experience with such experiments) to get a feel for how complicated it would be and how the data is stored already.

I see there was some discussion of a 'pool' level. Maybe having this 'replace' sub-XXX and then move sub- to the lowest level e.g.:

.
└── project_name/
└── raw_data/
├── pool-001/
│ ├── ses-001/
│ │ ├── sub-001/
│ │ │ └── some_behavioural_data
│ │ └── sub-002
│ └── ses-001_video.mp4
└── pool-002/
└── ses-001/
├── sub-003
└── sub-004

but this could get confusing if e.g. mice are interacting with lots of different other mice so there are many combinations / pools. Alternatively, maybe keeping the current folder structure and doing everything by pairing mice in the meta-data, though if there is one feed e.g. MP4 for both mice I guess this wouldnt work

[niksirbi]

I had some ideas on this recently, which would require minimal modifications to our current schema.
Consider the following project:

└── project/
    └── sub-001/
        └── ses-001/
            └── behav/
                ├── sub-001_ses-001_task-discrim_monitor-right_run-001.mp4
                ├── sub-001_ses-001_task-discrim_monitor-left_run-001.mp4
                └── sub-001_ses-001_task-discrim_monitor-right_run-002.mp4
     └── group-A/
        └── ses-001/
            └── behav/
                ├── group-A_ses-001_task-interaction_run-001.mp4
                ├── group-A_ses-001_task-interaction_run-002.mp4
                ├── sub-001_ses-001_task-interaction_run-001.mp4
                └── sub-002_ses-001_task-interaction_run-001.mp4
     └── groups.yaml

The idea is that we create a new reserved keyword (group or pool) on the same level as sub. Groups and single subjects can be intermixed within the same project, provided that we require a groups.yaml ( or groups.json) file at the top level, in which the correspondence between groups and subject is specified, e.g.:

group-A:
  - sub-001
  - sub-002
group-B:
  - sub-001
  - sub-003
group-C:
  - sub-004
  - sub-005
  - sub-006

There is endless flexibility, one can have as many subjects and groups as required, and each subject can appear in multiple groups. They only requirement is that each unique subset of subjects that appears in the project has a unique group ID (specified in the groups.yaml file.

I don't see any immediate problems with this solution (though probably I can't see very far). It also works in weird scenarios. Imagine an experimenter performs a group-A session with 2 mice (sub-001 and sub-002). During the same session they acquire videos of both mice together, as well as videos where each mouse is alone in the setup. This could be still indicated on the level of file names, as shown in my initial example. No need to create additional levels of the hierarchy.

[adamltyson]

@niksirbi I like it.

There's no reason why (at least conceptually, if not semantically) a subject needs to be one mouse. A subject could be one mouse, a group or an entire population.

Adding one new reserved keyword and an additional yaml file caters to any experiment I can think of at the moment (even more complicated behavioural experiments in other species).

[niksirbi]

@yarikoptic made us aware that a similar discussion has taken place for MRI hyperscanning (aka scanning 2 individuals in a single session, performing social tasks). See relevant thread.
See also this googlegroups discussion.