Repository navigation
[Feature]: Add optional device linking to TimeSeries #602
Description
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?
Activity
stephprince commentedon Dec 13, 2024
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 commentedon Dec 13, 2024
Hi guys, thanks for discussing my issue.
Yes, I thought that a sub-type of
TimeSerieswould be less disruptive sinceTimeSeriesis so fundamental. You might not want adeviceon some of the children ofTimeSeriesfor 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
TimeSeriesbut 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 commentedon Sep 3, 2025
Thinking more about this, what about just adding an Optional device link?
rly commentedon Dec 11, 2025
Revisiting this discussion, we think it would be fine to add an optional link from
TimeSeriestoDevice, and document specifically that the linkedDevicewas 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
DevicelikePatchClampSeries.electrodelinks to aDevice.