Working Group - Standards Discussion

[Sulstice]

Synchrony with BBQS Admin - Current Checklist Items

[CodyCBakerPhD]

Questions for Multi-subject Research Teams

• Which signals belong to a single subject, and which signals inherently describe a relationship or interaction between two or more subjects?
• For each shared or relational signal, what is its dimensionality at each time point: scalar, vector, matrix, image/grid, or higher-dimensional array?

Standards Readiness

• BIDS standard meta-issue, which points to other existing approaches, issues, and BEPs related to multi-subject: Multi-subject / grouped recordings in BIDS: meta-issue with pointer to overview wiki page bids-standard/bids-specification#2512
• NWB multi-subject extension: https://github.com/nehatk17/ndx-multisubjects

Discussions for Enhancements

Problem: The current approach of creating SelectSubjectsContainer to group data that uses a select subset of subjects is limited in that it leads to a potential explosion in the number of objects, depending on the combination of subjects that are interacting with each other.

Proposal 1: Create SelectSubjectVectorData, which would be a DynamicTableRegion that, combined with a SelectSubjectVectorIndex, allows definition of subsets of subjects for rows in a table. This will be useful, e.g., in the EventsTable to allow recording of events of subject interactions and have each event indicate the participating subjects.

Proposal 2: Expand TimeSeries to have an optional additional last dimension for subject, which would allow storing data from multiple subjects in a single TimeSeries. The SelectSubjectVectorData and SelectSubjectVectorIndex would then be additional optional datasets in the TimeSeries to annotate the last dimension and indicate the subject(s) the recording applies to. This would then allow combining recordings from multiple subjects in a single time series.

Note: If we modify TimeSeries in the core, this would still require modifying all derived TimeSeries types to add a corresponding additional permissible shape. So not all TimeSeries would automatically become multi-subject. Also, in the schema this would likely create cases where we have multiple different allowable shapes with the same number of dimensions. E.g., an ImageSeries may allow (time, x, y) and (time, x, y, z); adding (time, x, y, subject) and (time, x, y, z, subject) would mean we have two shapes with 4 dimensions but with different contents. We would therefore need a way to label the axes, and the main distinguishing factor is whether the SelectSubjectVectorData is present.

Note: This would be a major change to the core schema and not just a simple extension. We could test this in an extension by creating a new explicit MultiSubjectTimeSeries and select subtypes, but integration with the core would then be non-trivial. A better approach may be to implement this directly in a branch/fork of the nwb-schema as an unstable version.

---

🤖 Generated with Claude Code

https://chat.dartmouth.edu/c/6185a921-69e4-4327-bbf2-4bb30aab7171