Improved optogenetics support in vanilla NWB.

[TheChymera]

I was wondering whether instead of using an extension it might make sense to improve the optogenetics capabilities of vanilla NWB.

The reason why I think this might be a good idea is that the current optogenetics support has a couple of issues which might be a bit closer to errors rather than simply incomplete features.
In particular the first 3 issues can't really be fixed by adding new classes and would need to be changed in the classes already present.

1. currently the stimulation wavelength is an attribute of the OptogeneticStimulusSite class which is used as an attribute of the OptogeneticSeries class --- the wavelength is not specific to a site, but to the actual stimulation series, so it should be moved to OptogeneticSeries.

2. Further, the naming for the wavelength is excitation_lambda, “excitation” is a hypothesized result and not a parameter of the stimulation, further, the nomenclature isn't really consistent with optogeneticcs where opsins are commonly “activated” or “inactivated”, which in turn can lead to either neuronal “excitation” or “inhibition” depending on the opsin. So the name itself should also be changed to something like e.g. wavelength to avoid confusion.

3. OptogeneticStimulusSite is currently listed as having an attribute named Device. This is a bit backwardds since the stimulation happens with the involvement of one or multiple devices, which then have locations. Things necessitate places, places don't necessitate things. So OptogeneticSeries.Device.OptogeneticStimulusSite instead of the current OptogeneticSeries.OptogeneticStimulusSite.Device would be the correct way to go about this in principle --- though for the specific meaning of Device OptogeneticSeries.Device without any relationship to the OptogeneticStimulusSite would be the way to go:

4. Device seems to refer specifically to the device which produces the stimulation, so the Laser/LED. This device doesn't have any experimentally meaningful location. It's somewhere in the lab.

5. There is however a device which is crucial to the stimulus delivery, and needs to be documented, namely the optic canula. This should be a new class (in the extension linked above OpticFiberImplant --- though perhaps OpticFiberCannula would be an even better name with reuse potential), which is then connected to the other classes as OptogeneticSeries.OpticFiberImplant.OptogeneticStimulusSite. Proposed attributes for this class are listed in the extension.

6. Other than the two attributes which might be considered for removal as per the arguments above, the current OptogeneticStimulusSite class is left with two arguments: description and location; which seem largely equivalent and only qualitatively informative. Further, differentiating OptogeneticStimulusSite from a general-purpose location specifier or at least a surgical location specifier seems superfluous. Ideally there should be a class which can specify surgical intervention targets to be reused by anything which requires such a procedure. Again, the linked extension proposal contains such a class, OrthogonalStereotacticTarget with a number of proposed attributes providing quantitative unambiguous information.

@rly , what do you think? There was a discussion on Optogenetics improvement before but you said it would be contingent on more interest :) We're quite interested!
@yarikoptic

[yarikoptic]

• as discovered -- the referenced @TheChymera 's fork of @bendichter is functionally identical . May be worth to submit a PR to @bendichter with recommended changes to make it easier to grasp suggested changes
• re workgroup to discuss extension/proposal: https://dandiarchive.org/dandiset/search?search=optogenetics returns 5 dandisets ATM. Worth checking how they did optogenetics data types and bringing those users to discussion (note: all earlier dandisets were probably converted by @bendichter and his group)