Skip to content

Conversation

@rly
Copy link
Contributor

@rly rly commented Dec 11, 2025

Summary of changes

Requires changes in PyNWB.

Checklist

For all schema changes:

  • Add release notes for the PR to docs/format/source/format_release_notes.rst.
  • Have you included the relevant issue number using "Fix #XXX" notation where XXX is the issue number? By including "Fix #XXX" you allow GitHub to close issue #XXX when the PR is merged.
  • Make sure that hdmf-common-schema points to the latest release and not the latest commit on the main branch.

If this is the first schema change after a schema release (i.e., the version string in core/nwb.namespace.yaml does not
end in "-alpha"), then:

  • Update the version string in core/nwb.namespace.yaml and core/nwb.file.yaml to the next major/minor/patch
    version with the suffix "-alpha". For example, if the current version is 2.4.0 and this is a minor change, then the
    new version string should be "2.5.0-alpha".
  • Update the value of the version variable in docs/format/source/conf.py to the next version without the
    suffix "-alpha", e.g., "2.5.0".
  • Update the value of the release variable in docs/format/source/conf.py to the next version with the suffix
    "-alpha", e.g., "2.5.0-alpha".
  • Add a new section in the release notes docs/format/source/format_release_notes.rst for the new version
    with the date "Upcoming" in parentheses.

@rly rly requested review from h-mayorquin and oruebel December 11, 2025 01:02
Copy link
Contributor

@h-mayorquin h-mayorquin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great to see this moving forward. Two suggesions/questions on my side.

data is calculated, the contents of 'sync' are mostly for archival purposes.
quantity: '?'
links:
- name: device
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- name: device
- name: acquisition_device

Maybe this would make the expected use more clear?

links:
- name: device
target_type: Device
doc: Device used to record this time series. This should not be used to represent
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
doc: Device used to record this time series. This should not be used to represent
doc: >
Teh device that directly acquired the samples stored in this TimeSeries.
This field captures data acquisition provenance only and must refer to the
device that digitized or otherwise recorded the signal.
When multiple hardware components are involved (e.g., probe → headstage →
acquisition system), this field must refer to the acquisition system itself,
i.e., the device that digitized the data, not upstream sensors or
hardware.
This field must not be used to encode causal, control, or stimulation
relationships. For example, it must not refer to devices that delivered
optogenetic or electrical stimulation, triggered task events, or generated
control signals. Such relationships should be represented elsewhere in the schema.

Two sugggestions:

  1. Clarify what happens in multi-device acquisition chains like in a typical ecephys setup where we have: probe/head-stage -> DAQ/acquisition box. I thinks this fit nicely there as we don't have a way of storing the DAQ (the probe/headstage can be encoded in the ElectrodeGroup device). The same or microscopy where the ImagingPlane captures the device but not the acquisition box that was used to acquire the data.

  2. More concrete examples of what should not be here.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature]: Add optional device linking to TimeSeries

3 participants