Hello BIMfans,
After giving my attic some attic-tion (sorry,  again) I wanted to talk to you about an issue I am having.  This issue isn’t directly related to production of my graphical models or information, but it is having a BIG impact on both of these; it’s language.

Our language(s) are incredibly analogue, making it difficult to fit what we say into our logical, cold, and uncompromising digital world; with English 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).

Most of you (at least according to the blog’s analytics) will be glad to hear that this ins’t a post 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 (Zebra’s & LinkedIn Profile pictures being the exception), 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 my 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 primarily 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% of the week as radiation; radiators are actually convectors.

In addition: Models aren’t federated, federation is for federal unions; they are really integrated models; Gargoyle 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 (Wi-Fi 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 to guarantee that they will use them consistently.

Would everyone name my Amazon Dash Buttons as CommunicationAppliances? 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, & 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, & Length; all of which are required by COBie.

Would everyone call distance B width, and distance A depth on this cube?  What about a more complex shape?

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 that 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…