The Nature of Naming

BIM is by nature a shared environment. For example in the context of Revit each discipline team work together in one file.
This new paradigm means things have to be shared, people can't isolate themselves in the CAD files they are working in and name things however they want. Nor can they create new things to suit their own purposes. Anything created in a BIM file is for everyone to use.

How things are named becomes critical, because it is how different things are recognised by different people.
Not only so people can find the things they need, but also so things that are the same are not created multiple times with different names.

Many things are named in BIM, from filenames to parameters. This post concentrates on the naming of components (families in Revit). But the principles expounded are applicable to all naming.

WHAT NAMES IN BIM ARE USED FOR

Who uses and relies on names in the BIM model?
Receivers of BIM information don't care what the name of an object is. The information they require comes from object parameters. You don't produce a wall schedule for the contractor that lists the Revit names of walls, you list wall code, thickness, materials, fire, acoustic ratings etc. Indeed, if you are asked to use a particular naming schema by a client or contractor in your BIM software politely refuse. It is totally unnecessary.

The purpose of names is so BIM authors can identify things when they are creating them. When confronted by a list of wall names in their software they can identify and select the one they need. Or if what they need doesn't exist they can create a new one using a naming schema that others will understand, so someone else can use the wall that they made.

If objects have so many parameters why is the name of it so important? The information is there, you just have to expose the relevant parameter value.
This is true. But the stumbling block from a practical point of view is "exposing the parameter". In an ideal world (with ideal software) you could sort and filter by all the parameters an object has rather than just its name. There are Revit add-ins that do this to varying degrees (I welcome comments suggesting such add-ins). Revit out-of-the-box does not. The other issue is even if you could select by parameter the name still has to be unique. Unless the add-in controls naming of components, you still have to come up with a way to create unique names.
That said, an add-in may be a viable solution. But for the rest of us who can't get our bosses to pay for add-ins the problem remains.

BIM IS NOT CAD

Naming was also important in CAD. Every office had a CAD Naming Standard. But there are important differences to BIM.

The most obvious difference is that the output of CAD is drawings, lines on paper. In fact many CAD standards did little no more than describe lines. Layers names like 5_PEN.

With BIM you are dealing with objects, virtual objects that represent things that exist in the real world. When you model a wall you are creating an object that has (in Revit) upwards of 24 different bits of information, or parameters (in Revit speak).
In CAD you might have three; colour, pen weight and line pattern. Enhancements like multi-lines might increase this by 3 more by adding thickness dimensions, but still no-where near the number BIM encompasses.

In reality correct naming was not that critical for CAD. If a layer (or Level in Bentley) was named WALL_BRICK in one CAD file and BRICK_WALL in another, as long as they had similar line thicknesses  and patterns the drawings produced looked the same.

In BIM if you have two wall definitions with different names that are actually the same wall (i.e. have identical parameters) not only will your schedules be misleading (i.e. identical walls with different codes), if there is a change made to one and not the other that change won't propagate across the project (e.g. MR plasterboard changed to Fibre Cement sheet).
The effect is the BIM model becomes unreliable.

THE DOS LEGACY

CAD software started to be used back in the days of DOS (Disk Operating System). This was a text based language developed in the early 1980s when computers had very little memory. So little the length of filenames had to be restricted to 8 characters. And even then only uppercase letters (A-Z), numbers (0-9), and the underscore (_). This was because other 'punctuation characters' (including spaces) were used by DOS for programming.
Although these restrictions only applied to filenames they were usually applied to internal naming as well (early AutoCAD had restrictions on layer name length, Microstation Levels only used numbers up to 63). This was due to a mixture of software creating files hidden from users, internal memory constrictions, or just habit on the part of software coders.

