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.
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
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?
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.
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.
The naming of views and symbols above is based on ISO 13567-2, which covers the naming convention for layers.
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:
The naming of objects can be found within BS 8541-1, which is as follows:
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.
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.
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.
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.
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.
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:
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
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.
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*>
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.
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.