Classification - not so Easy

I have written about adding classification numbers to Revit before. Back then I thought it good practice to include them, even if you didn't have a specific need for them.

That was before I did some digging and found it is not as simple as it sounds.

Before you get bored and go back to looking at kittens on YouTube or BIMporn, I appreciate you are probably not interested in classification systems. I certainly am not. So I'll put the practical  information first, then at least you might know something useful before your eyes start glazing over.

How to Deal with Classification

QUESTION THE NECESSITY FOR CLASSIFICATION

Classification codes (see here for a description) are promoted by some as a panacea for all BIM uses. The truth is they are mostly used for costing and specifications. They are not that useful for Facilities Management as a classification code might tell you a thing is a door, but it doesn't tell you where the door is.

If you do estimating and will use classification codes (they are not the only method to identify components) then yes, they are necessary. If you use them for specification purposes then they are also necessary, although again, they are not the only, or even most common, way of managing specifications.

If you don't do estimating and are requested to include classification codes in your models ask why.
Are you doing it so the cost consultant or contractor doesn't have to? If so why are you doing it and not them? Who will pay you to do their work?

If there is no specific reason, if it is explained as "necessary for BIM", or simply "good practice", put a price on it and see if it is still a requirement.
Or pose a series of questions about the specifics of what it is they require (read to the bottom of this post for ammunition).
As a last resort, if they still insist, be comforted in the fact that they have no idea what they will be receiving, will never use it, and will never know if you have done it properly or not (whatever "properly" means).

DEFINE YOUR SCOPE

If you can't get out of providing classification codes, and you have no clear direction on what is expected, you need to define what you will deliver.

1.  Which classification system will be used.
If you are in the USA or UK the answer will be obvious, possibly even mandated. In other countries (like Australia and many Asia-pacific countries) it may not be so obvious.

If it is not clear use whichever one is easiest for you to access and use.

2.  Which version will be used.
Classification systems are pretty much constantly under review, and every now and again a new version is released.
As there are legacy work practices and softwares that rely on old versions these old versions tend to still be in use well after a new version is released.
Also draft versions exist for years and may be used on real projects as they are the only option available (as Autodesk did - see below).
Keep in mind whoever you are providing classification codes to may not necessary require the latest version, or may require you to use a draft version.
You could offer to provide the version most convenient for you to accomplish, which is not necessarily the latest (more on that below). However if whoever you are providing it to has not stated what they require you may have trouble arguing that an old version is 'fit for purpose'.

Best practice is to ask which version is required. If that is not possible explicitly state which version you will provide.

3.  Which tables will be used.
Omniclass has 15 tables, Uniclass2015 has 11, you don't want to commit to providing relevant codes from every table to all objects.

Offer to provide codes from one table: Omniclass Table 21 - Elements, or Uniclass2015 Table  Ss - Systems.

4.  Number of Codes per object.
Classification tables describe different things that might apply to the same object. Also our BIM objects often contain multiple things that might attract a classification code (e.g. a door has many components - locks, handles, closers, hinges etc).

Restrict your offer to a single code per object, that is, a single classification parameter per object.

5.  Depth of Codes.
Omniclass Table 23 is 7 levels deep, Uniclass2015 Table Ss is 4 levels deep. The deeper the level the more specific the information. The more specific the information the more objects required in your model. If you provide codes down to the level of door locks, you will need an object for each lock to hold the code (as opposed to a door parameter that describes the type of lock).

Only offer to provide codes to the first level of the classification system.


Now, all this sounds complicated, but can be captured in one sentence:

Omniclass:

We [normally/can/may/offer to/will] provide a single classification code to each appropriate object in our models conforming to Omniformat 2012, Table 21 - Elements, to a level of detail equal to Level 2.

Uniclass:

We [normally/can/may/offer to/will] provide a single classification code to each appropriate object in our models conforming to Uniclass2015, table Ss - Systems, to a level of detail equal to Sub-group.

You can of course provide more than this, that is your commercial decision. My recommendations are a base line, a minimum that is reasonable. The point is to place a value on providing classification codes for others to make use of. Classification data entry takes time and effort and should be paid for.

WORK OUT HOW YOU ARE GOING TO DO IT

