embed path in generated matnwb objects

[bendichter]

Currently, in order to create SoftLinks, References, etc. the user needs to know the HDF5 path of the target object. It would be better if the user could just input the object itself rather than a path to that object. The way to solve this would be during export, to take the resolved path of each object and write it as a property within that object. Then we can use that property to resolve links. This would have the added benefit that each object would contain its HDF5 path, which they could use in other software.

[bendichter]

@ln-vidrio is this feasible to implement? I think this would open the door for building shortcuts that would make the package more useable in several places. Right now it's hard to automate the construction of DynamicTables because you need to know the path of the objects.

[lawrence-mbf]

So a few thoughts on an approach that seems doable: 1) View objects add a property which takes objects. You still require Views in places that require them but it's still explicit and doesn't require a lot of changes in the data type check. Furthermore, you'd still need some wrapper class for region references. 1) Objects also must hold a private property which is only populated on the first pass of the export call. This is checked by the wrapping View object if its own path property is empty.

A few minor holes in this design:

• If an object is actually duplicated across multiple parts of the NWBFile, unpredictable behavior occurs as it's ambiguous which path the reference is actually referencing.

Any other ideas/improvements or other issues with this design?

[bendichter]

@ln-vidrio

I like the idea of being able to enter either a path or an object. I also think it's fine to require wrapping the object in an ObjectView as opposed to the PyNWB approach of just passing the naked object and having the API automatically determine whether it is a link child or a true child. That makes the linking more explicit anyway.

about the minor hole: If an object is duplicated, then I guess the path will resolve to one of the identical objects but you won't be able to control which one? I think that's fine. If it does occur, it probably won't be a problem to link to an arbitrary one. If it is important to link to a specific one, then it makes sense that the user either needs to create a duplicate object that is identical or disambiguate by explicitly defining the path.

[lawrence-mbf]

There is one more hole actually. For region references, you need to directly point to a dataset. For objects tagged as datasets I can assume that the data property is what is being indexed. However, if a RegionView is given a non-dataset object, it most likely must be paired with a property name or a target dataset, I guess as a cell array pair. EDIT Unfortunately, given that a class cannot derive full paths based on a property name, this is simply not possible.