BIM object standard naming?


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?

Screen Shot 2015-03-28 at 15.41.42

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.

Object Naming

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.

Screen Shot 2015-04-13 at 13.20.22

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!

Screen Shot 2015-03-28 at 15.31.56

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


9 thoughts on “BIM object standard naming?

  1. I’m not sure I follow your argument. Components (objects) have a name, and there may be multiple types within that componet. Object name= TableSquare, types=1200×600, 1800×900, 1800×1200 etc.
    Therefore you need both object name and type name.
    That is how it works in Revit anyway.
    But I agree. We shouldn’t be forced to use any system that makes the work we are responsible for more difficult and error prone.
    The problem they are trying to solve is a Unique identifier. I don’t know why they don’t get into the 21st Century and use GUIDs.

    • Hi Antony,

      Thanks for the comments.

      Revit and ArchiCAD work very differently and this is part of my point. Maybe I didn’t explain it clearly enough.

      I’ll use your language to explain to hopefully make it a little clearer (its confused by how different software uses language). The main difference is we don’t have Types within an object. We have the Object (TableSquare) which we can then configure and place in the model. We don’t have defined sizes for the TableSquare. The object is a TableSquare which then allows the user to put any size values (or other values) for that table. The table can be placed and then changed again in the instance that has been placed. So we can stretch objects to whatever sizes we want and configure things like the colour of the table or detail. We can change the geometry freely in any view including schedules. By doing this we have greater freedom to define geometry. To offset this flexibility we can then map the geometry information to any field within IFC or COBie. This allows us to create a Component Description, Type Name and Type Description. So for example I can map the ObjectName-LxW which gives me the Type Name and the Component Description. So basically the user doesn’t need to worry about setting up geometry before they place it.


      • Hi Rob

        Us Revit users can also create objects (families in Revit speak) that do not have any built in Types, but instead have any or all parameters set as instance values. While this does allow greater freedom in creation of objects, it does lead to a proliferation of non standard sized objects in a project, which may not actually be available as real life products. For this reason I prefer to reserve the use of instance parameters to site measured / cut items, such as built in shelving, and name the type accordingly: Varx300x1500. The cobie Type parameter could be completed by concatenation with the object name, substituting the Var for the actual instance length: A-FRN-Shelf-2100x300x1500. Sadly it’s not easy to do this direct in Revit, so we rely on plugins such as BIMLink to export to excel, concatenate data and reimport to Revit, before outputting to IFC.

        • Thanks David. Your comments are useful to help me understand the Revit approach a little better. ArchiCAD is essentially totally based on instance values, although some objects have locked values. These rarely get used because we only model generic content and users don’t like to feel constrained! (I totally get where you are coming from with the need to use real dimensions but we have good users who understand both design and production requirements). We do use a function in ArchiCAD called ‘Favourites’ which allows us to preconfigure objects. e.g. we have favourites for set door structural openings. These can be altered as well but it does mean the user has to make a conscious decision to change.

          I appreciate some tools don’t do things easily. I think my point was the BS 8541 is that we couldn’t achieve it even if we tried. I think focussing on the output would allow all software companies to refine their approaches. All tools have their strengths and weaknesses but they will all evolve to customer need. From my own experience Graphisoft are very receptive to amending the software where international/national standards require it.

      • Hi Rob,
        A little late with my comment and slightly off topic but how does a manufacturer ensure their objects are used without manipulation essentially creating a bespoke product? that is one benefit of a a ‘Type’ family in Revit, You can lock out those parameters so they cannot be altered.

        • Hi Nathan.

          With my architect hat on we don’t use manufacturer content and if we do we would strip the data so the object is a generic representation of a product. If you lock your data we are more likely not to use it all.


  2. I have been confused about this (and not even working in UK legal context). Maybe I’m missing the point, but as an ARCHICAD user myself, I don’t see much use in re-naming the generic library objects of ARCHICAD. The door “D01 19” is the original Graphisoft GDL object which should stay as-is, as this gets updated with the internal library. Why would I rename it? What benefit does that bring? Now I could use the object ID field to add a custom “name” which is being transferred in IFC. Is this sufficient? Or does the application of BS 8541 actually demand you to rename the actual objects?

    Is this common practice to start projects with full custom object libraries? What a complete waste of efforts, if you ask me. An office chair may be “Chair 01” and parametrically adapted to look more or less like the actual chair during design. Within the object properties, you may be able to add an actual brand and type/model name or ID, if needed. Wouldn’t that suffice?

    It does seem to make sense for custom content. Is this mostly when replacing generic content with actual content (e.g. LOD 400/500 as-built elements?) – although then the manufacturers who would be responsible to create that content will need to be flexible when their content is used in different countries, as they may need to adopt naming, properties etc…

  3. Bs8541 is about template/generic/manufacturer construction library objects. There is one method advocated for objects, and a respectful nod to past symbol naming “where (parameters such as) classification are not available”.

    So the standard is about (cobie) type. Perhaps your ten different luminaires are best managed together? Component parameters can characterise individual instances.

    And parametric ifc does exist. Ask your vendor when they will support it in and out.

    And if there is a mistake in the cobie example , sorry and thanks for pointing it out.

Leave a Reply

Your email address will not be published. Required fields are marked *

one + fourteen =