I recently attended the buildingSMART International Summit in Watford. At the event there was a short presentation about standard naming for BIM objects. Object naming in the UK is covered by BS 8541-1:2012. Now I have to confess that I hadn’t looked at BS 8541-1 for awhile. So on the train home from the event I dug it out again and had another read.
I’m not going to go into the full detail of the standard as readers can read it for themselves. As a high level overview, the object naming in BS 8541-1 sets out 2 ways of naming objects. The 2 options are covered in 4.3.2 and 4.3.3. Both set out how an object name can be constructed and both have consistent rules about what characters are not acceptable. But the more fundamental question that arises from standard object naming for BIM objects is why?
Image: BS 8541-1:2012 Library objects for architecture, engineering and construction
Object naming or COBie Type naming?
On the face of it standard object naming appears to be a good idea. However it is more complex than this. There is an assumption from some that object naming populates the Name field on the Type sheet of COBie. Now whilst this could be the case it is not the only way to complete this field. This is where I believe that the standard we should be determining is not in fact an object standard but a Type naming standard. The Type name is the output and the deliverable but how you get to that can be done in a number of ways. Of course it could be solely driven by the object name but equally it could be driven by other data to form a concatenated consistent output.
If Object Naming is the same as Type Naming in COBie then i’m not convinced that it will be enough to provide uniqueness. The COBie Type Name field is required to provide a line for each Type within the model. The example in BS 8541-1 (for option 1) shows NBL_LightFixture_CeilingPendant. But what if we have Ceiling Pendants with 10 different sizes? How does the standard create the uniqueness required? I’m not convinced it does therefore I can’t see how it can be used for COBie.
However, on Page 9 of BS 8541-1 there is an example of data completed in the COBie Type sheet. The example shows the Name field as MyCompany MC999 Basin 470w x 300d. This is non-compliant with BS 8541-1 if the Type field is the same as the BIM object name as it contains spaces and no type information. So from my point of view they are not the same thing and object naming has nothing to do with COBie.
NBS BIM Object Standard
Image: NBS BIM Object Standard
The NBS BIM Object Standard also contains a field for the object name (BIMObjectName). This field could be the object name (we have automatically mapped this so there is no manual input) or again could be completed by concatenating data to form the name. It should be noted that this is duplication of information in a typical IFC file anyway so i’m not convinced this field is even really needed. But again I would ask who really needs this information? Is it going to be used or reused by anyone or is it merely an internal field for the use of NBS? Also if there is an assumption that the Type name is the object name then we have duplication of data. That is just waste in the process which is something we are trying to remove from the industry. Again I think all we need is consistent Type Naming.
Reusing object names
One of the primary reasons for advocating standard object names is the ability to reuse the objects in other authoring software. This is flawed in my opinion as the objects themselves are not usable so naming (i’m not going into this process here, thats one for another day) is going to do little to help. We should also remember that objects are only referenced into other discipline models so it is highly unlikely a Structural or Services Engineer would want to reuse our windows! Until parametric IFC objects arrive on the scene then object naming for reuse is largely pointless in my (current) opinion.
Now from the above you would think that I am suggesting object naming is not important. I’m not. I still think there needs to be some consistency about how we name objects. However it only needs to follow some very simple rules. This should cover two things in my opinion.
The first is that the name should describe what the object is. If its a Chair it shouldn’t for example just be called Object_01. Users need ways of finding these objects so sensible naming is obviously required.
Secondly a list of characters that shouldn’t be used is required for object names. The list in BS 8541-1 is fine for this purpose as most of this is common sense.
Image: An out-of-the-box Graphisoft ARCHICAD 18 object. How should this object be named given the 5 configurations of bar stool are created from one object? (note: the configuration options are effectively infinite). For the record its called ‘Bar Stool 18’.
One of the components of object naming that I don’t understand is that the standard allows the use of CamelCase or underscores as separators. The fact there is a choice introduces inconsistency. Can we please settle on one.
But again how these objects are named in an authoring tool is not necessarily important. What is important is how a standard consistency is carried on the way in and the way out of the software. So for example a company could have a library of objects with spaces in their object names. This would not comply with BS 8541-1 but software could easily be adapted to remove these spaces at the point of export. It could also remove unacceptable characters on export. We are talking about a consistent input and output not what goes on in an authoring tool.
But in very simplistic terms, object naming just needs to apply a bit of common sense!
Image: Generic BIM objects in Graphisoft ARCHICAD 18
A way forward
So for me object naming standards should be rewritten and standard Type naming defined. I also think it desperately needs to be an international standard. The authoring tools can then be adapted to suit that standard. This will provide consistent high quality outputs from and to all authoring tools. We would all be aiming at the same input and output and it would allow more consistent validation to be performed.
Type naming could also cover how Type naming for elements is determined. Not everything in the Type name field comes from an object. Walls, Ceilings, and Footings for example are formed using tools that are not objects. These use different data, such as Materials, rather than object names. Trying to apply object naming to these elements leads to long and confusing naming within the authoring tools.
For Type Naming I believe the naming could be kept relatively simple with a series of rules based on different configurations. I don’t believe objects names need to try and cover very much as the meta data can carry more information. The aim is to make it identifiable to a user and no more.
So focussing on standardising COBie Type Name and Component Description formats would create more consistent outputs to be used by others including Cost Consultants, Contractors and Facilities Managers. If object names end up forming part of these standards then they will drive how objects are ultimately named but we should focus on the end output not on the input.
Rob Jackson, Associate Director, Bond Bryan Architects