Languages are incredibly analogue, making it difficult to fit what we say into our logical, cold, and uncompromising digital world. With English it is particularly difficult. As a quilt of a language, English has inherited many inconsistencies such as: strange pronunciations (slaughter is laughter with an “s” at the front), and inconsistent terms etymology (pig is German, while pork is French). Languages like Welsh, on the other-hand, are phonetic and use consistent terms (moch = pigs, cig mochyn = pig meat).
I’m sure you’ll be glad to hear that this article isn’t all about the superiority of the Welsh language, but it is instead a post about the follies of trying to digitise information using the analogue method of communicating and structuring information known as language.
Classification
Our world isn’t black and white, so it is easy to misclassify (or overclassify) objects. From the Tree of Life to Uniclass 2015 it is not an easy job to provide order to this chaos, leading to difficulties when trying to classify.
I’ve written about the Nest Thermostat previously but I didn’t mention its classification. My Thermostat, being a clever tool, functions as many things and therefore could be classed under Uniclass 2015 as a: Pr_70_70_47_21 – daylight sensor; Pr_75_50_76_73 – room temperature sensor; Pr_80_51_85_21 – data logger; Pr_40_30_25_23 – display screen; and many others. Its primary function, however, is as a thermostat, with the closest classification I can find being Pr_75_50 – mechanical services control product.
This means that while everyone on a project might be using a single classification system, there is to guarantee that they will use it consistently.
Would everyone classify my Nest Thermostat as Pr_75_50 – mechanical services control product?
Naming
Just like classification, we are also terrible when it comes to naming. For example, due to the fact that radiators emit 80% of their heat as convection, and 20% as radiation, radiators are actually convectors.
In addition, models aren’t federated, federation is for federal unions, they are really integrated models; gargoyles have water spouts, without spouts they are grotesques; and BIM barely has any acronyms. Acronyms are spoken as words, meaning that terms like EIR, DRM, TIDP, MIDP, IFC, IDM, bSDD, and BCF are actually initialisms. +10 Pedant Points
To show how complex naming can be, last week on Twitter I asked how to name my Amazon Dash Buttons (wifi-enabled buttons for ordering products off Amazon), and the results were inconclusive.
This means that while everyone on a project might be following the same Object standard, and even using the IFC schema to limit their choice of relevant types and sub-types, there is no guarantee that they will use them consistently.
Would everyone name my Amazon Dash Buttons as Communication Appliances? Not even I would, as I’d use Switch_MomentarySwitch.
Distances
In mathematics numbers have an order for numbers. We have: cardinal numbers, the principle set of numbers; ordinal numbers, used to provide a ranking; and nominal numbers, used to identify (not necessarily by rank).
The same can also be applied to directions for both cardinal or ordinal, but what about nominal? Well as nominal numbers are used to identify, then top, bottom, front, back, left, and right can be considered nominal directions; but how to measure these distances?
If I wanted you to measure the distance across the front of a cube, what are you measuring? Its length, width, breadth or depth? The answer will differ depending who you ask as there is no consistency on how we name these distances.
This isn’t a new topic, many have discussed it previously such as practical BIM when considering which direction is depth, and more recently Keith Wilkinson is conducting a survey to gain a consensus on what to call these directions.
In many commercially available authoring tools, you are able to name (and in my case misspell) these distances anything you like. So while we might instinctively know what to measure when asked how tall a door is, when we are asked how wide a cabinet is, there is plenty of room for varying interpretation.
This means while everyone might be using the same language, variation in how it is used can change the values recorded against attribute data such as height, width, depth, and length – all of which are required by COBie.
On this project I have specified Uniclass 2015, BS8541-1, COBie, additional EIR attributes so I have a consistent method of classifying, naming, and attributing data. However, it is one thing to specify their use, and quite another to ensure that they are being used consistently and appropriately.
The only way to ensure the application of this information correctly is to further qualify their use within my BIM Execution Plan. It looks like a revision is in order…
This article, along with many other informative pieces, was originally published on Rossiter’s blog There’s no BIM like home.
