OmniClass™: a critique

It has been suggested by some that, rather than developing or implementing Uniclass2, we in the UK should switch to OmniClass, used in North America. John Gelder, Head of content development and sustainability, takes a critical look at OmniClass, comparing it throughout with Uniclass2.

OmniClass is the North American equivalent of Uniclass2. Both are aligned to ISO 12006-2. OmniClass is promulgated by CSI (Construction Specifications Institute) and CSC (Construction Specifications Canada). OmniClass, and its predecessor Tables such as MasterFormat and UniFormat, have been widely used across North America for many years in their various editions.

Broadly speaking OmniClass is in a similar position to Uniclass 1997, with much the same general limitations, though it is rather more unified. Accordingly, this article parallels my earlier article, Unifying Uniclass.

The big difference is that while we can readily 'fix' Uniclass 1997 (hence Uniclass2), it is more difficult for us to influence OmniClass – we would just have to use it warts and all. The North American committees responsible for the various Tables are unlikely to change them quickly, if at all, in response to any requests from the UK. So, what are the warts?

Scope

OmniClass comprises 15 Tables. Some emphasise the architecture sector (buildings and landscapes), but some serve civil and/or process engineering as well. See Table 1. The stars indicate my own estimate of the emphasis in each Table.

Uniclass2 has a better balance – every Table does, or will, cover all three sectors. However, the Tables when first released emphasise the architecture sector since that is the area of expertise of the compiler (NBS, contracted to CPI).

Table 1: OmniClass Tables – scope

There are some technical gaps in the scope of OmniClass. For example, it has no Tables for the high-level objects 'Regions', 'Districts' and 'Complexes', and there are no Tables for 'Activities' or 'Systems'.

Uniclass2, including its planned Tables, will not have these gaps. The Complexes, Activities and Systems Tables have been published already.

Coding

All the Tables are fully numeric, with 100 possible codes per level. See Table 2.

Uniclass2 has similar consistency, except that the section codes are alphabetical (so you can easily see when Table codes are being used, and so the subject of the Table is hinted at).

Depth

The depth of the Tables is not consistent – one Table comprises up to eight levels (Table 23 Products), and one (Table 31 Phases) has just two, for example. See Table 2.

Uniclass2 is more consistent – most Tables have four levels (if you include the Table code).

Table 2: OmniClass Tables – coding, depth and placement

Object placement

Table 31 Phases places the objects it is classifying at the same (lowest) level throughout, but the other Tables may place objects at any of between two and six levels. That is, in all but one Table, at least one level may be used both for collections of objects and for individual objects. See the red levels in Table 2.

Uniclass2 always places the objects at the same (lowest) level in each Table – the other levels are always for collections so, if they are empty, this only indicates that they haven't been populated yet. You know where you are with Uniclass2.

The worst behaved Table is for Products – objects (products) could be at any of six levels. For most Tables, the highest level object is at level 3. Lowest level objects might be found at any of levels 2 to 8 inclusive. This leads to inconsistencies, e.g. the chemical elements in the Materials Table are not all at the same level. Also, it means users don't know when they have got to the bottom of a Table – if a particular level is empty, is that because the compilers haven't populated it yet, or is it because there are no objects below this level? The use of 00 doesn't help as it doesn't necessarily indicate an object collection (e.g. group or sub-group) – it could actually be an object.

00 is not used in this way in Uniclass2 – so 45 is a group-level parent to sub-groups 45-00 and 45-25, whereas in OmniClass 45-00-00 may be a group-level parent, or it may be an object.

For example, in the Work Results Table, the final 00 generally indicates that there are sections below this. So under 23-01-00 we have 23-01-30 Operation and maintenance of HVAC air distribution. But, sections might be at the 00 level. This allows ARCOM's MASTERSPEC to have sections at what we would normally think of as sub-group level, such as 00-26-00 Procurement substitution procedures, 03-30-00 Cast-in-place concrete and 33-46-00 Subdrainage (the Table identifier isn't used in these codes, just as it isn't in NBS Create).

