...
- Is upward linking via "parent" a broken aspect of Device instance?
- For "it is broken": it's not consistent with the currently prevailing thinking about DeviceDefinition: it does not provide for reuse of "part" data structures; it does not provide for multiples (and counts) of subordinate DeviceDefinition
- For "it is not broken": instance attributes (Devices) are affected by different use cases and needs are different than for kind attributes (Device).
- Device.parent has the advantage of enforcing strict containment hierarchy by not permitting more than one parent, and there is simplicity in maintenance of consistent state that way.
- Multiples and counts of Device instances contained by a Device instance. But Device instances have distinct identity and independently determined attributes.
- Reusability: If you want to preserve attributes of a Device instance between times it has a parent (say, you are switching a module to a different host device), you are free to persist it in a state where it has no parent, and provide it with the new host as a parent at the appropriate time)
- Certainly, equivalent logic can be accomplished with hasPart in the superordinate Device, but is there a killer use case in which it is unconditionally better?
...