electrode schemas

[lzehl]

@aeidi89 mentioned this (possibly interesting): https://www.biorxiv.org/content/10.1101/447995v1.full.pdf

• seems like this paper is looking exclusively at how to track and analyze electrodes in slice histology
• this might be approach-wise closer to tracks of biopsies

Nonetheless good to keep in mind. And of potential interest for the image service I guess. Please see the next comment for the schema approach I could imagine to capture types/structures of electrophysiology electrodes.

[lzehl]

Let me start with a couple of definitions / assumptions: 1) an electrode is considered to be a physical element (shaft, disk) that has at least one recording point/surface a) an electrode should have an identifier 2) the recording point/surface of an electrode is called electrodeContact 3) an electrodeContact is defined by it's identifier, central coordinate point (coordinate) and shape a) a coordinate of an electrodeContact is typically captured in a file 4) an electrode can be used independently as single electrode or be part of an electrodeArray a) a multiple contact electrode should define it's inter-contact-distance 5) an electrodeArray is defined by wiring multiple electrodes together into one hardware system a) an electrodeArray should have an identifier b) an electrodeArray should define it's inter-electrode-distance

[lzehl]

Now let me summarize the basic outline of electrode schemas based on the previously stated definitions / assumptions:

1) coordinate.schema.json 1.1) coordinate [expects: array of three number-items] 1.2) coordinateSpace [expects: object, ref to coordinateSpace.schema.json]

2) electrodeContact.schema.json 2.1) identifier [expects: string] 2.2) coordinate [expects: object, ref to coordinate.schema.json] 2.3) definedIn [expects: object, ref to fileInstance.schema.json] 2.4) type [expects: object, ref to electrodeContactType.schema.json] 2.5) relatedRecordings [expects: object, ref to fileInstance.schema.json] 2.6) relatedStimulations [expects: object, ref to fileInstance.schema.json]

3) electrode.schema.json 3.1) identifier [expects: string] 3.2) electrodeContact(s) [expects: array of objects, min: 1, ref to electrodeContact.schema.json] 3.3) interContactDistance [expects: number+unit] 3.4) type [expects: object, ref to electrodeType.schema.json]

4) electrodeArray.schema.json 4.1) identifier [expects: string] 4.2) electrode(s) [expects: array of objects, min: 1, ref to electrode.schema.json] 4.3) interElectrodeDistance [expects: number+unit] 4.4) type [expects: object, ref to electrodeArrayType.schema.json]

5) electrodeContactType.schema.json (this is not yet well defined) 5.1) semanticShape [expects: enum ("tip", "disk", "ring")] 5.2) numericShape [expects: enum of objects (tipShape.schema, diskShape.schema, ringShape.schema)]

6) electrodeType.schema.json (this is not yet well defined) 6.1) recordingType [expects: enum ("intracellular", "extracellular", "patch")] 6.2) semanticShape [expects: enum ("shaft", "disk")] 6.3) numericShape [expects: enum of objects (shaftShape.schema, diskShape.schema)] 6.4) manufacturer [expects: string]

7) electrodeArrayType.schema.json (this is not yet well defined) 7.1) type [expects: enum ("2D-electrode-array", "3D-electrode-array", "EEG-cap", "ECoG-array")] 7.2) manufacturer [expects: string]

@blixilla & @GMattheisen : what do you think about the suggested schemas as a start point? [please make direct references to the schemas/properties you want to discuss by using the numbers in the lists]

[blixilla]

@lzehl I think this is a good starting point. I think it makes sense to have this hierarchy with electrodeArray/electrodes/electrodeContacts.

I tried to play around and apply it to a rat use-case, the one with an EEG array (these are epidural electrodes, more precisely surgical implantation of a chronic array of 17 stainless steel electrodes covering most of the cortical areas of a rat brain); and then some questions arose:

In general, would you say SANDS is intended to contain metadata necessary for visualization in the atlas viewer, or should it also contain other interesting metadata for the user (e.g. 6.4 manufacturer). What is covered by openMINDS? What is covered in your schemas, @GMattheisen?

2.3: would this be an image or imaging volume?

3.3: is this essential positioning information? if all the coordinates is already defined - will this be calculated automatically? do you perhaps have an example? :)

4.3: same comment as above + is this supposed full coordinate lists for electrodes within an array? How easy would it be to provide, and with what precision?

5.1: just curious, in what case would 'ring' apply? :)

5.2 and 6.3: is this physical dimensions of electrodes/electrodeContacts? Do these schema files exist somewhere? What kind of information do they contain?

6.1: What would it be for an intrusive epidural EEG electrode?

7.1: For this example we need an option appropriate for an array of intrusive EEG electrodes. EEG cap would maybe not fit that well, what do you think?

I hope these questions made sense, otherwise I would be happy to get a more thorough explanation of how this schemas would be used.

[GMattheisen]

7.2, 6.4 Manufacturer (datatype: str) You may also want to allow for distributions. I have encountered numerous datasets where they array is a custom build and it is good to link out to the paper, pdf, or the like for a description.

We also discussed the possibility of a flag as a property of electrodecontactschema (2). I have seen data where channels are dropped or tagged if they recording quality is low or the recording lost before the end of the experiment. If the data user wanted to pull just the good recordings for analysis work/visualization, adding a tag would make for a great filter.

[lzehl]

@blixilla thanks a lot for your comments. Here my feedback:

"In general, would you say SANDS is intended to contain metadata necessary for visualization in the atlas viewer, or should it also contain other interesting metadata for the user (e.g. 6.4 manufacturer). What is covered by openMINDS? What is covered in your schemas, @GMattheisen?"

• for now SANDS should focus on how to provide metadata necessary for the atlas viewer
• SANDS schemas should on the long run be extended with in-depth metadata that are of interest (so, for now, we could leave out manufacturer in 6 "electrodeType" & 7 "electrodeArrayType")
• so far purchasable hardware devices are not captured as schemas in openMINDS (6 & 7 are a workaround for this)
  • a general schema for hardware devices could be interesting, possible properties (example: Utah Array):
  • manufacturer (Blackrock Microsystems)
  • name (Utah Array)
  • description (xxx)
  • connector (Cereport)
  • type (microelectrode array)
  • array (link to electrodeArray schema)

@GMattheisen: is any of this already captured in one of the in-depth schemas? maybe in neuroshapes?

2.3: would this be an image or imaging volume?

• electrodeContact would be defined by a coordinate not an image
• therefore the fileInstance would most likely point to a CSV, TSV, JSON, that stored that coordinate point, example:
  • tabular file with contact ID, x, y, z, unit as header
• in case of the paper that is mentioned in the first comment of this issue, we could also allow pointing to an image with a drawn in coordinate @blixilla what do you think?

3.3: is this essential positioning information? if all the coordinates is already defined - will this be calculated automatically? do you perhaps have an example? :)

• this is a good question, because in case we are in the native coordinateSpace of the electrode (meaning patient space) this could indeed be calculated
• we could get coordinates of electrodeContacts that are alread transformed into a common space, here the calculation of the inter-contact-distance will be most likely erroneous, because usually the spatial relation between contacts gets lost in the transformation process
• therefore I thought it might be good capturing it in any case
• we could leave it out for now, because I'm not sure if it helps the visualization

4.3: same comment as above + is this supposed full coordinate lists for electrodes within an array? How easy would it be to provide, and with what precision?

• see above (should be the same)

5.1: just curious, in what case would 'ring' apply? :)

• out of my head I have two examples:
  • deep brain stimulation (DBS) electrode (one shaft-electrode with typically 3-4 contact rings)
  • stereotactic EEG electrode (one shaft-electrode with typically 10 - 20 contact rings)

5.2 and 6.3: is this physical dimensions of electrodes/electrodeContacts? Do these schema files exist somewhere? What kind of information do they contain?

• yes, it would be the physical dimension of an electrode/electrodeContact
• no, these schemas do not yet exist (@GMattheisen: or do you have them in the in-depth metadata defined somewhere?
• I would imagine something simple for each semantic shape, such as:
  • tipShape.schema properties:
  • length (value+unit)
  • diameterTip (value+unit)
  • diameterBase (value+unit)
  • diskShape.schema properties:
  • diameterMax (value+unit)
  • diameterMin (value+unit)
  • height (value+unit) [might be, in principle, 0 in some cases]
  • ringShape.schema properties:
  • diameterMax (value+unit)
  • diameterMin (value+unit)
  • width (value+unit)
  • shaftShape.schema properties:
  • length (value+unit)
  • diameterTip (value+unit)
  • diameterBase (value+unit)

6.1: What would it be for an intrusive epidural EEG electrode?

• should be extracellular (as far as I know there is no further distinction of extracellular, except for the type of the recorded signal, e.g. MUA, LFP, EEG)

7.1: For this example we need an option appropriate for an array of intrusive EEG electrodes. EEG cap would maybe not fit that well, what do you think?

• yes, the list I posted might need more extensions, although we need to be careful with the definitions
  • ECoG array would possibly fit your needs already
  • question is if we should specify the overall location of the electrodes somewhere (e.g., epidural, subdural, intracranial, extracranial, etc.)

[blixilla]

@lzehl Sounds good to focus on viewer integration 👍 Thanks for all the thorough explanations :)

a few comments:

2.3: Ah, of course. For many of the rodent cases there are only very few coordinate pairs, so I was thinking we would write them directly in the JSON. Yes, I was thinking that the fileInstance could be directed to an annotated image.

3.3 and 4.3: I see, yes, I guess we can leave it out for now.

5.1: thanks :)

5.2 and 6.3: Sounds good.

6.1: yes, makes sense.

7.1: yes, could be nice to discuss this detail in a later meeting.

and lastly: Have you tried to set up an example JSON for a (real) human case, yet? Would it be possible to do this at this point, do you think?

[lzehl]

:slightly_smiling_face: you're welcome!

for 2.3: I was originally thinking that electrode coordinates should be always saved in a separate file, but I agree that this might be inconvenient in some cases. So linking to an image as source as well could simplify this. On the other hand we need to rethink this a bit what it means for the rest of the model... specifically the annotation.schema.json and the image.schema.json. I think in such cases where the coordinate comes from an annotated image it should be covered as annotation.

for 7.1: I would say let's start with the easy cases and then gradually extent the list.

To lastly: I suggest that I write down the code for these schemas and then get in touch with you for creating examples early next week?

[blixilla]

Cool, that sounds like a good plan :)

[lzehl]

Decisions made for the electrode schemas (present: @UlrikeS91 , @aeidi89 , @blixilla , @lzehl ):

• leave out manufacturer property for now (push it to in-depth part of the schemas)
• do now go into detail about the Types (can be resolved/discussed also later and is not needed for a first working version of the schemas for atlas viewer purposes)
• implement first version of schemas in elements asap (@lzehl)

[Majpuc]

Hi, nice progress on electrodes! I wonder if you have considered injection electrodes used for tract-tracing experiments? I guess all your already defined metadata will fit well and some additional ones specific for this type could be added, like electrode entry point, depth and injection volume ?

[apdavison]

@Majpuc I think the injection volume would belong to the in-depth metadata. Depth seems like it belongs in SANDS, as this is definitely spatial information, but perhaps that information is already available in the coordinates, or can be calculated from the coordinates and the position of the cortical surface in the atlas?

[Majpuc]

Yes, a valid point. If both the coordinates of the entry point of the electrode and the contact point (the tip) are recorded, this can be calculated. Thanks!

[UlrikeS91]

@apdavison I agree with you on the injection volume. The depth however is is tricky to calculate at the moment. The way it is planned at the moment, we won't capture the entry point of the electrode, only the contact point of the tip in the brain. Given that electrodes can be inserted with an angle (on purpose or by accident), the distance to the cortex surface would only be an estimation of the depth. It will give some information, but I don't think it's as exact as @Majpuc is looking for, right?

@apdavison How important do you think this information is for ephy electrodes? Do you think it's crucial for a 1st version of the electrode schema or rather additional information that would be nice to have but isn't that crucial?

I think for injection electrodes this is very important, since injections tend to spread around the tip and along the entire tract of the electrode. For tract tracing experiments, this would be crucial information. Transfection could have taken place at any of those areas then which can have a big impact on the results/findings.

@lzehl Do we want to include an entry point coordinate already for ephy electrodes (e.g. as optional property)?

[apdavison]

@UlrikeS91 Depth is critical, as it tells you which layer (and hence which possible cell types) you are recording/stimulating in. It is often measured precisely using histology, so probably it would be best to have a field for it even if it could in principle be calculated.

[UlrikeS91]

@UlrikeS91 Depth is critical, as it tells you which layer (and hence which possible cell types) you are recording/stimulating in. It is often measured precisely using histology, so probably it would be best to have a field for it even if it could in principle be calculated.

Thanks for the info, Andrew. I assume that Lyuba will respond herself later too, but if not, I'll point this out to her in our next meeting.

[lzehl]

@Majpuc glad you like the basic layout of the electrode schemas :slightly_smiling_face: I would assume that capturing metadata for tract-tracing of injection electrodes would be an extension to the current set of schemas. I currently would aim for that tract-tracing as performed in the paper mentioned at the top of this issue, would be captured in the annotation.schema.json (which would need a revision then) or as it's own schema (e.g., tractTrace.schema.json) which could be attached to the electrode.schema.json. Or one could add indeed a schema for the injection point of the electrode (penetrationPoint.schema) and assume that the trace is the linear connection between the coordinate stated in the electrodeContact and the penetrationPoint. Any preferences, feedback are appreciated for this :slightly_smiling_face: @apdavison : what do you think? Would this be a simple extension to SANDS which would be compatible to the in-depth metadata?

@apdavison considering depth: I was thinking of defining shape schemas for electrodes and contacts which should then also include the length of an electrode (cf comments above). If you think this would be beneficial for SANDS, it would be great to get help / feedback here. I left it out for now, because it is not so relevant for the EBRAINS atlas viewer team (they currently mainly need the electrodeContact coordinate for the data that can define this, e.g. sEEG data).

[Majpuc]

@lzehl Thanks for considering this. I don't have any strong preference but it seems that having a (penetrationPoint.schema) might be useful for all electrodes. I'll let you decide :)

[UlrikeS91]

@lzehl I think we can close this issue, right?

[lzehl]

Leave this one open for now. I want to hear back from @apdavison first and verify again if we have a good fit with in-depth extensions.

[apdavison]

@lzehl I think we need to separate electrode and electrode-placement. The length of an electrode doesn't necessarily tell you the depth(s) of the recording point(s). For single electrodes and for small arrays such as tetrodes, the penetration depth is adjusted in order to find good cells, while for electrode arrays I guess the local curvature of the surface could affect the penetration depth of individual electrodes in the array (not sure if this latter point is significant).

Concerning good fit with in-depth extensions, don't worry too much about that, as we will revise the extensions to fit with whatever is decided for openMINDS core and SANDS.

[lzehl]

@apdavison I agree with you. The implemented openMINDS_SANDS schemas focus now purely on the device (hierarchy) and an already identified coordinate point for the electrode contact. The process of getting to this coordinate point is not necessarily provided / described in openMINDS.

I think right now the openMINDS_SANDS schemas could be easily extended with more "pure" device information (length, shape, impedance, type, etc.). Some of those could be already optional properties in SANDS (maybe the ones that might be useful for visualization in the atlas viewer, or the general context [type, e.g. "linear electrode array"]) but I think most of it should/could be tier 3.

I'm closing this issue for now. We can get back to it in a new issue, if we need to further discuss extensions for the currently implemented electrode schemas in SANDS