It wasn't until the introduction of Windows NT & 95 (Apple always had fewer restrictions) these restrictions started to relax. Dashes (-) became permissible, the file name length increased to 31 characters, lowercase was displayed.
Now most punctuation characters are allowed, (only  \ / ? : * " > < |  can't be used), and restriction on length is 260 characters.

Many CAD standards still used today were originally created back in the days of DOS, when CAD naming schemas obsessed with the number of characters and only allowed letters, numbers and underscores.
Even today many IT and CAD managers still insist these old DOS restrictions be maintained, because back in 1998 they had an incident where it mattered. When pressed their best reason is do it "just in case".
Indeed there is still software around where it matters, but I find if this is the case invariably there are other reasons not use it (I tried an accounting package with these restrictions but stopped using it because it was like using software from 1998). To me it is an indicator of software which is ancient, or considers coding more important than usability.

In 2014 there is no practical reason to restrict naming schemas to suit computers from 20 years ago.

WHAT MAKES A GOOD NAMING SCHEMA

Apply these simple principals.

UNDERSTANDABLE

The most important criteria for a naming schema is that it is understandable by everyone who will interact with it.
This is not as onerous as you think, as mentioned above only BIM authors make use of names so this cuts down the audience considerably.
There are many ways to make a naming schema understandable. There is really no one size fits all. What works in one office may not work in another. Architects respond differently to engineers, a design office will respond differently to a documentation workhouse.

How do you make a naming schema understandable?

• Be literal:
  call 13mm plasterboard, for example, plasterbd13 not P01 or L13.
• Be consistent:
    brick110 and plasterbd13
    not
    110brick and plasterbd13.
• Use punctuation that is meaningful:
    brick110 / stud92 , insul50 / plasterbrdMR13 + tiles
    not
    brick110_stud92_plasterbrdMR13_insul50_tiles
• Manage the unmanaged:
  Use a prefix and name structure to identify objects that are managed.
  For example:
  - prefix material names to separate them from rubbish that comes in with imported files:
     .plasterbd
  - name things that are standard differently:
    2.5 text   is standard;
    Black 2.5 bold   is not standard.

COMPREHENSIVE

Naming schemas need to be capable of naming absolutely every possibility for objects they are applied to.
If they don't how do your users name something the naming schema doesn't account for? They make it up, and each one will make it up in their own unique way. To say something is hardly ever used is not a solution, it is a cop-out, what I call an excuse, not a reason.
This doesn't mean a naming schema has to be ridiculously long. By utilizing meaningful punctuation fields of information can be optional - left out if not relevant. If necessary the schema defines what the value is by default, and how it is added to the name if it is not the default.

• Define a name schema to include all variances that are possible, not just those that are probable:
  In Revit look at all the Type parameters of the object being named and make sure the ones that will cause a new type to be created has a place within the name structure.
• Use optional fields:
     brick110 / stud92 / plasterbrdMR13
     can be extended to
     brick110 /stud92 , insul50 / plasterbrdMR13 + tiles
• Assume default values:
  walls are internal unless nominated otherwise,
     -/block140/- is interior wall;
     -/block140/-.e is exterior wall

WORKABLE

There is no point creating a fabulous naming schema if no-one uses it, or uses it properly. It has to work in practice.

It is a trap to think because you have a captive audience in your office you can rely on training to enforce a naming schema.
The reality is Architects and engineers, the BIM authors, don't care about naming schemas. Nor should they be expected to. They are hired to provide their professional skills in designing a building. And that is what they want to do, not obsess over how they name things.
People new to the office, or project, also need to be considered. No boss wants their highly paid engineers spending hours learning naming schemas, they want them producing billable work.

And relying on training will only be effective if the naming schema actually works. An all too common assumption is that if only everyone used it properly there would be no problems. Whether it does what it needs to do is never challenged.

How to make a naming schema work:

• Set general rules for name creation rather than a rigid rules:
  names follow major-medius-minor rule rather than 3 uppercase letters, underscore, 4 lowercase characters, underscore, 2 numbers.
• Create a naming structure rather than a rigid standard:
  allow 13mm plasterboard to be named plasterboard13, plasterbd13 or pb13, not just PB13.
• Document naming schemas:
  don't rely on people memorizing what they learnt at a training session; provide examples, cheat sheets, easily update-able and searchable documentation (i.e. web manuals or wiki)
• Adjust naming schemas to suit particular projects:
  work with project teams to get a schema they are comfortable with.
• Investigate how people use naming schemas:
  instead of forcing recalcitrant users into training ask them what they would change to make it useful to them.
• Review naming schemas in the light of experience:
  don't be afraid to make changes when it is warranted.

As an example of making changes to suit users, I recently added tag codes to the front of wall and material names.
e.g.
brick110 / stud92 / plasterbrdMR13
became
W.B201_brick110 / stud92 / plasterbrdMR13

To me this is poor practice as codes are unique to a particular project, and there is an overhead in keeping the names matching the code parameter (in our case Type Mark).
But users felt more confident selecting items clearly identified with the code used in tags. (Wall types not yet assigned a code were named: W.Bxxx_....).
From a purely data management view not ideal, but if it helps people do what they need to do so be it.


The bottom line is BIM standards, including naming schemas, should never be considered set in concrete. BIM software development is fast moving and standards need to move with them.

CONCLUSION

At the end of the day naming schemas, and office BIM standards in general are for humans, the users of BIM software, not the software itself, the IT system or those that run it.
When dealing with humans a rigid purely logical approach is rarely successful. What is called for is 'fuzzy logic' (to use a software term); simple rules that have a degree of flexibility.

Despite my examples above, (which are not from a real naming schema), I have deliberately not been specific because I don't believe there is such a thing as the perfect schema. To be practical a naming schema has to suit the people who work with it, so they (or someone in direct contact with them) need to be the ones who work it out.
What I have tried to do is reveal some of the guiding principles behind a workable naming schema.


Creating BIM standards is a hard and thankless task. You will never satisfy everyone, you will never achieve the perfect standard, and the job is never completely finished. But there are benefits to even partially successful standards. It is worth the effort.


There will always be resistance to change, but don't accept excuses masquerading as reasons:

• I don't like it:
  - it is not an aesthetic decision so who cares what you think.
• We have always done it that way:
  - if that was the case we would still be drawing on linen with quills.
• People are already familiar with the current system:
  - not relevant if the current system is unsuitable for BIM.
• It works now so why change it:
  - does it? really? let me show you otherwise . . .

Bored with BIM? Need a present for that special woman in your life? The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, fashion, new media and ... men. The complete series, "AWAKENING the lost woman", "CAPTURING the lost woman" & "FINDING the lost woman" is available now on Amazon, Kobo, Google Books, Barnes & Noble and iBooks.