7.2 IDS Structure — Facets

Introduction

The core of every IDS specification is divided into two parts: applicability, which determines which IFC objects the specification applies to, and requirements, which define what those objects must satisfy. These are expressed using six facet types. Learning to recognise them isn't about memorising a list, it's about being able to open any specification, real or unfamiliar, and see which of six possible questions it's actually asking.

The Six Facets, Defined

Entity selects elements by their IFC class, IfcColumn, IfcReinforcingBar, optionally narrowed by a PredefinedType. It's almost always present in applicability, since a specification needs to know which elements it's talking about before it can check anything about them.

Attribute checks a value sitting directly on the element itself, not inside any container, things like Name or NominalDiameter. One tag is enough to name it.

Property checks a value inside a named property set attached to the element, BarLength inside Pset_ReinforcingBarCommon. Two tags are needed here, not one, the set's own name and the property's name inside it, since the same property name could theoretically exist in more than one set.

Material checks the element's material association rather than requiring you to navigate any particular property-set path, by name or category.

Classification checks an external classification code assigned to the element, a Uniclass or OmniClass reference, via a system and a value.

PartOf is the one facet that doesn't check data on the element at all. It checks whether an element participates in a specified IFC decomposition or containment relationship, such as belonging to a particular spatial structure, but that's one case among several. buildingSMART's own documentation describes PartOf as covering requirements that an object be part of an assembly or part of a group, and the relationship types it can check span spatial containment, aggregation, and nesting, genuinely different relationship kinds in the schema, not one relationship checked three ways. Everything else on this list asks what an element has. PartOf asks how it relates to something else.

Reading All Six Against a Real Run

Definitions are one thing. Seeing what a facet actually looks like when it's checked against a real file, and what result it actually produces, is another. A real IDS file was run against a real Revit 2021 IFC2X3 project, 1,484 elements, 1,252 reinforcing bars, using ten specifications. Four of them map cleanly onto four different facets, each with a real result.

Attribute, checking NominalDiameter on every IfcReinforcingBar:

<ids:attribute cardinality="required">
  <ids:name><ids:simpleValue>NominalDiameter</ids:simpleValue></ids:name>
</ids:attribute>

Result: 1,252 of 1,252 bars passed. Every single bar in the file carried a diameter.

Property, checking BarLength inside Pset_ReinforcingBarCommon:

<ids:property cardinality="required">
  <ids:propertySet><ids:simpleValue>Pset_ReinforcingBarCommon</ids:simpleValue></ids:propertySet>
  <ids:name><ids:simpleValue>BarLength</ids:simpleValue></ids:name>
</ids:property>

Result: 0 of 1,252 passed.

Material, checking that every IfcColumn carries a specific concrete grade:

<ids:material cardinality="required">
  <ids:value><ids:simpleValue>Concrete, Cast-in-Place - C25</ids:simpleValue></ids:value>
</ids:material>

Result: 0 of 91 columns passed.

PartOf, checking that every column belongs to an IfcBuildingStorey:

<ids:partOf cardinality="required">
  <ids:entity><ids:name><ids:simpleValue>IFCBUILDINGSTOREY</ids:simpleValue></ids:name></ids:entity>
</ids:partOf>

Result: 91 of 91 passed.

Worth being upfront about the sixth facet: Classification never appears in this dataset at all. None of the seven real files this series draws from carry classification codes. It's included here for completeness, not because there's a real result to show for it.

Why Two of These Failures Aren't Model Errors

Both zero-pass results above look, at first glance, like the model failed. Neither actually did, and the reason why is a lesson about facets specifically, not just about this file.

The BarLength Property check failed because it was looking in the wrong place, not because the data was missing. In IFC2X3, BarLength is a direct Attribute on IfcReinforcingBar, not a Property inside Pset_ReinforcingBarCommon. A specification built around the Property facet is structurally correct, valid syntax, sensible logic, and still produces a false failure if it's pointed at a location the schema version in question doesn't actually use for that value. That's the same shape of lesson this series already covered from the exporter side, the same conceptual value can sit in genuinely different IFC locations depending on schema version and export path, and here it shows up again from the checking side.

The Material check failed over a single character. The file's actual value was "Concrete, Cast-in-Place - C25", with a dash. The specification checked for "Concrete, Cast-in-Place C25", without one. IDS requires an exact match by design, so one dash is the entire difference between pass and fail. The material was correct. The string wasn't identical.

Neither of these is a flaw in IDS. Both are the Property and Material facets doing exactly what they're built to do, checking a specific location and a specific value with no tolerance for either being slightly off. The lesson is about writing specifications carefully, confirming where a value actually lives before checking for it there, and matching text exactly rather than approximately, not about the facets themselves being unreliable.

What Facets Can and Cannot Express

Facets express constraints on the presence and characteristics of specified IFC information, not just a flat presence check. Depending on the facet, that can include restrictions, patterns, and enumerated value sets, more expressive than a simple yes-or-no test.

What they cannot do matters just as much. No facet compares two properties on the same element against each other, there's no built-in way to ask whether one quantity is larger than another. buildingSMART's own documentation states directly that IDS has no capability to define details of geometry, so nothing about a shape, a curve, or a solid can ever be reached through any of the six. And within a single Material or Property check, there's no way to express an "and" condition inside one facet instance, checking that several distinct things are simultaneously true takes several separate specifications, not one combined one.

None of this is a shortcoming to fix. It's the actual shape of what these facets were built to check, and knowing the edge of that shape now avoids mistaking a real limitation for a bug later.