Naming Omnibus

Hello BIMfans,
While developing my information model, ‘naming’ has easily given me the most pause for thought.  While I have already discussed some naming conventions in previous posts, I have decided to put everything here.  The rule is simple, I will only use a naming convention if it can be found in a British, European (#Remain), or International Standard.

NOTE:  If I have missed out any naming conventions, feel free to leave a comment and I will add it to the post and credit you as thanks!

NOTE:  To save repeating myself, any fields with an asterisk* are optional fields.

Naming
Fun fact:  BIM is worth eight points in Scrabble.

So, let’s see what naming conventions I have found.  For ease of navigation, I have structured this post as follows:

  • Directory naming
  • File naming
  • View and symbol naming
  • Layer naming
  • Object naming
  • Type and component naming
  • Level naming
  • Space naming
  • Property and attribute naming
  • Title block naming
  • Text naming
  • Line naming

Directory Naming

The naming of directories and folders can be found within BS 1192, which is as follows:

Directory and Folders:  <Project>-<Status*>-<Revision*> e.g 7001-CR-C01

This naming convention has already been applied to my directory within Autodesk’s A360 which I use to host the graphical models I share on this blog.  However, as I am not operating a full project its implementation here is limited.  Note:  It does allow sub-directories with names based on the file naming convention discussed below.  However, I consider this a waste of time.  Why have a folder called ‘Models’ or ‘Architect’ when it is written in the file name?

Folders
Hint:  Optional means don’t bother…

 

File Naming

The naming of Files (Probably the second most contentious naming convention behind Boaty McBoatface) can also be found within BS 1192, which is as follows:

Files:  <Project>-<Origin>-<Volume>-<Level>-<FileType>-<Role>-<Class*>-<Number>

This naming convention has already been applied to several files that I have been sharing over this blog via Autodesk’s A360.   You’ll notice that my native files use ‘M3’ and my IFC files use ‘MR’ as they are renditions out of their respective native models.

 

Models
Looks at those tiny file sizes!!

 

View and Symbol Naming

The naming of containers within files, such as views and symbols can also be found within BS 1192, which is as follows:

Containers within Files:  <Role>-<Class>-<Presentation>_<Description*>

This naming convention has already been applied to most of my views and some symbols within my graphical models.

SymbolsViews.png
Yes, that is exactly what my North Point needed; Uniclass2015!

 

Layer Naming

The naming of views and symbols above is based on ISO 13567-2, which covers the naming convention for layers.

Layers:  <Agent(Role)><Element><Presentation><Status*><Sector*><Phase*><Projection*><Description*>

A key difference is that ISO 13567-2 uses a fixed field system.  Meaning that there is no need to use a field separator. Instead, hyphens are used as a ‘general’ symbol and underscores as ‘not used’.  Due to issues with Uniclass 2015 that I have expressed a concern over, I haven’t implemented this yet.  However, an example layer would look something like this:

A-2530__–DoorsAndWindows

Object Naming

The naming of objects can be found within BS 8541-1, which is as follows:

Objects:  <Source>_<Type>_<Subtype>

This naming convention has already been applied to my objects when I first considered Object Naming and has been applied to objects such as my Nest Thermostat, and Google Home.  Now there are several opinions on how this naming needs to be implemented, I have taken the stance that it is for the naming of the object file (i.e. what you find when you search your computer), because type and component naming is covered in in another standard.

DoorNaming

 

Type and Component Naming

The naming of almost everything else can be found within ISO 4157-1, which defines how to name:  General designation codes, buildings, storeys, parts of storeys, floors, and load-bearing structural elements.

 

1vajbl
…using ISO 4157-1

The naming (referred to as designation in this standard) of types and components can be found within ISO 4157-1, it requires a primary and additional designator which I have used as follows:

  • Type:  <IfcType><Numerals in running order> e.g. DoorType01
  • Component: <IfcSubtype><numerals in running order> e.g Door01

This naming convention has already been applied to parts of my information model like my Door and Window Schedule Drawing which I produced when I discussed my Outstanding Openings.  However, further development work is needed to reflect this information correctly within COBie. This is because the USA’s National BIM Standard states that Component.Name should be consistent with the name that appears my schedules.  Meaning that each door in COBie should be named Door01, Door02… to suit what appears in my door schedule.

DoorSchedule

Level Naming

The numbering (referred to as designation in this standard) of floors can also be found within ISO 4157-1, which is simply a running number.  This (surprisingly) aligns well with the BS 1192 naming convention with specifies a two-digit sequential number for floor levels.

However, I have also chosen to name my floors, and have done so following the component naming listen above to get:  Floor 00, Floor 01, and Floor 02.  Note:  This is different from my storeys which are Storey 1, Storey 2, and Storey 3 respectively.

Elevations.PNG

Space Naming

The naming (referred to as designation) of rooms and spaces can be found within ISO 4157-2, which is as follows:

Rooms:  <Floor number><Numerals in running order> e.g. 101

This has already been applied to my information model and can be seen in both my graphical model and in my COBie files.  Easy.

COBieSpaces

Property and Attribute Naming

The naming of properties can be found within BS 8541-4, which requires the use of CamelCase (just like Hashtag writing #CamelCaseMakesItEasierToRead) and an indication of the data type expected.  For example, if you take a look at the properties I have used from my previous post on Classical Conditioning three properties were being focused on:

Pset_Condition
AssessmentDate, when the assessment was completed YYYY-MM-DD;
AssessmentDescription, qualiative description of the assessment; and
AssessmentCondition, the condition:  Very Poor, Poor, Adequate, Good, or AsNew.

By suffixing Assessment with ‘Date’, ‘Description’, or ‘Condition’, it suggests the data type that should be expected to populate each property.  Luckily for me, all the properties I have used are available in the IFC Schema.  However, if I ever found I was lacking, this convention is how I would create those additional properties.

 

Title block Naming

The naming (referred to as designation) of title blocks can be found ISO 5457, which is as follows:

Title blocks:  <Descr.>-<Standard>-<Size><Trimmed>-<Material>-<Side>-<Pattern*>

This has already been applied to my title blocks when I formed my original templates

Title Block.JPG

 

Text Naming

The naming (referred to as designation) of text styles can be found within ISO 3098-0, which is as follows:

Text Styles:  “Lettering ISO 3098-1” – <Type> <Spacing><Incline><Alphabet> – <Size>

This text style naming convention has now been applied to my graphical models. However, due to Revit’s vile terrible horrible improving text formatting capability, I have to include an additional field to indicate whether the text is bold, italic, or underlined as a suffix.

TextNaming_New

 

Line Naming

The naming (referred to as designation) of line styles can be found within ISO 128-20, which is as follows:

Line styles:  “LineISO128-20” – <Type> x <Width> / <Colour*>

However, Revit annoyingly unfortunately doesn’t allow you to rename system line styles. While I could recreate all my lines styles following this convention, I do not consider this worthwhile.  If/when I need to create specific line styles, those user-defined line styles will follow this naming convention.

Line_new

 

And there we have it.  By using a myriad of British, European, and International Standards, I have now laid out all of the naming conventions I am aware of and how they have been applied to the production of my information model.  This will help me align my information not only between models but also to the national and international communities; fantastic!

Operation and Maintenance
3.1 What are the sizes and condition of the windows & doors?
3.2 What assets are in a poor condition?
3.3 What costs can be attributed to my assets?
3.4 What are the most cost effective thermal improvements that could be undertaken?

Now that I have worked out all of my naming, I need to apply this so that I am ready to share my model to do some external cost exercises…

Update:  Following a Twitter Poll I have changed how my name my IFC files from M3 to MR.  Thank you, John Ford, for raising this question.

Update:  Text naming image updated following a clarification comment around how ISO 3098-0 naming can be applied within Revit.  Thank you, Nathan Beevers.

10 thoughts on “Naming Omnibus

  1. Would compliment the RIBA naming protocol nicely, I think. Thanks so much for sharing.

    Like

  2. RE: Text styles. The lettering designation in BS EN ISO 3098-1 shows no hyphen delimiter between and . As it is included in your string, I wonder if this necessary for Revit?

    Like

    • Hi Nathan. Well spotted.

      ISO 3098-1 doesn’t indicate the naming structure, only the required fields “the following elements in the following order”.

      I had chosen to use less spaces (I hate spaced in names!), but following this comment I have changed the image to show exactly as written in ISO 3098-1 to show it can be implemented exactly as shown.

      Like

  3. Dan

    … also, with regards implementing line styles standards in Revit: If I follow the BS designation standard, and include the width field would that mean all my model line weights would have to be a consistent width across the view scales?

    Like

    • Yes. As far as I can see, the most practical method is to align the line weights to 128-20 (manage > additional settings > line widths), and then just name the line style based on the weight assigned. If you do this then the line weight will stay consistent regardless of scale.

      Like

Leave a comment