How should I interpret this "deviating" pattern in the IFD4_ADD2 spec ?

Developers IFC4
1

I am parsing the IFC4.exp to store the specification as a graph. All seems good, but I sometimes find “deviating” patterns. For instance in the EXPRESS definition of IfcElement

ENTITY IfcElement
 ABSTRACT SUPERTYPE OF (ONEOF
    (IfcBuildingElement ,IfcCivilElement, IfcDistributionElement, IfcElementAssembly, IfcElementComponent, IfcFeatureElement, IfcFurnishingElement, IfcGeographicElement, IfcTransportElement, IfcVirtualElement))
 SUBTYPE OF (IfcProduct);
	Tag : OPTIONAL IfcIdentifier;
 INVERSE
	FillsVoids : SET [0:1] OF IfcRelFillsElement FOR RelatedBuildingElement;
	ConnectedTo : SET [0:?] OF IfcRelConnectsElements FOR RelatingElement;
	IsInterferedByElements : SET [0:?] OF IfcRelInterferesElements FOR RelatedElement;
	InterferesElements : SET [0:?] OF IfcRelInterferesElements FOR RelatingElement;
	HasProjections : SET [0:?] OF IfcRelProjectsElement FOR RelatingElement;
	ReferencedInStructures : SET [0:?] OF IfcRelReferencedInSpatialStructure FOR RelatedElements;
	HasOpenings : SET [0:?] OF IfcRelVoidsElement FOR RelatingBuildingElement;
	IsConnectionRealization : SET [0:?] OF IfcRelConnectsWithRealizingElements FOR RealizingElements;
	ProvidesBoundaries : SET [0:?] OF IfcRelSpaceBoundary FOR RelatedBuildingElement;
	ConnectedFrom : SET [0:?] OF IfcRelConnectsElements FOR RelatedElement;
	ContainedInStructure : SET [0:1] OF IfcRelContainedInSpatialStructure FOR RelatedElements;
	HasCoverings : SET [0:?] OF IfcRelCoversBldgElements FOR RelatingBuildingElement;
END_ENTITY;

9 out of 11 INVERSE attributes refer to an IfcRel entity that links back to IfcElement. The two others

ReferencedInStructures : SET [0:?] OF IfcRelReferencedInSpatialStructure FOR RelatedElements;
ContainedInStructure : SET [0:1] OF IfcRelContainedInSpatialStructure FOR RelatedElements;

refer to an IfcRel entity that refers back to IfcProduct.

ENTITY IfcRelReferencedInSpatialStructure
 SUBTYPE OF (IfcRelConnects);
	RelatedElements : SET [1:?] OF IfcProduct;
	RelatingStructure : IfcSpatialElement;
 WHERE
	AllowedRelatedElements : SIZEOF(QUERY(temp <* RelatedElements | ('IFC4.IFCSPATIALSTRUCTUREELEMENT' IN TYPEOF(temp)) AND (NOT ('IFC4.IFCSPACE' IN TYPEOF(temp)))
)) = 0;
END_ENTITY;

ENTITY IfcRelContainedInSpatialStructure
 SUBTYPE OF (IfcRelConnects);
	RelatedElements : SET [1:?] OF IfcProduct;
	RelatingStructure : IfcSpatialElement;
 WHERE
	WR31 : SIZEOF(QUERY(temp <* RelatedElements | 'IFC4.IFCSPATIALSTRUCTUREELEMENT' IN TYPEOF(temp))) = 0;
END_ENTITY;

My question: wouldn’t it be more consistent if these two INVERSE attributes were part of the IfcProduct Express definition?

2

What say you @Moult @Evandro @berlotti or @TLiebich ?

3

This is a known deviation from the normal bidirectional direct and inverse relationships. The reason was, that several subtypes of IfcProduct are not expected to take part in this relationship, e.g. IfcStructuralItem and IfcStructuralActivity. And the underlying modeling language so far allows to have such patterns.

It is one of those topics that should be revisited within the IFC5 development timeframe.

2 Likes
4

I call these constructions “partial inverse” and carried out an extensive analysis about this special issue in IFC. Apart from the reason mentioned by Thomas Liebich, there is another one: The domain of the direct attribute being a select type. Since no attributes, including inverse, can’t be specified for select types, if name or restriction is required for the inverse, you would have to specify it for the concrete sub-types (more precisely sub-selections) of the select.

@TLiebich, good to learn about the background and reasoning that led to these constructions. But according to my reading of Express, it would not work the way as expected. Even with this construction, all subtypes of IfcProduct will be able to take part in the relationship - just that only some of them would have a name and cardinality restriction defined for the inverse.

5

@tauscher - yes, and I am aware of it - an inverse relationship is only adding name and cardinality and makes it navigable. It would be probably a better way to have it as a bidirectional relationship to the supertype IfcProduct and restrict the use at those other subtypes, where it is not applicable, via a where rule. (the case with SELECT is a different one).