proposed change: ProbeType class

[bendichter]

@oruebel @rly and I reviewed this and worked through how it would be integrated with the core schema.

One of the shortcomings of the extension as is, is that you would have a lot of repeated information if you have a bunch of the same probe. Consider an experiment with 5-6 NP probes implanted simultaneously- each one would need to duplicate the exact same ContactTable. Instead, we could create a new type, ProbeType, which contains information about the probe model, e.g. contact table, geometry of shank information, manufacturer. The Probe object would have an optional attribute probe_type which would link to a ProbeType object. The Probe class would also contain metadata about a specific probe object, e.g. the serial number.

Another change the addition of Shank objects, which are contained within a ProbeType. The optional shank column of the ContactTable is an object reference to one of the shanks in that ProbeType. This would allow users to extend the Shank class to add custom metadata to shanks.

[khl02007]

@bendichter @oruebel @rly Thanks for the suggestions.

• I think it's a good idea to separate the information specific to a probe (e.g. serial number) from information common to all probes of the same type (e.g. related to contacts).
• re: ProbeType and Neuropixels probes: as you know, these probes have more contacts than channels, and the same probe can be used in multiple configurations, each with different set of 'active' contacts. Should this information be included in ProbeType or Probe? If latter, then Probe would still need something like a ContactTable.
• @alejoe91 @samuelgarcia should weigh in here on whether Shank deserves to be its own data type. We had implemented it in an earlier version but removed it based on the thought that information about a shank can just be added to the set of contacts that constitute the shank as a column in ContactTable. We also already have ElectrodeGroup to specify information about an arbitrary set of electrodes. But I'm not opposed to this idea.

[oruebel]

• We also already have ElectrodeGroup to specify information about an arbitrary set of electrodes.

Just a quick note, to make the logic of this consistent, we were considering to potentially deprecate ElectrodeGroup as part of a potential path for eventually integrating the extension with the core schema.

• each with different set of 'active' contacts.

As far as I recall, the ElectricalSeries or ElectrodesTable would reference the contacts that are being used for recording a particular trace. As such, I think it's Ok for a ContactTable to contain both active and inactive contacts.

• Should this information be included in ProbeType or Probe?

In principle, the information of which contacts are being used should be encoded in the ElectrodesTable / ElectricalSeries. However, I agree that having the information of active/inactive contacts explicitly available in the Probe will be useful.

At first glance, I think it makes sense to have ProbeType focus on information that is common for a probe and have Probe capture instance-specific information. In that vain, information about the configuration of the probe seems to belong in Probe. One way to represent the information on active contacts could be to have and optional Probe/active_contacts datasets that would be a DynamicTableRegion pointing to the ContactTable (i.e., this would be a list of ints). The alternative would be to have an optional column active on the ContactTable but then for each configuration one would need to create a new ProbeType.

[rly]

Adding our notes

[rly]

Ping @mavaylon1

[samuelgarcia]

Hi Ryan,
I am agree that having Shank as object is too heavy for storage.
A simple columns with shank_id (or similar) in the contact table should enough I think.