Properties and materials

A wall in a finished model carries more than just 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. All this is in the file.

Attributes aren’t properties

Some of the structure of this metadata is fixed in advance, by the open IFC standard, and its schema lists the attribute fields each kind of object has. An IFC4 IfcWall has nine such fields and no more: a Name, a Description, an ObjectType, a Tag, a PredefinedType, its placement, its geometry, a globally unique id, and a note of who last changed it. Those are its attributes, and the list is in the standard - which is why it isn’t the same list in every version of the schema: an IFC2X3 wall has eight, and no PredefinedType.

Much of the rest of the metadata attached to elements - whether it is an external wall, what it is rated to - is held as properties, kept in named sets attached to the object. Attributes and properties sit side by side on screen but behave nothing alike. You can’t invent an attribute; a program that added one would be writing a file nobody else could read. You can invent a property set. And you need to know which is which before you can fetch one: a door’s Tag - the number beside it on the drawing - is an attribute, its fire rating a property inside Pset_DoorCommon, and a query asks for them differently, Tag=D01 against Pset_DoorCommon.FireRating=FD30.

A third thing appears to be an attribute. A wall will also have ContainedInStructure, HasOpenings, ConnectedTo and many more virtual attributes (the schema calls them inverse attributes): which storey it stands on, what is cut into it, which walls it runs up against. None of that is written in the wall entity; these are the schema’s way of referencing a relationship - the relationship is an entity in its own right, holding both ends, and an inverse attribute is how it looks from the object it references.

Properties travel in sets

Those named groups are property sets, and an object may carry several.

Many are published rather than invented. The standard sets are part of the IFC schema itself, named with a Pset_ prefix, and each applies to particular classes of object: Pset_WallCommon carries IsExternal, FireRating, AcousticRating, LoadBearing and the rest, and applies to walls. When looking at a wall, Bonsai offers you the wall’s sets rather than a list of everything in the standard.

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. You can invent property sets too, and it isn’t a hack, nor a hole in the published vocabulary: a property set is itself a standard kind of object; practices have their own, and so do jobs and clients. Check first whether a standard set already has somewhere to put it, because the standard one saves an explanation.

So if you create your own property sets, don’t give them a Pset_ prefix. If they are universal but not in the standard for some reason, prefix them EPset_; otherwise prefix them with the name of your company or the software that needs them.

Quantities work in the same way as properties

Quantity sets look like property sets; 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 naming works the same way too: the standard sets carry a Qto_ prefix, as the standard property sets carry Pset_. The prefix isn’t a reliable way to spot one, though. A great many exported files put their quantities in a set called BaseQuantities instead - the older convention, and still what commonly arrives from other software.

Quantities are written into the file: Bonsai calculates them when you ask, and they then sit there as data rather than being worked out afresh by whatever program opens the model next.

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 what makes a schedule out of an IFC file mean anything. The other side of this is that they are a snapshot: change the geometry and the stored quantities are stale until you select what you changed and recalculate, the same habit as for a stale wall join.

This is important: edit a wall and stored quantities don’t change until you refresh them.

Materials are their own kind of metadata

A material is neither a property nor geometry, and IFC gives it its own machinery, in several arrangements. Which 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 also generate an object’s shape, as types and occurrences explains. Here the point is that the build-up is a description in its own right, readable by anybody whether or not they care what shape it made.

Don’t be confused by types that have a layer set and the layer set itself. A wall type can have a layer set that applies to all occurrences of the wall, but this is just a normal layer set, not the type itself.

Classification is a reference, not a label

Classification is yet another kind of metadata that can be assigned to objects and types.

Classification looks like a property but isn’t. 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 many such tables, as ordinary IFC files: international ones such as Uniclass, Omniclass and MasterFormat, and - tellingly - national tables from a range of countries. Somebody in each of those places needed their own and added it.

An object can be classified against more than one table: a cost consultant may want NRM while the client’s asset system wants Uniclass.

This metadata is model quality

Almost everything in the model is found by this metadata rather than the geometry. A schedule of doors is a query over their attributes and properties, a fire strategy check is a query over ratings, and a cost plan is quantities against classification codes.

That is why the model is worth reaching into directly rather than only clicking about, and it is what a requirements check actually inspects. A model that looks right and carries none of this metadata is just a glorified drawing rather than BIM.

Last updated 6 October 2026.