Question: Is link export handled differently in `PoseEstimation` compared to a dynamically generated hdmf/pynwb class?

[ehennestad]

I was running the example for writing pose estimates and tried to open the file in MatNWB.

Some of the (soft) links in the PoseEstimation were not parsed by MatNWB. There are two problems

1. MatNWB does not support reading "link arrays" as can be encountered in the devices property of PoseEstimation
2. The link for the skeleton property is saved into the file with the given name, i.e subject1_skeleton, whereas MatNWB expects the link to be named skeleton, like the property. Looking at some examples from pynwb, i.e the ecephys tutorial, the device of an ElectrodeGroup is saved using the property name it is added to, not it's given name.

I am working on a fix for 1), but wondering if there is a discrepancy for scalar links comparing the PoseEstimation class and HDMF generated dynamic classes. I see that PyNWB handles/supports both cases (i.e it can read scalar links with any name and place them under the correct property), but MatNWB currently does not. Is this a limitation in MatNWB that should be fixed?

If yes, is there a rule for when the given name is used for export and when the property name is used? Is this interchangeable?

[ehennestad]

Ok, so it seems to be happening because the skeleton link is not named in the specification:

ndx-pose/spec/ndx-pose.extensions.yaml

Lines 127 to 129 in d2ffeba

	- target_type: Skeleton
	doc: Layout of body part locations and connections.
	quantity: '?'

MatNWB currently assumes all "scalar" (i.e quantity: ? (0 or 1)) objects are named, and therefore is not handling this properly. We have agreed that this is a bug in MatNWB that should be fixed.

But it also raises the question of whether there is a reason the skeleton link is not named, and whether it should it be?

[ehennestad]

But it also raises the question of whether there is a reason the skeleton link is not named, and whether it should it be?

I realise you already discussed this here:
NeurodataWithoutBorders/nwb-schema#638 (comment)