Description - properties, materials and classifications

A wall in a finished model carries a good deal more than its shape. It knows whether it is external, what it is rated to for fire and for sound, what it is made of and in what order, what its area and volume are, and what it is called in whichever classification table the job is using.

None of that is metadata hung off the side of the model. It is the model. The shape is one attribute among many, and on most days it is not the one anybody is asking about.

Properties travel in sets

Properties are not loose attributes scattered over an object. They come in named groups called property sets, and an object may carry several.

Many of them are published rather than invented. The standard sets are part of the IFC schema itself - the published specification your model file is written to. They are named with a Pset_ prefix, and each applies to particular classes of object - Pset_WallCommon carries IsExternal, FireRating, AcousticRating, LoadBearing and the rest, and it applies to walls. Bonsai knows which sets apply to what, so when you go to add one to a wall you are offered the wall’s sets rather than a list of everything in the standard.

That publication is the whole point. When you write a fire rating into Pset_WallCommon.FireRating, anybody’s software knows where to look for it, because the name and the meaning were agreed before either of you opened a file. A rating you invent a place for is a rating somebody else has to be told about.

You can invent places, though, and it is not a hack - nor is it a hole in the published vocabulary described in The model is a graph of standard objects. A property set is itself a standard kind of object, and naming one is not the same as inventing a word the schema does not have. Custom property sets are ordinary and expected - practices have their own, jobs have their own, clients ask for their own. The rule of thumb is only to check whether a standard set already has somewhere to put it, because using the standard one costs nothing and saves an explanation.

Quantities are a separate kind, and they are stored

Quantity sets look like property sets and are named Qto_ instead. The difference is where the numbers come from: quantities are measured off the geometry - lengths, areas, volumes, and less obvious things like formwork area.

The part worth understanding is that they are written into the file. Bonsai calculates them when you ask it to, and then they sit there as data. They are not worked out afresh by whatever program opens the model next.

That has two consequences and they pull in opposite directions. Anybody who receives your file gets your quantities, computed the way you computed them, without needing your software or agreeing with your method - which is exactly what makes a schedule out of an IFC file mean anything. And they are a snapshot: change the geometry and the stored quantities are stale until something recalculates them. A stale quantity is the same problem as a stale wall join, and What is parametric and what is not gives the habit that answers both.

Materials are their own kind of description

A material is neither a property nor geometry, and IFC gives it its own machinery. There are five arrangements, and the one to use depends on how the thing is actually built.

• A plain material - the object is made of concrete, and that is all that needs saying.
• A layer set - a build-up in order, each layer with its material and thickness. Walls, floors, roofs.
• A profile set - a cross-section, possibly composite, swept along the object. Beams, columns, members.
• A constituent set - named parts made of different things, where there is no layering or sweeping to describe. A window’s frame, its glazing and its ironmongery.
• A material list - a bare list, when nothing more structured is true.

Layer sets and profile sets are also the mechanism behind an object’s shape, which is why they turn up in Types and occurrences as well: the type carries the build-up, and each occurrence is its own length and height. Here the point is the other half of it - that the build-up is a description in its own right, readable by anybody, whether or not they care what shape it made.

Classification is a reference, not a label

Classification is the one that looks like a property and is not. Writing EF_25_10 into a text field would be a property. A classification reference points at an entry in a published table that exists outside your model, so the code carries its meaning with it.

Bonsai ships thirty-eight such tables, as ordinary IFC files. Uniclass is there in three editions, along with Omniclass, MasterFormat, Uniformat, NBS Create, CAWS, NATSPEC and RICS NRM1 and NRM3 - and, tellingly, national tables from Norway, Denmark, the Netherlands, Finland, Belgium, Spain, Brazil and Sweden. Somebody in each of those places needed their own and added it.

You can classify against more than one table at once, which is ordinary: a cost consultant may want NRM while the client’s asset system wants Uniclass, and an object can carry both.

Why this layer is the useful one

Almost everything the model is eventually asked to do runs on this layer rather than on the geometry. A schedule of doors is a query over properties. A fire strategy check is a query over ratings. A cost plan is quantities against classification codes.

That is why the model is worth reaching into directly rather than only clicking about in - see Finding things - and it is what a requirements check actually inspects, in Checking the model. A model that looks right and carries none of this is a drawing with extra steps.

Last updated 4 September 2026.