Lost in translation: the importance of standard shared parameter definitions

Posted on January 17, 2019 by Vincent Cadoret

Lost in translation: the importance of standard shared parameter definitions

The problem

Human language can be quite ambiguous. Let’s take, for example, the phrase:

He fed her cat food (thanks to Byrdseed for this one)

We could mean either “He fed a woman’s cat some food.” or “He fed a woman some food that was intended for cats.” or “He somehow encouraged some cat food to eat something.”

This ambiguity does not work well in machine language, where everything has to be specifically defined and categorized (binary doesn’t understand grey zones...). Without a standard definition of what a parameter means and what possible values it can contain, it’s difficult to program automated solutions to use/exploit that data.

The same can be said of Building Data. Our experience shows us that without clear definitions of what a parameter means and contains, BIM data cannot be efficiently transferred between parties and software packages. Therefore, in addition to the famous and always valid GIGO, another problem emerges: “lost in translation”.

What’s out there

There are a few notable initiatives out there that aim to solve this problem, including:

Although these are praiseworthy efforts, the first two are vendor-specific and software-specific, which poses at least a couple of issues:

  • You get locked-in with a specific vendor.
  • Tend to be less interoperable with other vendors.

To avoid this “vendor lock-in”, the database of shared parameter definitions should be controlled by a neutral third-party (such as BuildingSMART or NBS) and be vendor-neutral.

However, having one central organisation managing this database also comes with its own issues:

  • Delays in approving & adding new parameters (unacceptable in a project timeline setting where deadlines need to be met).
  • No matter how “neutral” this organisation is, it always has some bias.
  • If the organisation “goes under”, who takes care of maintaining the definitions?

The Solution?

Right now it seems like our best hope for standardizing parameter definitions is IFC by BuildingSmart International. It’s vendor-neutral and controlled by as neutral of a third party as is possible.

IFC4 has an extensive list of parameter definitions across multiple industry sectors, including Architecture, Structure ,HVAC, Electrical and even the Facility Management side of things. It is very detailed. For example, there exist definitions for levels of risk assessment, risk consequences and even packing instructions! This leads to another question about data frugality, but that’s for another article...

Conclusion

A solution already exists to standardize our parameter definitions. It’s called IFC. Granted, it’s not perfect and it doesn’t cover 100% of use cases, but it probably does cover the most common ones.

Then why is there still so much “parameter ambiguity” in the industry? Could it be that the competing interests of software vendors are to blame? Maybe. Is there a lack of understanding about OpenBIM? Is the BIM maturity level of the industry still underdeveloped? Is the need to compete and stand out overpowering the need to collaborate? Or is it simply that existing OpenBIM solutions are too daunting to implement? Our presence in the industry, our expertise in helping organizations implement BIM and in defining their requirements tell us that this is not an exhaustive list of all the challenges, but they all need to be considered.

Going back to our example from the beginning, any ambiguous phrase can be clarified with the use of the proper words so that “he fed her cat food” is clearly interpreted as “he fed a woman’s cat some food”. However, this requires the use of a standard list of words, a dictionary, and some effort on the part of the user to read that dictionary.

So for as long as there are still humans involved in the design process, it looks like we can’t fully eliminate ambiguity. Maybe we have to wait for AI (which is more apt at dealing with ambiguity than traditional programming) to catch up in our industry before true and effortless BIM automation starts to happen.


Vincent Cadoret
BIM Specialist