Each Subject in a BIS Repository can have one PhysicalPartition child Element, which will be sub-modeled by one “top-level” PhysicalModel, as shown below.
There are two ways to establish a hierarchy of Models:
- Via the
- Via sub-modeling
By building a Subject hierarchy with parent-child relationships among Subjects, the PhysicalPartitions and PhysicalModels associated with those Subjects can be organized hierarchically.
The subject hierarchy approach is used by iModel connectors and legacy applications, because it more closely maps to legacy ways of modeling.
Theoretically, the child Subject could have a relationship to some Element in the PhysicalModel of its parent Subject, in order to indicate that the child Subject’s PhysicalModel is modeling the same thing as the Element in the other model, though this has not been done in practice. It would be a more-flexible way of expressing that the child Subject's PhysicalModel is essentially sub-modeling an Element in the parent
Subject's PhysicalModel, as described below. In general, new classes of relationships could be invented to relate specific Elements to specific Subjects, regardless of their modeling perspective. This could facilitate flexible re-organization of Models/Elements while maintaining the semantic connection to the Subject hierarchy.
Sub-modeling was described in Model Hierarchy and more-directly establishes a hierarchy of PhysicalModels.
With sub-modeling, the “top-level” PhysicalModel contains some Elements that mixin ISubModeledElement. Those elements will have a sub-PhysicalModel that represents the same real-world Entity as the sub-modeled Element, but at a finer granularity. Certain iModel-based authoring apps take this approach to establishing a hierarchy of PhysicalModels Organizing the contents of PhysicalModels
There is no strict requirement limiting the top
PhysicalModel to contain only a single
PhysicalElement. iModels that are generated from other repositories will sometimes have top
PhysicalModels with multiple
PhysicalElements if that best matches the organization of the source data. Legacy data may also have a non-standard organization.
Models are weakly-typed in BIS. To understand the real-world Entity that a
Model is modeling, it is necessary to look at the
Element which the
Model is sub-modeling.
Note: PhysicalModel should not be subclassed. The few
PhysicalModel subclasses that exist are deprecated and should not be used. When a term such as "Site Model" is used, it indicates "a
Model that sub-models a
Site", but does not indicate a strongly-typed
Organizing the Elements
Additional hierarchical organization can be applied to Elements using the SpatialComposition schema and the PhysicalSystem class.
| Next: Physical Models and Elements |:---
Last Updated: 21 November, 2022