NBS Create sections are always set at the same (lowest) level in the Uniclass2 Work Results table.

Some of the OmniClass Tables have a disproportionate amount of content devoted to health care, presumably reflecting an area of interest of the compilers. For example, in the 'Spaces by function' Table, 'Healthcare spaces' constitutes about 45%, and about 23% of the Products Table comprises 'Medical and laboratory equipment'. We are trying to be more balanced in the development of the Uniclass2 Tables.

Alignment

The Tables should align, with similar terminology, sequencing, grouping and coding as far as practicable. For example, the Tables for elements, work results and products should align, so that elements can be mapped to systems (described in work sections) which can be mapped to their component products, i.e. in the project model. Consider building services: the three Tables don't fully align. See Table 3a.

A worse example is the non-alignment between the 'Entities by function' and 'Spaces by function' Tables (11 and 13 respectively). See Table 3b, which illustrates corresponding selections.

In Uniclass2, the Elements and Systems Tables align at Group level (same terminology, sequencing, grouping and coding), but the (unpublished as yet) Products Table takes a different tack in its classification (e.g. by Skin products or Source products) and so can only align partially.

The Uniclass2 Entities (by function) and Spaces (by function) Tables align at Group level, and both align with the Regions, Districts, Complexes and Activities (by function) Tables.

By its very nature, the Uniclass2 Work Results Table aligns to all the other Tables for physical objects, down to Section level.

Table 3a: OmniClass Tables 21, 22 & 23 – imperfect alignment

 
Table 3b: OmniClass Tables 11 & 12 – imperfect alignment

Some Tables offer several alternative approaches for classification. Table 13 'Spaces by function', for example, mostly does what it says, but also includes a short classification by planning type. Table 14 'Spaces by form' is mostly about form, but includes a legal and geopolitical classification. ISO 12006-2 provides for alternative approaches to the classification of entities, but it does this using separate Tables. Otherwise a given object would, within the one Table, have more than one classification.

OmniClass aligns fairly well with ISO/CD 12006-2 (the Committee Draft of the new edition) – only one ISO Table isn't in OmniClass (Complexes), and only two OmniClass Tables aren't in the ISO (Materials and Organizational roles). SectionFormat is outside OmniClass, though it is an essential complement to the Work Results Table. See Table 4. However, it is a bit of a concern that the USA is not represented on the ISO subcommittee (TC 59/SC 13) for the development of the new edition, though Canada is. Neither country is on the Working Group.

Uniclass2 respects the ISO one-classification-per-Table rule. Uniclass2 also aligns fairly well with the ISO/CD – only one ISO Table isn't planned at this time for Uniclass2 (Spaces by degree of enclosure). But, six Uniclass2 Tables are not in the ISO. These include Regions, Districts, Activities and Systems – tables for these object classes are required to properly serve the complete timeline and all sectors. Tables for Materials and Work Results Structure are also in Uniclass2. The second of these should be inside the classification system, rather than outside it, since it is an essential complement to the Work Results Table, which is pivotal to Uniclass2.

The UK is represented, by the author, on the ISO Working Group.

Table 4: OmniClass and Uniclass2 Tables – mapping to ISO/CD 12006-2

Conclusion

OmniClass is generally in better shape than Uniclass 1997, which it followed and learned from (Uniclass 1997 is cited throughout as a 'legacy table'). But OmniClass is not ideal for current UK needs (quite apart from some of the inevitable UK/USA nomenclature issues, e.g. 'aluminum' and 'faucets').

Not all its Tables fully support all three construction sectors. It is missing some key Tables, e.g. for Complexes and Systems. It has an inconsistent approach to the depth of Tables, and to object placement in them. Tables that could, and should, be aligned (to simplify use of the entire classification system) are not. The Work Results section structure is outside OmniClass.

BIM requires a unified approach to classification if it is to work well, e.g. with simple mapping between classification Tables. OmniClass cannot deliver this, as it stands. Uniclass2 can.

Related NBS information

Articles

• An introduction to Uniclass 2