Closed allynt closed 7 years ago
This can either be hard-coded; ie: always treat model.simulates and realm.processes as a hiearchy, or it could be a customization.
The treeview would look something like:
Where I can find all the "simulates" of a "model" and all the "processes" of a "realm" and all the "sub-processes" of a "process"
There are multiple properties that can support a hierarchy.
At the model level there is SIMULATES which points to realms. At the realm level there are PROCESSES which points to process. At the process level there are SUB_PROCESSES.
At the model level there is also There is also COUPLED_COMPONENTS and INTERNAL_SOFTWARE_COMPONENTS which point to software_components.
During ontology ingestions, the Q can mark a proxy as "hierarchy". And there will also be some recursive fn to extract a hierarchy from a QModelProxy.
For CMIP6 only the former hierarchy path will be used to construct a treeview.
Other projects may use the latter hierarchy path instead of or in addition to the former one. I do not know how to render multiple hierarchy paths and am deferring that task [#526].
How to distinguish between relationships that ought to use subforms vs those that ought to use references.