Before embarking on the task of assigning classifications, including pre-populating component families, establish the methods you will use. Poor choices and decisions can turn the task into a job that eats up hundreds of man hours.
Don't assume anything. Test every step, and verify every result.
In particular make sure you are aware of the abilities and limitations of the software you intend to use.
I've only investigated Revit (which I will go into more detail below). Amongst other things I found that:

The default Omniclass Table 23 - Products data in Revit is WRONG (kind of, see below).
The default Omniclass Table 21 - Elements data in Revit is OUT OF DATE

This doesn't mean you can't, or shouldn't, use Revit. These issues can be resolved. But only if you know about them. Software vendors never take responsibility for the results their software produces (read any T & Cs), so don't trust files provided by vendors containing data you are responsible for. Check they are correct.

The Boring Details

If you really don't care about classification systems you can stop reading now. Perhaps come back when your client or boss requires you to become a data entry operator plugging in classification codes.

WHAT ARE CLASSIFICATION SYSTEMS?

By classification systems I mean Omniclass from the USA, and Uniclass from the UK. There are other non-english classification systems which I am not familiar with, nor ever hope to be. There are also various standards, but I'm not going to go there either.
Classification systems are hierarchical numbering systems (although some contain letters) that attempt to provide a unique number for everything that needs to be described in the building process.

An example from Omniclass Table 21 - Elements:
21-03 10 30       Interior Doors
21-03 10 30 10  Interior Swinging Doors
21-03 10 30 20  Interior Entrance Doors
21-03 10 30 30  Interior Sliding Doors

An example from Uniclass2015 Table Ss - Systems:
Ss 25 30            Door and window systems
Ss 25 30 20       Door, shutter and hatch systems
Ss 25 30 20 16  Collapsible gate and grille doorset systems
Ss 25 30 20 25  Doorset systems
Ss 25 30 20 30  Frame and door leaf systems
Ss 25 30 20 32  Frameless glass door systems


Both systems are made up of a number of tables. Uniclass has 15, although Uniclass2015 has 11 (maybe 10 now - see below). I counted 15 in Omniclass but the last one is numbered 49. I don't know if this is because there are yet to be release tables, existing tables have been deleted or the numbers are just not sequential.
Some tables come from pre-existing classification systems, Omniclass Table 21 from Uniformat, Omniclass Table 22 from MasterFormat.

Oh, and there are two Uniformats, plain old Uniformat and Uniformat II.
And there is Uniclass, Uniclass2 and Uniclass2015. Uniclass is the original developed before BIM, Uniclass2 was going to be the new version with better integration between tables. That partially complete system has now been re-branded as Uniformat2015 by the UK NBS who are working on it as part of their government contract to create a "BIM Toolkit".

Which classification system is best? Who knows (or cares). If an article from the UK NBS: Omniclass: a critique is anything to go by Uniclass2 is better structured for BIM than Omniclass.
Except Uniclass2015 (remember, Uniclass2 is now called Uniclass2015) is incomplete, only four tables are available (I hesitate to say 'published', they are still draft), so may or may not be usable, depending whether the bit you need is sufficiently complete to be useful.

It seems that most tables grew from cost estimating requirements, with the exception of the Work Result tables which seem to come from specifications systems. Omniclass Table 22 is based on MasterFormat, and Uniclass Table  J (Table WR in Uniclass2) is based on CAWS (Common Arrangement of Work Sections for building works) classification.

Except that Uniclass2015 Table WR has now been withdrawn. Apparently is is redundant as "it has become clear that this table is confusing (why have objects got two near-identical codes?), redundant (objects only need one code) and unnecessarily restrictive on the other tables (the number of levels was limited in every case)."

I suppose they know what they are doing.

WHO USES CLASSIFICATION CODES?

As mentioned above historically classification codes have been used for cost estimating and specification writing.

Sometimes they are used for classifying product libraries, or naming systems in CAD and BIM software. Attempts at the latter are rarely successful. Not many people know that 21-03 10 30 means interior door, but every knows what "Door-Interior" means. I have seen the sad remnants of misguided attempts to introduce naming based on opaque classification codes in a number of architectural offices.

So it is the cost estimators who mainly use classification codes, working for the owner, the contractor; or as a consultant to owners, design professionals, or contractors.
Classification codes may possibly be used for specifications but they are the providence of design professionals, there is no need to pass that information on to others within a BIM model.

Classification codes are hardly information that is required by all participants within the AECO work chain.

