Introduce AnatomicalCoordinatesTable

[h-mayorquin]

From the introductory comment on #1.

@bendichter @stephprince and I are also proposing a separate object (CoordinatesTable?) to store the estimated localization and confirmed localization of electrodes in some reference space and atlas. It would have coordinates, brain area, method, and reference space information. One object for estimated, one object for confirmed using method 1, one object for confirmed using method 2 (in case there are two). Each CoordinatesTable would point to the ElectrodesTable. (Under the model of #1, each CoordinatesTable would have had to point to both ChannelsTable objects above or be duplicated, which are not ideal.)

I think this is a great idea for the reasons defended on #1 here

I don't really like having the estimated and confirmed positions as canonical attributes in the channels table. I think that the proposal on #3 of relegating this to an AnatomicalCoordinatesTable is better for the following reasons. First, separation of concerns between the description of the ecephys setup and experiments of localization. I think is nice to decouple those two things so they can evolve on their own. If the localization experiments improve we then only need the change to AnatomicalCoordinatesTable or link into a better extension without making parts of our schema obsolete. Second, in the case of SpikeGLX where two channels map to one contact we will end up with redundant information. Plus, even within the current schema I don't like the canonization of estimated_{} as a set of single columns. I think that confirmed_{x} is a great name but what if there is more than one estimate? Right now those are optional attributes and maybe something like this is needed urgently in which case is fine but I still wanted to point out what I think are flaws of this design.

So I think that the ChannelsTable can be linked per-row to a new AnatomicalCoordinatesTable and that would decouple and solve some of the problems that we have been discussing.

One thing with this approach though is that the mapping between an anatomical site (a row of the AnatomicalCoordinatesTable) and a ProbeInsertion is not explicit but indirect in the current schema.

[h-mayorquin]

Important discussion how does this fit into the considerations of #4 .

[bendichter]

yes but the anatomomical coordinates table is in a separate repo here: https://github.com/bendichter/ndx-anatonical-localization

[h-mayorquin]

I think is even better if a different extension takes responability of specifying locations.

Reading the schema it seems that the current estimated_position_{x}_in_mm would be a single column maping to an AnatomicalCoordinatesTable which is a dynamic table so that makes sense.

I also think that another good reason to decouple localization from here is that this extension can be used to store results from in-vitro experiments and the current {}_position_{x}_in_mm do not really make sense for those cases.