4.4 Property Sets

Introduction

Property Sets are how IFC attaches open-ended, extensible data to an element from outside its own line, distinct from the small, fixed set of attributes built into the entity itself. This lesson shows the mechanism with a real property set from AC20-FZK-Haus.ifc, then a real, documented failure mode from validated construction projects.

What a Property Set Actually Is

A real beam in FZK-Haus carries Pset_BeamCommon, reached through the relationship entity IfcRelDefinesByProperties:

#20409= IFCRELDEFINESBYPROPERTIES('0kgaqWTukScGEjKDAQ25_g',#12,$,$,(#20374),#20405);
#20405= IFCPROPERTYSET('04m_eFuJACryOL903aNSOy',#12,'Pset_BeamCommon',$,(#20403,#20404));
#20403= IFCPROPERTYSINGLEVALUE('Slope',$,IFCPLANEANGLEMEASURE(0.),$);
#20404= IFCPROPERTYSINGLEVALUE('Reference',$,IFCIDENTIFIER('Radial Gradient Fill 1515460218 200 x 240'),$);

The property set itself, #20405, descends from IfcPropertySetDefinition, a subtype of IfcRoot, so it opens with a real GlobalId, OwnerHistory, Name, Description, plus one attribute of its own: HasProperties.

The individual properties inside are a different branch of the schema entirely. IfcProperty, buildingSMART's schema confirms, is a subtype of IfcPropertyAbstraction, not IfcRoot. No property, of any kind, carries a GlobalId. #20403's four values, Name, Description, NominalValue, Unit, match buildingSMART's own definition of IfcPropertySingleValue exactly.

One Entity, Multiple Homes for Data

#20404's value, 'Radial Gradient Fill 1515460218 200 x 240', is the same messy ArchiCAD label that also sits directly on this beam's own entity line, in a completely different position (its ObjectType attribute). Same underlying data, two structurally different homes: one fixed and built into the entity at creation, one external, attached through a relationship, and extensible, an element can carry as many property sets as needed. This is the actual distinction to take from this lesson: an entity's own attributes are few and fixed; its property sets are where IFC's real flexibility lives.

Standard Names, Custom Names, Same Mechanism

Pset_BeamCommon is buildingSMART-defined, meant to mean the same thing in any compliant file. That's what "standard" means: portable naming, not portable content, since the Slope and Reference values on this specific beam are still ArchiCAD-specific regardless.

The same beam also carries ArchiCADProperties, a name appearing nowhere in buildingSMART's documentation, twenty-nine properties, entirely German, entirely ArchiCAD workflow metadata: Ursprungsgeschoss (origin storey), Raumname (room name), Typ (type). Same mechanism, IfcPropertySet plus IfcRelDefinesByProperties, used for two different purposes: one for cross-software portability, one purely internal to one vendor's workflow.

Presence Isn't Reliability

Pset_WallCommon.LoadBearing is a real, standard, buildingSMART-defined property. Across two separately validated real construction projects, it was populated, and wrong, on both.

In one project, two concrete shear walls, material confirmed independently as reinforced concrete panels, were exported with LoadBearing = False. Taking that at face value would have silently dropped 22.7 m³ of real structural concrete from a validation report. In another, every wall in the building showed LoadBearing = False with no material tag at all to fall back on, forcing a validation process to flag the entire wall category rather than trust the flag outright.

Neither case is missing data. The property exists, populated, exactly where the schema says it should be. It's simply wrong: a modeler error, not a schema failure. A property's presence confirms the mechanism worked. It confirms nothing about whether a human entered the correct value.

A Different Shape: IfcComplexProperty

buildingSMART's schema defines a second property kind entirely: IfcComplexProperty, confirmed to have no NominalValue attribute at all, only a nested HasProperties list, a property containing other properties.

A real wall from a validated Allplan-authored project (Allplan being a widely used structural detailing tool in the German, Austrian, and Swiss market) carries exactly this structure:

[Object Layer Attributes #1]
  → Gewerk: Betonarbeiten
  → Objektname: Wand

Gewerk, German for trade, was the single most reliable classification signal in that file: Betonarbeiten means concrete works. It was invisible to a validation process for exactly the reason the schema predicts: code safely skipping properties with no NominalValue also skipped the one property carrying the real answer. The fix wasn't a workaround, it was checking HasProperties specifically when NominalValue is absent. Absence of NominalValue is not absence of useful information.