ARE CLASSIFICATION SYSTEMS NECESSARY FOR BIM?

When computers started to be used it was found classification codes and their tables were not as logical as everyone assumed, hence all this reworking and new versions.
But there seems to have been a knee jerk reaction that classification systems are necessary, even critical, for BIM to work.

I don't see it. BIM software brings its own structuring of data that can be utilized for costing and specifications. I don't see that it is absolutely necessary to add another layer of information that duplicates existing data.
Particularly when existing classification systems do not provide enough coverage. The Uniformat codes produced for Autodesk (see below) have an extra 3 levels of numbers. Presumably because Uniformat did not have enough codes to cover all the things that Revit can model.

And where does IFC fit into all this?
IFC is a 'schema', it not only identifies objects but also locates them in relation to other objects. So IFC not only knows something is a door, it knows which wall it is in, which rooms are around it, which lock it has.
Which raises the question of why have IFC and classification? Or why can't classification codes be built into IFC? Match IFC attributes to classification codes within IFC software so users don't have to manually enter them.

Of course it is not that simple, or more precisely, practical.
Whilst Uniclass2015 has a whole lot of codes for door hardware, there are no definitions for door hardware in IFC. Both are incomplete, but in different ways.
And the logical structure is different. Classification system grew from a system designed for humans to use, IFC is for software to use. Is the effort to make them align worth it, will it produce a practical result? Something that will actually achieve useful outcomes in the real world?

I'm not advocating that classification systems be abandoned altogether. It is just that they are 'nice to have' rather than a necessity. Don't be fooled into thinking they are critical part of BIM.

ADDING CLASSIFICATION CODES

Apparently it is really simple. You just add the appropriate classification code to parameters attached to objects in your BIM model.
To put this in perspective, the appropriate code from a choice of 6,905 codes in Omniclass Table 23;  a choice of 6,470 in Uniclass2015 Table Pr. Added to parameters in each of the thousands of objects in a typical BIM model.

But, I hear you say, we use BIM, the software will do it for us. Yes and no.

I'll restrict my discussion to Revit, because that is what I use. And because I couldn't be bothered re-spending the time I wasted discovering how things don't work in Revit on other softwares.

Revit has two built in places for classification values, and a third that can be re-purposed to do it. The fourth way is to manually create custom parameters.

Each family file (components like doors, furniture, etc) has a file based parameter called Omniclass Number. This is for Omniclass Table 23 - Products. When this parameter is selected Revit provides a dialogue box where you can select the appropriate code from a drop down list that can be sorted by Revit category. So if you are in a Door family only codes appropriate to Doors are offered for selection. Revit also fills in the Omniclass Title parameter automatically. Nice.

All types of objects also have a parameter called Assembly Code. This is not file based so categories that don't exist as separate files, like walls, floors, ceilings, roofs have this parameter. It works the same way as the Omniclass parameters, the user is offered a selection from Omniclass Table 21 - Elements that only applies to the category of the object. Revit automatically fills in the Assembly Description parameter.

The third way is to use the Keynote parameter. All types of objects have this parameter. When Keynote is selected a user defined tab delimited text file is read that lists the code opposite its title. The user selects from the list. Some organisations have created Keynote files for use with their classification systems. In Australia NatSpec has done so for their specification codes (get it here). Note that the one that comes with out of the box Revit in Australia is not the latest version.


The Omniclass Number and Assembly Code values also come from tab delimited text files (although formatted differently).
Omniclass Number values are in OmniClassTaxonomy.txt. This file is located in bowels of windows on each users local computer at %APPDATA%\Autodesk\Revit\<product name and release>.

Assembly Code values are in a file called UniformatClassifications.txt. A copy can also be found in the bowels of windows, but you can change the path to this file, and even path to a different file.
The command to do this can be found under the Manage tab > Additional Settings > Assembly Code. In this command there are a number of ways the definition file can be pathed, one of which is relative the Library set in Options. It seems AutoDesk assume Assembly Code values may be associated with particular component libraries.

The path and file to the Assembly Code definition file is set in each file. So individual projects, and individual family (component) files, can be linked to different Assembly Code definitions.

The automatic assigning of Assembly Description (and Omniclass Title) only happens if the correct files are associated with the file you are in.

Revit also provides a keynote file based on Omniclass Table 22 - Work Results (aka Masterformat).

