Closed bendichter closed 2 months ago
Okay I'll work on that. But quick question. What's the deal with the different versions in the specifications?
Why are multiple versions embedded in the NWB and how do I know which to use?
I really don't know. @rly, should this be permitted?
Good question. If there are multiple versions, the latest version according to semantic versioning should be used. I don't recall why multiple versions are allowed in the file given that individual neurodata type objects are not versioned and PyNWB/HDMF (and I think MatNWB) just uses the latest. This happens when appending to a file that was written with an older version of NWB than what is currently loaded. Probably the old schema was just not deleted. I created a ticket in HDMF to resolve it.
@bendichter Neurosift now respects all neurodata type inheritance in the way you suggested.
There is also a new tab called "specifications" that provides tables of all the namespaces, spec-groups, and spec-datasets in the file.
the widget works great on this example and the spec tab is great too!
In this example:
https://neurosift.app/?p=/nwb&url=https://fsbucket-dendro.flatironinstitute.org/dendro-outputs/2d2b13fd/2d2b13fd.ec254350/output&dandisetId=000871&dandisetVersion=draft&dandiAssetId=407d6e5f-2a16-4879-b38f-b74cad7b9e24&st=lindi
There is a neurodata object of type "EllipseEyeTracking". Looking at the spec in the Raw, this type inherits from the core type "EyeTracking." In cases like this, would it be possible to inspect the type hierarchy of the cached spec and try rendering this object with the visualization of the parent class?
This is how NWB Widgets works, not just for extensions but in fact for all neurodata types. If there is no widget defined for that neurodata type, it traverses the line of inheritance looking for the nearest parent for which a widget is defined. In this way, all neurodata objects have at least some corresponding widget.