BIM naming standards

Designing a naming system for BIM may be a daunting task if it is started from scratch, not only because of the amount of time it requires but also because of all the planning and experience it demands. It is not only about setting the right name for files and parameters, but it also requires forecasting the future needs of the practice and its scalability. The team or BIM manager in charge should plan ahead for all the possible extensions like libraries, scripts, and projects. And we are here to help you with this task.

In this regard, sources like the Open BIM Object Standards and the NBS BIM Object Standard can offer help in setting up your own naming system.

General naming system rules

Use of characters

This will set the structure of valid characters for any file in our BIM system:

• Uppercase letters (A to Z) from the ISO basic Latin alphabet
• Lowercase letters (a to z) from the ISO basic Latin alphabet
• Numbers (0 to 9)
• Underscore (_), to separate elements between Field, Originator, and Source
• Space ( ), used only for separating fields within a name*

The following characters must be avoided for naming:

• Symbols or mathematical operators, including, but not limited to, (! “ ,£ $ % ^ & * { }[ ] + – = < > ? | \ / @ ’ ~ #¬ ` ‘)
• The period character (.) is used only to define the file extension
• The use of the hyphen character is problematic because is the same than the subtraction operator, so it must be avoided

Abbreviations

Whenever a maximum number of characters is reached, or the maximum recommended amount of characters, abbreviations will be introduced.

General naming scheme

Naming of families or basic objects

For example, following the previous rules, a door family would be named like this:

AR_BIMicon_DoorManufacturer_Door Interior Glazed.rfa.

The reason to use the underscore in the three first fields is to categorize the object, while the fields after the source describe the object. Personally, it is clearer to read and search.

Naming of family types

The types inside this family would be named by its dimensions, in the following order Width x Length x Height:

• 900 x 2100
• 1000 x 2100
• 1100 x 2100

If there are more than one glazing size, this can be named like the following example:

• 150 x 500 Glazing 900 x 2100
• 150 x 500 Glazing 1000 x 2100
• 150 x 500 Glazing 1100 x 2100

Naming of Parameters or Properties inside BIM software

The naming of parameters inside Revit will follow the same rules as previously described but with the exception that it will omit the fields Discipline, Originator and Source.

The main reason is that the family has already been classified and there is no further need to repeat this information. Also, it won’t help to locate parameters more easily inside the family if those fields are added, as it will highlight them over the built-in ones. This is clearly not the case, as the built-in parameters are as widely used as the users created.

For example, creating material parameters:

• Panel Material
• Knob Material
• Kickplate Material

In this case, it is Subtype + Description. The description may sound redundant, as the Type of Parameter is Material and Finishes but the parameter can be grouped under any other one like Dimensions or Text. This will help avoid it.

Another example of naming parameters, the glazing:

• Glazing Width
• Glazing Height

Prefixing the Differentiator will help not mistaken between this and the door dimensions:

• Door Width
• Door Height

Naming materials

The naming of materials should follow the same naming scheme defined previously. For example:

BIMicon_Wood_Pine Clear Varnished

BIMicon_Glass_Translucent Blue

Naming material files

The previous rules apply for material files as well, such as texture, bump or cutout bitmap. For example:

BIMicon_Wood_Pine Clear Varnished.jpg

The naming scheme is a very flexible one, and it can encompass a huge range of objects and properties. In the unlikely event that it ends up short and special cases arise, the organization can tailor this one to adapt to their needs.

* The reason why we should start using the space character in naming systems

There was a long long time ago when Unix and Windows systems couldn’t handle spaces in filenames because commands were delimited by spaces. This is not the case anymore. Just google if there is any strong reason to avoid spaces in modern operating systems and you won’t find anything else beyond the command line excuse. For example, check Quora.

As humans, spaces in writing is more than natural, is an essential part of the way we read and represent ideas and concepts. Moreover, the space limitation is completely related to programming, so we need to claim back what is natural for us, humans.

A computer is a tool invented by human beings for use by human beings. The computer should adapt itself to the needs of the person. A file name is a descriptive label. Putting spaces in descriptive labels is a natural, reasonable thing to do.

Franklin Veaux in Quora

As a programmer, I adopt the conventions established by programmers. Inside a program, I am all in to respect and follow camelCase conventions, PIP 8 rules and no spaces at all for variables naming. I would even follow the syntax rules that don’t make sense in natural language, because inside that environment, not abiding by those rules mean that the software won’t work.

But outside that world, as an architect, I use natural language. I don’t want my filenames, properties, folders to be named in camelCase. I want clarity for my construction field colleagues who may never do programming and don’t care about names as long as they are clear and legible.