IFC Syntax : Property Sets
An IFC element carries its non-geometric data in property sets. A property set is a
named container of properties ; an objectified relationship binds that container to
one or more objects. This skill covers the container, the relationship, the property
value entities, and the rules that keep them valid.
Applies to IFC2x3, IFC4, and IFC4.3. Three items changed across versions : see the
Version Differences section.
Quick Reference
The container plus relationship pattern
A property set is NEVER a child of the element. It floats in the file as its own
instance and is linked by an IfcRel* relationship. ALWAYS hold this pattern in
mind : one container entity, one objectified relationship.
IfcPropertySet (the container : a named SET of IfcProperty)
^
| RelatingPropertyDefinition
IfcRelDefinesByProperties (the relationship)
|
| RelatedObjects
v
IfcWall, IfcSlab, ... (the element occurrences)
IfcPropertySet
Verified verbatim (IFC4.3) :
ENTITY IfcPropertySet
SUBTYPE OF (IfcPropertySetDefinition);
HasProperties : SET [1:?] OF IfcProperty;
WHERE
ExistsName : EXISTS(SELF\IfcRoot.Name);
UniquePropertyNames : IfcUniquePropertyName(HasProperties);
END_ENTITY;
Supertype chain : IfcRoot to IfcPropertyDefinition to IfcPropertySetDefinition
to IfcPropertySet. It inherits the four IfcRoot attributes (GlobalId,
OwnerHistory, Name, Description).
Name is mandatory here : the ExistsName rule rejects an unnamed property set.
The Name is semantically significant : a standardised set must carry its exact
Pset_ identifier.HasProperties holds at least one IfcProperty. The UniquePropertyNames rule
rejects two properties with the same Name in one set.
IfcPropertySetDefinition is the abstract supertype shared by IfcPropertySet and
IfcQuantitySet (the supertype of IfcElementQuantity). Quantities and properties
therefore share the same attachment machinery : see ifc-syntax-quantities.
IfcRelDefinesByProperties : attach to an occurrence
Verified verbatim (IFC4.3) :
ENTITY IfcRelDefinesByProperties
SUBTYPE OF (IfcRelDefines);
RelatedObjects : SET [1:?] OF IfcObjectDefinition;
RelatingPropertyDefinition : IfcPropertySetDefinitionSelect;
WHERE
NoRelatedTypeObject : SIZEOF(QUERY(Types <* SELF\IfcRelDefinesByProperties.RelatedObjects |
'IFC4X3_DEV.IFCTYPEOBJECT' IN TYPEOF(Types))) = 0;
END_ENTITY;
Supertype chain : IfcRoot to IfcRelationship to IfcRelDefines to
IfcRelDefinesByProperties.
RelatedObjects is a SET [1:?] : a single property set can be shared by many
objects through one relationship.RelatingPropertyDefinition accepts an IfcPropertySetDefinitionSelect (an
IfcPropertySet or an IfcElementQuantity).- The
NoRelatedTypeObject rule FORBIDS any IfcTypeObject in RelatedObjects.
ALWAYS use IfcRelDefinesByProperties for element occurrences. NEVER place a type
object in its RelatedObjects : that breaks NoRelatedTypeObject and the file is
schema-invalid.
Attaching a property set to a type object
A type object (IfcWallType, IfcSlabType, ...) carries its property sets through a
DIFFERENT mechanism : the direct aggregation attribute HasPropertySets on
IfcTypeObject. ALWAYS populate IfcTypeObject.HasPropertySets with the
IfcPropertySet instances ; the type itself is linked to its occurrences through
IfcRelDefinesByType. NEVER try to reach a type with IfcRelDefinesByProperties.
See ifc-core-entity-hierarchy for the type / occurrence model.
The property value tree
IfcProperty (abstract)
├── IfcSimpleProperty (abstract) : six concrete subtypes
│ ├── IfcPropertySingleValue one nominal value
│ ├── IfcPropertyEnumeratedValue value(s) from a controlled vocabulary
│ ├── IfcPropertyBoundedValue an interval (upper / lower / set point)
│ ├── IfcPropertyListValue an ordered list of values
│ ├── IfcPropertyTableValue a two-column lookup table
│ └── IfcPropertyReferenceValue value is a resource-level entity
└── IfcComplexProperty nested group of sub-properties
IfcProperty carries Name (IfcIdentifier, the property's identifier) and a second
optional text attribute (Description in IFC2x3 / IFC4, renamed Specification in
IFC4.3 : see Version Differences).
IfcPropertySingleValue : the common case
Verified verbatim (IFC4.3) :
ENTITY IfcPropertySingleValue
SUBTYPE OF (IfcSimpleProperty);
NominalValue : OPTIONAL IfcValue;
Unit : OPTIONAL IfcUnit;
END_ENTITY;
This is by far the most common property entity : one named value. NominalValue
holds an IfcValue (a typed measure such as IfcLengthMeasure, IfcBoolean,
IfcLabel). Unit is an OPTIONAL override : see "How a property gets a unit".
The other five IfcSimpleProperty subtypes and the full attribute lists are in
references/methods.md.
IfcComplexProperty : nesting
Verified verbatim (IFC4.3) :
ENTITY IfcComplexProperty
SUBTYPE OF (IfcProperty);
UsageName : IfcIdentifier;
HasProperties : SET [1:?] OF IfcProperty;
WHERE
WR21 : SIZEOF(QUERY(temp <* HasProperties | SELF :=: temp)) = 0;
WR22 : IfcUniquePropertyName(HasProperties);
END_ENTITY;
IfcComplexProperty groups sub-properties hierarchically. UsageName describes how
the group is used. HasProperties may itself contain further IfcComplexProperty
instances, enabling nesting. WR21 forbids a complex property from containing
itself ; WR22 enforces unique sub-property names.
How a property gets a unit
A property with a Unit attribute (IfcPropertySingleValue, IfcPropertyBoundedValue,
IfcPropertyListValue) resolves its unit one of two ways :
Unit NOT given : the unit is implied by the measure type of the value (an
IfcLengthMeasure rides the project's global length unit), resolved through the
project IfcUnitAssignment.Unit given : that explicit IfcUnit OVERRIDES the project-global unit for that
one property only.
A property NEVER invents a unit out of nothing. See ifc-syntax-units for the
propagation chain.
The Pset_ naming convention
The IFC specification publishes a library of standardised property sets. Their
Name ALWAYS begins with Pset_. The common pattern is Pset_<ElementClass>Common,
for example Pset_WallCommon for IfcWall, Pset_SlabCommon for IfcSlab,
Pset_BeamCommon for IfcBeam, Pset_DoorCommon for IfcDoor.
ALWAYS name a standardised property set with its exact published Pset_ identifier.
NEVER give a custom (project-specific) property set a Name that starts with
Pset_ : the prefix is reserved and a custom set using it collides with the standard
library.
IfcPropertySetTemplate (brief)
IfcPropertySetTemplate plus IfcRelDefinesByTemplate declare the shape of a
property set in advance. This is the IFC-native mechanism behind the published
Pset_ library : the standard property sets are themselves templated. Templates are
a secondary topic ; full signature in references/methods.md. IfcPropertySetTemplate
and IfcRelDefinesByTemplate are NEW IN IFC4 : they do not exist in IFC2x3.
Version Differences
| Item | IFC2x3 | IFC4 | IFC4.3 |
|---|
IfcProperty second text attribute | Description (OPTIONAL IfcText) | Description (OPTIONAL IfcText) | Specification (OPTIONAL IfcText) |
IfcPropertyBoundedValue.SetPointValue | absent | present | present |
IfcPropertySetTemplate / IfcRelDefinesByTemplate | absent | present | present |
ALWAYS write IfcProperty's second text attribute as Description for IFC2x3 and
IFC4, and as Specification for IFC4.3. NEVER use SetPointValue on an
IfcPropertyBoundedValue in an IFC2x3 file : the attribute did not exist.
Decision Trees
Occurrence or type : which attachment?
What receives the property set?
|
+-- An element OCCURRENCE (a specific IfcWall instance, ...)
| --> IfcRelDefinesByProperties.
| RelatedObjects = the occurrence(s), RelatingPropertyDefinition = the Pset.
|
+-- An element TYPE (IfcWallType, IfcSlabType, ...)
| --> IfcTypeObject.HasPropertySets aggregation (direct attribute).
| The type reaches its occurrences via IfcRelDefinesByType.
|
+-- BOTH a type and its occurrences
--> Type Psets are defaults ; occurrence Psets override on Name collision.
See ifc-impl-property-extraction for the resolution algorithm.
Which IfcSimpleProperty subtype?
What shape is the value?
|
+-- One single value (a fire rating, a boolean flag, a thickness)
| --> IfcPropertySingleValue.
|
+-- One value chosen from a fixed controlled vocabulary
| --> IfcPropertyEnumeratedValue (+ IfcPropertyEnumeration for the allowed set).
|
+-- An interval : an upper bound, a lower bound, optionally a set point
| --> IfcPropertyBoundedValue.
|
+-- An ordered list of values of one data type
| --> IfcPropertyListValue.
|
+-- A lookup table : defining values mapped to defined values
| --> IfcPropertyTableValue.
|
+-- The value IS a resource entity (a material, a person, a time series)
--> IfcPropertyReferenceValue.
Standard or custom property set name?
Is this a property set published in the IFC standard?
|
+-- YES --> use the EXACT published Pset_ identifier (Pset_WallCommon, ...).
|
+-- NO (project-specific) --> choose any Name that does NOT start with Pset_.
A custom set named Pset_* collides with the library.
Does the property need an explicit Unit?
Should the value use the project's global unit?
|
+-- YES --> omit the Unit attribute. The measure type plus the project
| IfcUnitAssignment resolve the unit.
|
+-- NO, this one property uses a different unit
--> set the Unit attribute to an explicit IfcUnit (a local override).
Patterns
Pattern : Attach a property set to element occurrences
ALWAYS create the IfcPropertySet as a standalone instance with a non-empty Name,
populate HasProperties with at least one IfcProperty, then create one
IfcRelDefinesByProperties whose RelatingPropertyDefinition points at the set and
whose RelatedObjects lists the element occurrences.
ALWAYS reuse a single IfcRelDefinesByProperties to attach one shared set to many
occurrences : RelatedObjects is a SET [1:?].
NEVER place an IfcTypeObject in RelatedObjects : the NoRelatedTypeObject rule
rejects it.
Pattern : Attach a property set to a type object
ALWAYS attach a property set to an element type by adding the IfcPropertySet to the
type's HasPropertySets aggregation. The type is bound to its occurrences by
IfcRelDefinesByType ; the occurrences inherit the type's property sets as defaults.
NEVER use IfcRelDefinesByProperties to reach a type : type attachment and
occurrence attachment are two distinct mechanisms.
See ifc-core-entity-hierarchy for IfcTypeObject and IfcRelDefinesByType.
Pattern : Keep property names unique within a set
ALWAYS give every IfcProperty in one IfcPropertySet a distinct Name : the
UniquePropertyNames rule (IfcUniquePropertyName) rejects a duplicate.
ALWAYS give the IfcPropertySet itself a non-empty Name : the ExistsName rule
rejects an unnamed set.
The same uniqueness rule (WR22) applies inside an IfcComplexProperty.
Pattern : Choose the right IfcSimpleProperty subtype
ALWAYS model a single named value as IfcPropertySingleValue with one
NominalValue : it is the correct entity for the overwhelming majority of properties.
ALWAYS model a value drawn from a fixed vocabulary as IfcPropertyEnumeratedValue,
and reference an IfcPropertyEnumeration that holds the permitted values : the
WR21 rule rejects an enumeration value that is not in the referenced list.
ALWAYS model an interval as IfcPropertyBoundedValue ; an omitted bound denotes an
open interval. NEVER use SetPointValue in an IFC2x3 file.
NEVER store a list of values by repeating a property : use IfcPropertyListValue
(all members the same data type, enforced by WR31).
Pattern : Nest properties with IfcComplexProperty
ALWAYS group related sub-properties under an IfcComplexProperty when they form one
logical compound (for example the panes of a glazing unit) : set UsageName to
describe the group and HasProperties to the sub-properties.
An IfcComplexProperty MAY contain further IfcComplexProperty instances for deeper
nesting.
NEVER let an IfcComplexProperty contain itself : the WR21 rule forbids it.
Pattern : Name standardised versus custom property sets
ALWAYS use the exact published identifier for a standardised property set
(Pset_WallCommon, Pset_SlabCommon, ...) : the Name is how a reader recognises
the set as the standard one.
NEVER prefix a custom property set with Pset_ : the prefix is reserved for the
standard library. Choose a distinct project or vendor prefix instead.
See ifc-errors-property-set-mistakes for the failure modes of a misnamed set.
Pattern : Resolve a property's unit
ALWAYS omit the Unit attribute when the property uses the project's global unit :
the measure type of the value plus the project IfcUnitAssignment resolve it.
ALWAYS set the Unit attribute to an explicit IfcUnit when one property must use a
different unit from the project default : that is a deliberate local override.
NEVER assume a bare NominalValue number carries no unit : its measure type implies
one through the project unit assignment.
See ifc-syntax-units for the full unit-propagation chain.
Reference Links
references/methods.md : the complete verified entity definitions : all six
IfcSimpleProperty subtypes, IfcComplexProperty, IfcPropertyEnumeration,
IfcPropertySetTemplate, the supertype chains, the IfcObjectReferenceSelect
members, and the per-version difference detail.references/examples.md : worked STEP scenarios : a property set on a wall, a
shared set on many occurrences, each of the six simple property types, a nested
complex property, a type-level property set, and a custom property set.references/anti-patterns.md : the failure modes this skill prevents, each with
the rule it breaks and the reason it fails.
Official sources
Related skills
ifc-syntax-quantities : IfcElementQuantity, which shares the
IfcRelDefinesByProperties attachment machinery.ifc-syntax-units : how a property value resolves to a concrete unit.ifc-syntax-data-types : the IfcValue measure types a NominalValue carries.ifc-core-entity-hierarchy : the type / occurrence model and IfcRelDefinesByType.ifc-impl-property-extraction : the type-versus-occurrence override resolution.ifc-errors-property-set-mistakes : property-set failure modes in real models.
