Use clean fiber photometry terms; add photometry table and device types

[bendichter]

This implements the changes I proposed in dandi#1665, targeting your add_ndtypes branch so they land there rather than as a competing PR.

The photometry types now use "fiber photometry approach" and "fiber photometry technique" as plain single terms. The semicolon-joined strings would each have become a single unfacetable MeasurementTechniqueType name, and "calcium imaging" is inaccurate for the many photometry dandisets that use dLight or GRAB sensors to measure neurotransmitters rather than calcium (000251, 000351, and 001434 are examples). With single terms per type, the existing str | None fields are sufficient, so the map's structure is unchanged. If we later want a type to emit multiple terms, BareAsset.measurementTechnique and .approach are already lists in dandischema, so that would be a CLI-only change.

I also added the metadata table types from the deprecated ndx-photometry (FibersTable, ExcitationSourcesTable, PhotodetectorsTable, FluorophoresTable) and the container, table, and device types from ndx-fiber-photometry (FiberPhotometry, FiberPhotometryTable, OpticalFiber, ExcitationSource, Photodetector, Indicator), so files carrying only those still get marked. For reference, the smaller sessions in 001632 contain no photometry types at all, only the events tables, so they will remain unmarked regardless.

I dropped dandi/metadata/neurodata_typemap.py for now since nothing imports it and it would drift from the map in util.py. I think the expanded map is valuable and worth reintroducing once it is wired in as the single source of truth, ideally together with the organize.py change that would make the module field drive filename suffixes.

Tests updated accordingly, including a new case checking that the ndx-photometry tables alone produce the photometry approach. test_metadata.py passes locally.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Wuywpnnb3Q57q6oeMZ4God

[bendichter]

@rly

[rly]

OpticalFiber, ExcitationSource, Photodetector, Indicator are not unique to the photometry extensions. They are all defined in ndx-ophys-devices and imported by ndx-microscopy or ndx-optogenetics, as well as ndx-fiber-photometry.

dandi-cli does not disambiguate based on namespace, but it should. That's a larger change, though, outside the scope of these PRs.

Since matching is done by exact string match and subtypes do not inherit, we can also add DeconvolvedFiberPhotometryResponseSeries and MultiCommandedVoltage from ndx-photometry and FiberPhotometryIndicators, FiberPhotometryViruses, FiberPhotometryVirusInjections from ndx-fiber-photometry, and CommandedVoltageSeries from both.

Re: the semicolon issue, this is a pre-existing pattern. For example, TwoPhotonSeries maps to "microscopy approach; cell population imaging" on master and published dandisets carry the compound string with the semicolon, e.g., https://dandiarchive.org/dandiset/000049. It would be best to change this to a list of strings, perhaps, in a separate PR.

I agree that "calcium imaging" is inappropriate for many photometry data. Whether calcium was imaged can be detected using Indicator.label / FluorophoresTable.label inside the file, but there's no straightforward way to do that within the current framework. I checked ten photometry dandisets and none contain a RoiResponseSeries, so nothing else will supply an imaging-family term for them. Once entries are lists, I would like photometry to emit both "fiber photometry approach" and "cell population imaging". For now, no imaging term is better than an inaccurate one.

OK to delete dandi/metadata/neurodata_typemap.py. I agree - we can discuss introducing that in a separate PR rather than have it hold up addition of photometry and other extension types to the map.

Since I know you're out of office, I'll make the above changes to your PR and merge it so that we keep the momentum going.

[rly]

Thanks for bringing this back and suggesting dropping the neurodata_typemap for now!

[rly]

Looks like I can't modify this PR directly even though maintainerCanModify: true because GitHub computes that permission against the root of the fork network, dandi/dandi-cli, where I have push: false. So I'll merge this into my branch and make commits on top of it.