[Feature]: Add optional device linking to `TimeSeries`

[h-mayorquin]

This relates to writing data from NIDQ devices in the context of a SpikeGLX recording. A more complete discussion can be found here.

To summarize:

Analog channels from NIDQ devices can represent a variety of non-neural signals (e.g., motion, temperature, MEG). It’s unclear how best to store this information. One option is to save every channel as a separate TimeSeries (e.g., TimeSeriesMotionChannel1, TimeSeriesTemperatureChannel2, TimeSeriesMEGChannel3, etc.). This approach allows the TimeSeries description to include all necessary information and also to use other fields such as gains, offsets, and units for better provenance.

However, this approach has a downside: there is currently no formal way to indicate that all of these TimeSeries were recorded from the same device (the NIDQ board). I think it would be good for provenance if we had the option to link a TimeSeries object to a Device.

What do you think? Am I missing something?

Code of Conduct

• I agree to follow this project's Code of Conduct
• Have you checked the Contributing document?
• Have you ensured this change was not already requested?

[stephprince]

thanks for the issue @h-mayorquin

@rly @oruebel and I discussed this yesterday and think it's a good idea but we would need to investigate further to make a plan for the exact implementation.

One point that came up was that there are some TimeSeries that are not directly generated from a device but instead from a preprocessing step or script. In these cases having the option to link a device may not be appropriate.

One option to address this is to create a new intermediate TimeSeries type (e.g. "RecordedTimeSeries") that allows this optional device linking. To start implementing this approach, we should first take a look through all the types that inherit from TimeSeries and determine which ones would be a "RecordedTimeSeries" with optional Device linking vs. the current definition of TimeSeries without Device linking.

[h-mayorquin]

Hi guys, thanks for discussing my issue.

Yes, I thought that a sub-type of TimeSeries would be less disruptive since TimeSeries is so fundamental. You might not want a device on some of the children of TimeSeries for example. Slightly related would be the proposal of @rly here to separate Neural from Non-neural ElectricalSeries which could solve this problem as well (although, note the NIDQ electrical series should not be linked to electrodes).

The other possible solution to the NIDQ metadata problem would be to add a way of annotating channels. That way, I can use a single TimeSeries but then annotate the modality of each channel there. This goes close to the Xarray model of labeling dimensions and rows which might be nice but I guess that would require a big discussion among you guys.

[h-mayorquin]

Thinking more about this, what about just adding an Optional device link?

[rly]

Revisiting this discussion, we think it would be fine to add an optional link from TimeSeries to Device, and document specifically that the linked Device was used to record the time series data (instead of saying the time series was sent to the device for stimulation). No need for a new subtype.

We may want to add some consistency checks for types that already have a link to Device like PatchClampSeries.electrode links to a Device.