30 August 2014

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.


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.


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.


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.


Apply these simple principals.


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
      110brick and plasterbd13.
  • Use punctuation that is meaningful:
      brick110 / stud92 , insul50 / plasterbrdMR13 + 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:
    - name things that are standard differently:
      2.5 text   is standard;
      Black 2.5 bold   is not standard.


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


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.
brick110 / stud92 / plasterbrdMR13
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.


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.


  1. Great post Antony. The characters used in BIM naming system should reflect the range used by the operating system being used. BIM naming schemas using \:{}[]!;<>?`and ~ are not supported in Windows (and I think DOS of old has the same limitations). Revit does not allow these characters. Same goes for CAD objects - AutoCAD Block naming has the same limitations.

  2. Indeed Revit does restrict characters that can be used as does Windows. But not exactly the same as Windows.

    Windows does not allow: \ / : * ? " | < >

    Revit does not allow: \ : { } [ ] | ; < > ? ` ~

    But characters still available in Revit include:
    space ! " # $ % & ' ( ) * + , - . / = @ ^ _

    Characters still available in Windows include:
    space ! # $ % & ' ( ) + , - . = @ ^ _

    Another restriction (or good practice, Revit doesn't stop you) is to avoid mathematical characters in parameter names, because Revit treats them as operators if you use the names in a formula. Yes/No gets interpreted as Yes divided by No.
    But that is only in parameter names, names for other things don't end up in formulas.

    Like AutoCAD blocks Revit family files (.rfa) are windows files so can't use characters restricted by windows.

    The bottom line is there are still plenty of punctuation characters available for naming.

  3. Anthony, I have to respectfully disagree with your "punctuation that is meaningful" guidance:

    To my way of thinking, "brick110 / stud92 , insul50 / plasterbrdMR13 + tiles" (which breaks OS filename rules on multiple platforms) is no more or less meaningful than "brick110_stud92-insul50_plasterbrdMR13_tiles". The clarity of the text in between the separators and their order is almost certainly more critical that the separator(s) themselves.

    Why the aversion to the underscore? The advantage of the underscore (ASCII 95) is that it is a visible form of "non-breaking space" that is universally supported and unambiguous. (You can use an ASCII 127 (win) or ASCII 160(mac) as a non-breaking space, but it's not obvious to readers of a string that it's not an ASCII 32 breaking space. To people raised in a hashtag world, a mere underscore should not be so off-putting!

    One sub-topic that might deserve more play is a tactical approach to hierarchical naming. One restriction that hierarchical naming (of any sort) imposes is the need to make higher-level categories less verbose. This is because, inevitably, the differentiation of two entries in a hierarchically ordered list occurs at the end, and not the beginning, of the name. And (system or OS limitations notwithstanding) the length of a name is important, not just for user reading fatigue but also for practical UI issues. For example, long names will often by truncated by various UI elements (dialog lists, for example). Thus, it makes sense for the higher-level categories to be shortened. For example:


    will scroll off or be truncated in many displays. But


    Gets to the "good stuff" faster..

    1. Robert, Your attitude is exactly what I am talking about.
      When naming in Revit what relevance are the restrictions on operating system naming? Revit is not an operating system, nor do names in Revit have to interact with operating systems (with the exception of project and family names).

      My point is what are the specific advantages to restricting naming to OS requirements? I know there are advantages in extending it. For example using punctuation to mean something is that you can use that punctuation in Revit view filters. Search for '=fe' to find all external walls. Also most punctuation is narrower than an underscore (in proportional fonts - yes modern OS use proportional fonts) keeping names just that little bit shorter.

      And what advantage is there to users by shortening names until they loose all meaning?
      Anyone can understand what "Architectural_Wall_Bearing_CMU-8_R14_Brick-veneer" is.
      But "Ar_W_Brng_CMU-8_R14_Brick-V"? Gobbledy goop.

      The point of naming is so that humans understand what something is, not to comply with the requirements of archaic IT systems.

    2. One good reason to restrict naming to characters that are supported by all OS's is so that you don't get gibberish (or outright mistakes) when you send someone a message or an email and they are working in a different OS (or a mobile OS).

      As for the contractions, my point is that there are good reasons to abbreviate the more general categories. I'm not saying that my particular example was thoroughly considered. Indeed, there may be somewhat of an art to finding contractions that unambiguously "read'.

      Finally, considering your Revit examples, I would remind that BIM <> Revit. Otherwise, you should change the name of this blog.

    3. Antony, I think you missed the critical points of Robert's post:
      #1 names such as your wall example will be truncated to fit into the window\dialog box in most cases, you would only be able to see the first dozen-odd characters unless all of your users have a 30" screen with wide dialog boxes (a pretty rare scenario), adding subtypes will only agrivate the problem further as most additional information would be cut-off;
      #2 at some point in it's life, your models may be exported or components\families saved to another file or format, at this point the longer descriptions will be lost and probably mangled by the OS restrictions in order to comply, components of the file (eg. different types) may in some cases be merged into a single type — thus the characters can be a potentially huge stumbling block.
      It's a brillant idea to show all key information all the time, but it's not without it's hurdles.

    4. Following this with interest. I think that is in important to be able to export/import objects to and from a BIM system and while the operating systems may be "archaic" , these will not change any time soon. As for the length of name, there are issues with operating system path/file names being more that 256 characters long so keeping a name shorter is safer.

      I tend to name objects with 3 to 5 fields with a maximum of 4 characters. This give us 24 characters maximum using _ as field separators. The codes are driven from a defined data dictionary and if we automate the naming process, this leads to better consistency.

      Rather than trying to pack meaning into an object name using a complex, coding system, using a simple name structure with 3 fields and adding parameters to backfill the other information about the object maybe be a better approach.


  4. Some good ideas that prompt further investigation, most of the exisitng standards are relevant only in very large, multi-discpline organisations, needlessly complex and lack user-friendliness. The spirit of this approach is far more practical for most cases. I would suggest, when naming families, consider not only the filing aspect, but how they are displayed in Revit — we prefix all families with a 3-char type, so they are much easier to locate\identifiy in the Revit family browser.

  5. This comment has been removed by the author.

  6. Here is what I have come up with for door families and types. Any feedback would be much appreciated.

    Example Family Naming

    Door - Single Swing HM Exterior.rfa

    Door - Double Egress Swing HM Interior.rfa

    Curtain Panel - Single Sliding Alum Automatic.rfa

    Curtain Panel - 3 Panel Telescoping Automatic Sliding.rfa

    Example Type Naming for "Exterior Doors"

    NV HM 36 x 84 5.75J 4H

    FG WD 36 x 84 8.25J 2H

    Example Type Naming for "Interior Doors"

    NV HM 36 x 84

    FG WD 36 x 84

    Swing Door Abbreviations:

    FL = Flush Door
    HG = Half Glass Door
    FG = Full Glass Door
    VL = Vision Light Door
    NV = Narrow View Door
    J = Jamb
    H = Head

    Example Type Naming for "Curtain Panel Sliding Doors"

    SO-SX or SX-SO 2S 4CR 1BR 6J

    SX-O-O-SX 4S 4CR 8BR 4.5J

    Sliding Door Configutaion Abbreviations:

    X = Slide Panel
    O = Fixed Sidelight
    SO = Swingout Sidelight
    SX = Slide/Swing Panel
    S = Stile
    CR = Center Rail
    J = Jamb