IfcRelNests decomposition and validation rule SPS007 - Spatial Containment

[fg55b]

Hello everyone,

When working with decompositions in IFC, there are some questions regarding the validity of using IfcRelNests to decompose physical elements.

When attempting to use IfcRelNests for ordered decompositions, the resulting file fails validation with the rule SPS007 - Spatial Containment. This rule references the Concept Template for Spatial Containment, which states:

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.

The definition of the IfcRelNests relationship is:

• In IFC4:

The nesting relationship IfcRelNests is a special type of the general composition/decomposition (or whole/part) relationship IfcRelDecomposes. The nesting relationship can be applied to all non physical subtypes of object and object types, namely processes, controls (like cost items), and resources. It can also be applied to physical subtypes of object and object types, namely elements having ports. The nesting implies an order among the nested parts.

• In IFC4X3:

The nesting relationship IfcRelNests is a special type of the general composition/decomposition (or whole/part) relationship IfcRelDecomposes. The nesting relationship can be applied to all subtypes of object and object types. For example, processes, controls (like cost items), and resources. It can also be applied to alignment, nesting its different layouts; and to physical subtypes of object and object types, such as elements having ports. The nesting implies an order among the nested parts.

The change from "namely" (an exhaustive, restrictive list) to "such as" (an illustrative, non-exhaustive list) suggests a broader scope for IfcRelNests in IFC4X3, potentially including physical elements beyond those with ports.

Furthermore, the documentation for IfcRelDecomposes states:

The differentiation between the aggregation and nesting is determined to be a non-ordered or an ordered collection of parts.

If the distinction is strictly regarding ordering, it implies that nesting should function similarly to aggregation regarding spatial containment, differing only in the ordering of parts. If not, this statement may be misleading, since it contradicts the Spatial Containment concept, which explicitly mentions only IfcRelAggregates for decomposition that implies spatial containment.

Considering the above, should IfcRelNests be considered a valid relationship for decomposing IfcElement subtypes in cases where an ordered decomposition is logically required?

[aothms]

I have asked this question before at different occasions. There are simply competing explanations of this distinction and I don't think we're able to clear this up in the context of 4.3. Do you have an example of what you're trying to accomplish? My preference would be to simply add a property that indicates the ordering within the connection (if feasible) and use unordered aggregation.

[fg55b]

Thank you Thomas for the context. We have encountered several cases where ordering is a key requirement, such as pipeline segments, element assemblies, and complex layered sections.

For IfcDistributionElement subtypes, ordering may be derived from port connectivity (IfcRelConnectsPorts). However, this logic does not apply to other IfcElement subtypes where order is still relevant. In these general cases, could IfcRelConnectsElements be considered a valid alternative to denote an ordered sequence?

Your suggestion of using properties for ordering is certainly viable and seems suitable for complex cases. However, we are trying to exhaust all native possibilities first to ensure interoperability without relying on custom agreements. In this context, IfcRelNests seemed the natural choice because ordering is intrinsic to its definition. Conversely, even if alternatives like IfcRelConnectsElements were valid, they would likely also rely on custom agreements, since they lack explicit native semantics for ordering.

[aothms]

could IfcRelConnectsElements be considered a valid alternative to denote an ordered sequence?

I think this makes sense.

If it's about phasing you could also sequence them in relating tasks; although that's a bit heavy; it's also more explicit about the semantic meaning of the ordering. I think that's maybe the biggest problem with using nesting in this way that while there is an ordering, the meaning behind that ordering is fully opaque.

[fg55b]

Regarding your point about tasks: definitely, they benefit both from the possibility of using IfcRelNests appropriately and from having the IfcRelSequence relationship, which explicitly denotes the ordering.

This highlights the gap for physical elements. Although IfcRelConnectsElements or IfcRelSequence (via tasks) can denote ordering, one of my concerns is that they introduce dependencies (connectivity or process) that might not exist in reality. In these cases, using a property seems more appropriate, since it does not force any additional semantic meaning.

I understand your point about the semantic opacity of IfcRelNests regarding ordering, implying an order but not explicit meaning. However, I would argue that implicit order is often better than no order at all.

A strong example is the use of IfcRelNests for IfcAlignment. In the infrastructure domain, sequencing is essential, yet IfcAlignment relies on nesting in the absence of a dedicated relationship like IfcRelSequence. This particular case suggests that IfcRelNests remains a necessary and valid mechanism within the schema for ordered composition, even when specific ordering semantics are implicit.