Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add DeviceModel neurodata type #607

Open
rly opened this issue Feb 5, 2025 · 2 comments · May be fixed by #608
Open

Add DeviceModel neurodata type #607

rly opened this issue Feb 5, 2025 · 2 comments · May be fixed by #608
Labels
category: proposal proposed enhancements or new features

Comments

@rly
Copy link
Contributor

rly commented Feb 5, 2025

Problem

We discussed today at the NWB meeting the need in both https://github.com/catalystneuro/ndx-ophys-devices and https://github.com/catalystneuro/ndx-extracellular-channels for a neurodata type that represents the model of a device as opposed to a specific instance of a device model and the configuration of that instance.

In new NWB schema 2.8.0, we added an optional string attribute to Device: Device.model to try to handle this in a simple way. However, this could be improved.

Having a separate DeviceModel object, with model properties like manufacturer, that is linked to from Device has the following advantages:

  1. It deduplicates information when there are multiple instances of a device model present in a session (e.g., multiple Neuropixels 1.0 probes were used and have the same manufacturer and locations and sizes of 960 physical contacts)
  2. It is useful when combining data across sessions in a relational database (or archive) to say that these devices use the same model. We built this into Spyglass (ref) where there are a handful of probe types with model-level properties but many different instances of a probe type that have different configurations.

Proposed solution

Create a new DeviceModel type that has a name, manufacturer (string, required), model_number (string, required), and description (string, optional).

  • Unfortunately, we added Device.model_name and Device.model_number in the 2.8.0 release, perhaps too hastily. I propose we deprecate those in Device and recommend users use their equivalents in the new DeviceModel type.
    • Note that PyNWB has not yet released support for 2.8.0 (a release candidate is out though).
    • Note that MatNWB added support for 2.8.0 in main but has not yet made a release
  • Device.manufacturer has been around for some time. I propose we also deprecate that and recommend users use the equivalent in the new DeviceModel type.

An aside: Device identifiers

For cross-session and cross-experiment harmonization of devices (e.g., "find all the NWB files on DANDI that used a Neuropixels 1.0 probe"), ideally everyone uses the same DeviceModel name to represent the same real-world device model, e.g., "Neuropixels 1.0" for a Neuropixels 1.0 probe (as opposed to variations like "NP1.0" or "Neuropixels"). And ideally someone would maintain a registry of devices and their unique identifiers, like an RRID, for those devices. Not only would that aid harmonization, downstream users could use the identifier to access more thorough information about the model on an external website. ProbeInterface contains a limited library of probe models that are identified by the manufacturer and model name (so no change is needed here). We could create and maintain a registry for all NWB device models, but I think that would be a significant undertaking and responsibility, and perhaps a separate discussion.

@rly rly linked a pull request Feb 5, 2025 that will close this issue
3 tasks
@rly rly added the category: proposal proposed enhancements or new features label Feb 5, 2025
@h-mayorquin
Copy link
Contributor

+1 on this.

@alessandratrapani
Copy link

I support this proposal. Here is an example of how it could be used: PR#5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: proposal proposed enhancements or new features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants