proposal: store 3D positions of probes e.g. electrodes

[bendichter]

Currently, in the dandi-atlas, we need to process each asset and extract 3D electrode positions in a common reference image coordinates system. We store this in JSON files in the repo, which is working for now, but it means this data is not standardized or centralized into asset metadata for use across all DANDI applications. How would we feel about adding a field to incorporate this data? This would essentially need to mimic our ndx-anatomical-localization extension, including information about the reference space and coordinate system, and a reference to what type of device is being localized.

[satra]

perhaps extend equipment (

dandi-schema/dandischema/models.py

Line 1233 in 20544c0

class Equipment(DandiBaseModel):

) for this so that we capture that a specific electrode type is used as well as where it is.

[yarikoptic]

Check if alignment to datacite is possible

• Check/export new instruments metadata to datacite #254

then such metadata should be also included in datacite doi record

[satra]

also considerations of coordinate systems and space is quite limited in that extension relative to the extensive work in the neuroimaging community (which has dealt with space complications and hemispheric flips for a long time). we should thus be aligned with bids over here for this kind of information especially with regard to coordinate systems. https://bids-specification.readthedocs.io/en/stable/appendices/coordinate-systems.html

[bendichter]

I actually really like brain globe for standardization of multi-species atlases. It provides a common standard and API for 33 different atlases across diverse species, cloud-hosted images and meshes, and a unified API for loading and visualizing them. Our work on ndx-anatomical-localization is intended to plug into the brainglobe system for visualization. The metadata around the Space object is intended to be sufficient for this.

I worked with the BIDS system around coordinates systems closely in creating BEP32, and I don't find it nearly as nice. It's really just lists a table of references, but doesn't have a uniform API for loading the actual atlas and reference image data. Several of the entries don't even have any link to any reference material, and for those that do it's not always obvious how to navigate to the corresponding atlas data.

[satra]

for image-based templates there is an entire framework - https://www.templateflow.org/

i'm not talking about API but rather the relevant pieces of information that ensures left and right are actually encoded appropriately for nearly symmetric brains, and the reference spaces clearly have a notion of left and right.

[bendichter]

Thanks @satra I had never seen this before. It is not mentioned in the BIDS docs. This looks pretty analogous to brainglobe. Though I think it's worth noting this does not have complete coverage of the templates listed on BIDS:

BIDS Coordinate System	TemplateFlow Template	Match?
ICBM452AirSpace	-	No
ICBM452Warp5Space	-	No
IXI549Space	-	No
fsaverage	tpl-fsaverage	Yes
fsaverageSym	-	No
fsLR	tpl-fsLR	Yes
MNIColin27	tpl-MNIColin27	Yes
MNI152Lin	tpl-MNI152Lin	Yes
MNI152NLin2009a	tpl-MNI152NLin2009a{Sym,Asym}	Yes
MNI152NLin2009b	tpl-MNI152NLin2009b{Sym,Asym}	Yes
MNI152NLin2009c	tpl-MNI152NLin2009c{Sym,Asym}	Yes
MNI152NLin6Sym	tpl-MNI152NLin6Sym	Yes
MNI152NLin6Asym	tpl-MNI152NLin6Asym	Yes
MNI305	tpl-MNI305	Yes
NIHPD	-	No
OASIS30AntsOASISAnts	tpl-OASIS30ANTs	Yes
OASIS30Atropos	-	No
Talairach	-	No
UNCInfant	tpl-UNCInfant	Yes

12 out of 19 BIDS image-based coordinate systems have corresponding templates on TemplateFlow.

The 7 not on TemplateFlow: ICBM452AirSpace, ICBM452Warp5Space, IXI549Space, fsaverageSym, NIHPD, OASIS30Atropos, and Talairach.

[bendichter]

Anyway, back to the matter at hand. Equipment could work, but I would think of metadata within equipment to describe the equipment itself, not actions. We have several cases where a probe was implanted multiple times. Now this is usually done in different sessions so this wouldn't necessarily cause a problem, but if we ever wanted to represent these equipment objects as nodes in a graph then we would need to store the localizations as separate nodes so they could link to both equipment and session.