Ambiguity on whether nesting is part of the spatial decomposition

[Moult]

The element nesting concept describes this:

The hosted component should not be contained in the spatial hierarchy, i.e. the concept Spatial Containment shall not be used at the level of hosted components. The hosted component is contained in the spatial structure by the spatial containment of its host.

In other words:

IfcBuilding <-- IfcRelContainedInSpatialStructure --> Parent Host Element <-- IfcRelNests --> Child Element

The child element does not have an IfcRelAggregates relationship or an IfcRelContainedInSpatialStructure relationship, because its parent has one.

However the spatial containment concept does not mention nesting. It only talks about IfcRelContainedInSpatialStructure and IfcRelAggregates.

Any subtype of IfcElement may participate in two different containment relationships. The first (and in most implementation scenarios mandatory) relationship is the hierarchical spatial containment, the second (optional) relationship is the aggregation within an element assembly.

• The subtypes of IfcElement are placed within the project spatial hierarchy using the objectified relationship IfcRelContainedInSpatialStructure, referring to it by its inverse attribute SELF\IfcElement.ContainedInStructure. Subtypes of IfcSpatialElement are valid spatial containers.
• The subtypes of IfcElement may be aggregated into an element assembly using the objectified relationship IfcRelAggregates, referring to it by its inverse attribute SELF\IfcObjectDefinition.Decomposes. Any subtype of IfcElement can be an element assembly, with IfcElementAssembly as a special focus subtype. In this case it should not be additionally contained in the project spatial hierarchy, i.e. SELF\IfcElement.ContainedInStructure should be NIL.

I think this is a mistake, I think nesting should also be a possibility that causes something to be in the spatial tree (indirectly via its parent). Also nesting is mutually exclusive to aggregation.

I propose to add another bullet point to that paragraph above describing nesting.

[aothms]

• I think nesting should also be a possibility that causes something to be in the spatial tree

agreed, defacto it already is, especially with alignments et al.

• Also nesting is mutually exclusive to aggregation.

agreed, I don't understand why there are separate inverses for Nests and Decomposes (points to RelAggregates). Why not a single inverse capped at max cardinality 1? Otherwise this would be a good candidate for another gherkin rule. We need to check how this works out with the "Reusing of horizontal profile alignment use case" where I think we'll have an alignment aggregating other alignments as well as nesting profiles. But that's from parent to child, not child to parent (so it is still a tree). https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Object_Composition/Nesting/Alignment_Layouts/Alignment_Layout_-_Reusing_Horizontal_Layout/content.html

The template is a bit problematic though. As the the title is "Spatial Containment". The concept graph only mentions RelContains. Should we really hijack this template to build comprehensive documentation about the overall decomposition/nesting/containment tree?

Also then RelVoids should be mentioned because the OpeningElement is not contained.

Should we introduce a new monster template that illustrates how to get the "parent" node in the typical tree?

CC'ing @evandroAlfieri as he recently has been discussing this in the IF with the vendors.