bimkernel · 05

Classification
systems.

The modeller chooses the name. The classification code is the same for everyone.

Five names for the same wall.

Every company, program and person names things their own way. Without a common code, neither quantities nor searches add up.

Classifying says what it is.

A classification code groups objects by what they have in common. It does not say which one each is or what it is like.

One object, several tables.

The same door is part of a space, an element with a function, a product that is bought and work that is carried out. Each view has its own table.

A code reads from general to specific.

Each pair of digits goes down one level. Trimming the code from the right gives a broader class that is still valid.

One code, five uses.

The code is the stable link between the model and everything that comes after: cost estimate, specification, searches, requirements and maintenance.

Each use calls for its table.

Before classifying you need to know what for. Cost estimating looks at elements and work; maintenance, at products and spaces.

The class says what; the properties, how.

A data dictionary links each class to its properties, units and a unique identifier on the web. That is how a machine understands the code.

One system, one edition, in writing.

Decide before modelling which system, which tables and which version. A code without its edition is a number that can change meaning.

One framework, many systems.

The international standard contains no codes: it says which tables a system should have. Each country fills them with its own content.

Each country, its own system.

There is no worldwide classification. There are families born from the same standard and almost always tied to each country's specification or price database.

Fifteen tables, four revisions a year.

The British system is the most active, and it is free. An office partition gets one code for each point of view.

Three systems for three moments.

In North America, UniFormat organises the cost estimate by elements, MasterFormat the specification by work results, and OmniClass brings both together in 15 tables.

Classify and designate every part.

The Nordic school combines both: what type each object is, and a unique designation that says what function it serves, what it is made of and where it is.

No official table, GuBIMclass in practice.

There is no mandatory national table. The most widely used one was born in Catalonia: it classifies each element by its main function on four levels.

Three fields and a parameter.

It ships with UniFormat and OmniClass. Any other system is written into a parameter with a fixed name and syntax so that IFC understands it.

Classification is native.

Since 2017, each element can carry codes from several systems at once, and the systems are imported as files.

Each program, its own field.

The data sits in a different place in each program, but the common destination is the same: a classification in the IFC with system and code.

A dictionary on the internet.

buildingSMART publishes hundreds of classifications on a single platform, with a fixed web address for each class. Programs query it through its API.

Find the code and use it.

The official search tools give you the right code; viewers and the common data environment turn it into filters, colours and saved views.

Three entities carry the code.

The system, the code and the link to the objects are kept separate. That way the same object can carry several systems without mixing them.

Translating is not copying.

Systems look at things with different criteria and there is almost never a one-to-one equivalence. Better to keep each system in its own place than to convert one into another.

Six mistakes that empty your filters.

Nearly all happen on export: the code exists in the model but arrives with no system, under another name or in another field.

Five questions for every object.

Having a code is not enough. It must belong to the agreed system, come from the right table, exist in that edition and match what the object is.

The requirement, in a file.

An IDS says “every wall carries a code from this table and this system”. Every checker reads it the same way, and one different letter in the system name is enough to fail.

Check against the table.

An IDS does not know whether a code exists. A Python script compares every code in the IFC with the official list for the agreed edition.

Check before you export.

The cheapest error is the one spotted in the authoring program: a schedule or a colour filter by code before every delivery.

Four rules.