Because Revit uses separate text files it is possible to replace those files with different ones; a different classification version, or completely different classification system. As long as the files are formatted correctly. Which is sort of great.
Except to replace OmniClassTaxonomy.txt you need to replace it for every user on every individual computer. And it will then apply to ALL projects and family files used by that user on that computer. It is an office wide change, not an individual project change. And you will need to do it every time there is a new version of Revit. You can't change the filename either, it has to be OmniClassTaxonomy.txt, which makes it hard to identify what the file contains.

UniformatClassifications.txt is a little easier. As described above you can change the path and filename via a menu command. Although it is a bit tedious if you want to associate a different definition file to family (component) files, as you have to open, make the change, and then save every individual family file.

ALTERNATIVE CLASSIFICATION FILES

Why would you need to change the files? Obviously if you need to use Uniclass (more on that below), but also if you intend to use Omniclass.

OMNICLASS

As mentioned above the default files that come with out of the box Revit are not correct.

The default OmniClassTaxonomy.txt is based on a 2006 draft version of  Omniclass Table 23 - Products. There are valid historical reasons for this, Autodesk are not being belligerent. They introduced Omniclass for families files so they could use it to classify them in their web based component library AutoDesk Seek. It was never their intention to support Omniclass for general users.

A newer version based on Omniclass 2012 is available from Autodesk at Update OmniClass Taxonomy File. However the new file doesn't associate Omniclass values with Revit categories. I'm not sure why, there is no technical reason it couldn't. I'm also not sure why Revit 2016 still ships with the draft version of Omniclass.

If you use the Omniclass Number parameter it is important you make a decision, because Omniclass values for the 2006 draft are DIFFERENT from Omniclass 2012.

Default Omniclass -Interior Doors:  23.30.10.00
Omniclass 2012    -Interior Doors:  23.15.11.15


The default UniformatClassifications.txt file is a modified version of Uniformat II. It was created for Autodesk by RSMeans, a USA costing data provider. They modified it by adding up to an extra 3 levels for a maximum depth of 7 levels, whereas Uniformat has a maximum of 4 levels.

Autodesk now also provide with out of the box Revit the UniformatClassifications_2010.txt file. This is an updated version of Uniformat.
Again, there are differences in the numbering between the two versions:

UniformatClassification.txt           - Interior Doors:      C1020
UniformatClassification_2010.txt - Interior Doors:      C1030

You could also make your own OmniClassTaxonomy.txt or Assembly Number definition file from publicly available excel files of Omniclass tables. Although you will have to reverse engineer the file structure from Revit's files.

UNICLASS

I couldn't find any Uniclass equivalents of  OmniClassTaxonomy.txt  or  UniformatClassifications.txt. I did find some people who have created their own, so it is possible, although you will have to reverse engineer the file structure.

Some Uniclass 2015 tables are available as excel files from the NBS BIM Toolkit site (scroll to the bottom of the article).

But there is a deeper problem. Uniclass 2015 is not complete, it is still being developed. Admittedly the tables you are most likely to use, Ss - Systems and Pr - Products are more developed than some other tables. But no-one will guarantee they won't change. In fact the downloadable excel files have a suffix of 'latest'. Doesn't exactly instil confidence. I wonder if they don't finish this year they will still call it Uniclass2015.

CONCLUSION

Classification systems are probably useful, to certain people in certain circumstances. But they are not a requirement for BIM to work.

Although my comments about the lack of completeness may have come across as captious, my view is that it is always worthwhile making improvements. The process is disruptive but if we don't constantly strive to improve we will be stuck with impractical systems. Imagine having to use the Roman numbering system! I encourage those working on updating classification systems to continue their good work.

But there appears to be quite a way to go. Not only do we need the the classification systems to be BIM friendly, complete and stable, they need to be available in a consistent and durable way so that software houses can access them for integration into their softwares.

To be honest, I don't see how anyone can take them seriously until this happens. The journey I had to take just to identify which codes I should apply to our in-house component library has been ridiculous. Time in my life I'll never get back.


If you have managed to get down to here, well done. You now know a bit more about classification systems. Not everything mind you, there are even more boring things you could be abreast of.
And of course everything I have explained may not be 100% correct. If you see anything wrong, or misinformed, please comment. I'm quite happy to be proved wrong, but don't expect me to care.