A BIM element is more than a shape. A wall carries its fire rating, whether it’s external or internal, whether it’s load-bearing; a door carries its fire performance, dimensions, product code — this information (properties). In IFC, the mechanism that groups these properties is the property set (Pset), and the way an element expresses what it is is classification. Together they take a model from something you view to something you use — search, aggregate, check.

Bottom line first

A Pset (property set) is a named group of properties on an element (e.g. fire rating and external/internal in Pset_WallCommon).
There are standard Psets (IFC-defined) and custom/vendor Psets; for aggregation and checking, prefer the standard.
Classification tags an element with a code for “what it is” (Uniclass, OmniClass, etc.), enabling aggregation and matching across element types.

What a property set (Pset) is

A Pset is a named group of related properties. In IFC an element can be linked to several Psets, each holding individual properties (a name-value pair). A wall, for instance, gets Pset_WallCommon, inside which sit values like “fire rating,” “external or internal,” and “load-bearing.”

An element can carry both standard and vendor Psets. For aggregation and checking, use the standard ones

Standard vs custom Psets

There are broadly two kinds of Pset.

Preferred

Standard Psets (IFC-defined)

Pset_WallCommon / Pset_DoorCommon, etc.
names and meanings fixed by the spec
read the same way in any tool
a shared language for aggregation, checking, exchange

Handle with care

Custom / vendor Psets

defined by a tool or organisation
often carry lots of internal housekeeping
the receiver may not know their meaning
tend to bury the standard ones

In real models, vendor-internal properties often mix in by the thousands. By count they can be the majority, so the standard Psets that matter (fire rating, quantities, etc.) get buried and hard to find. If you’re aggregating or checking, the rule of thumb is to read the standard Psets first.

Classification — tagging an element with “what it is”

Where a Pset expresses “the values of this element,” classification expresses “what this element is,” using a common coding system. In IFC, IfcClassification (the system) and IfcClassificationReference (an individual code) associate a classification code with an element.

Classification enables aggregation and matching across element types. For example, you can pull “everything that is an external wall” by classification code regardless of the modelled element type (wall, curtain wall, etc.). The accuracy of QTO and model checking rises the better the classification is set up.

Through a classification code you can handle “everything that is an external wall” independent of the modelled element type

The main classification systems

There are several classification systems, chosen by region and purpose. A few of the best-known (defer to each system’s official definition for the facts):

Uniclass

A unified UK classification split into tables (elements, systems, products, etc.) covering a wide range of work.

OmniClass

A comprehensive North American system made of multiple tables (elements, deliverables, products, etc.).

Uniformat

Classifies a building by “element (part).” Suits early-stage and order-of-magnitude aggregation.

MasterFormat

Widely used in North America for classifying specifications (work results).

Which to use depends on the project and client requirements. What matters is standardising on one per project (or a clear mapping between them). Mixing systems makes the classification useless for matching.

Why Psets and classification get lost or messy

Not included on export. Properties and classification must be enabled in the export settings; with them off you get a geometry-only IFC.
A flood of vendor properties. Standard Psets get buried under custom ones. Read the standard first on the receiving side.
Classification unset or inconsistent. Either there’s no classification at all, or systems are mixed. Standardise per project.
Naming drift. Hand-typed properties split under spelling variation. Leaning on standard Psets and classification keeps it stable.

Export pitfalls in general are in IFC export tips, and the empty-properties symptom in common IFC problems.

Using them in practice

Start in a viewer by clicking an element and checking which Psets and classification it carries. If the standard Psets are visible and a classification code is attached, it’s ready for search, aggregation and model checking. Quantity takeoff (QTO) is also easier to keep at a consistent granularity when you group by part and type via classification.

Conversely, adding properties or classification “in bulk after the fact” is costly and risky, so being deliberate about standard Psets and classification while modelling is ultimately what pays off most.

Summary

A Pset is a named group of properties on an element. Prefer the standard Psets and don’t let them get buried under vendor ones.
Classification tags an element with a “what it is” code (Uniclass, OmniClass, etc.), enabling aggregation and matching across types.
Standardise on one classification system per project (mixing breaks matching).
The better the properties and classification, the more accurate your search, quantities and checking.

Geometry-only BIM stops at “view”; BIM with sound properties and classification becomes usable data. The big picture is in what is IFC, and the terms in the BIM & IFC glossary.