Easy way to create multi-level containers ?

[etiennedemontalivet]

Hi,

I was wondering if there is an easy way to create container of containers ? Let say I have SpatialSeries that are made of the joint positions (markers) of 2 legs. I'd like to have the data structured like this:

root (NWBFile)
> ...
> acquisition
    > ...
    > legs
        \/ left
            \/ spatial_series
                > marker1
                > marker2
                > marker3
        > right 

Is there an easy way to do so ? If not, is there a reason to not save the data in such structure ?

I tried playing around with NWBDataInterface and add_child method but without success:

Code here

```python

import numpy as np
import pynwb
from datetime import datetime
from dateutil.tz import tzlocal
from pynwb import NWBFile

start_time = datetime(2017, 4, 3, 11, tzinfo=tzlocal())
nwbfile = NWBFile(
    session_description="demonstrate advanced HDF5 I/O features",
    identifier="NWB123",
    session_start_time=start_time,
)

data = np.arange(100, 200, 10) # fake data
timestamps_l = np.arange(10) # fake ts
timestamps_r = timestamps_l + 1 # not sync
positions_l = []
positions_r = []
# we add 3 markers per leg
for i_marker in range(3):
    positions_l.append(
        pynwb.behavior.SpatialSeries(
            name=f"left mvt_{i_marker}",
            description=f"left mvt_{i_marker}",
            data=data,
            timestamps=timestamps_l,
            reference_frame="unknown",
        )
    )
    positions_r.append(
        pynwb.behavior.SpatialSeries(
            name=f"right mvt_{i_marker}",
            description=f"right mvt_{i_marker}",
            data=data,
            timestamps=timestamps_r,
            reference_frame="unknown",
        )
    )

motions_l = pynwb.behavior.Position(spatial_series=positions_l, name="left leg")
motions_r = pynwb.behavior.Position(spatial_series=positions_r, name="right leg")

leg = pynwb.core.NWBDataInterface("leg")
leg.add_child(motions_l) # I don't see what this does
leg.add_child(motions_r) # I don't see what this does
nwbfile.add_acquisition(leg)
nwbfile # but then there is nothing in leg ?

```

Also I think that what I want is doable if defining an extension, but I would prefer an easier way if it exists :).

Any help would be much appreciated!

[CodyCBakerPhD]

Sounds like this is for pose estimation data - is this from DeepLabCut, SLEAP, or lighting pose? If so you can use the automated converters from NeuroConv

If not, it sounds like the extension you want to use is ndx-pose (it's a very popular one): https://github.com/rly/ndx-pose

[etiennedemontalivet]

Thank you for your answer!
So it's not possible with the current pynwb library ? I'm asking because ndx-pose could fit my needs for this example, but I have other use-cases such as multiple ECoG recording systems (with different timestamps), same for EMGs,...

[CodyCBakerPhD]

The extensions are mixable with pynwb

pynwb is simply the 'core' of the most common (and oldest) neurodata types; extensions, especially popular ones like ndx-pose exist to allow users to mix and match neurodata types in whatever way is needed to best represent the experiment

So while you could in principle only use pynwb.SpatialSeries, ndx-pose might be a better overall representation of your setup

[etiennedemontalivet]

But if only using pynwb.SpatialSeries (or pynwb.ElectricalSeries), is there a way to create a multilevel architecture in the nwb file so that it looks like :

root (NWBFile)
> ...
> acquisition
    > ...
    \/ emg
        \/ system1
            resolution: ...
            comments: ...
            description: ...
        \/ system2
            resolution: ...
            comments: ...
            description: ...
        > system3

PS: I am referring to this structure:

[CodyCBakerPhD]

For acquisition specifically, that is harder to do

For processing, you can nest them within different and appropriately named processing modules

High levels of nesting are also going out of favor as time goes on; it is becoming a more modern best practice to use a flatter structure with richer object names (with the names effectively absorbing the nesting into them; in your case, the emg object could have the system detail appended to it)

Otherwise, it would only be possible in the EMG case with a custom extension

[etiennedemontalivet]

Thanks a lot for the detailed answers !