Understanding BIM in the UK Part 2: Changes in the UK Naming Convention and The UK Annex

On the surface, the recent changes implemented by UK BIM Alliance may not look like much has changed, but that is far from the case.

We’re going to go through the naming convention now and try to better understand what the changes are and how they affect your team. At first glance, the naming convention in the UK annex of ISO 19650 looks very similar to the old BS1192 naming convention. It splits down into its various parts and a lot of them look to be the same.

It starts with a project and has an originator, that's the same. However, instead of volume and system, it has functional breakdown, and instead of level in location, it has spatial breakdown. Instead of type it has form, which is the type of information contained in a file that's been uploaded. Then, instead of role, it has discipline. Again, seems very similar but it ends up with no identical factors. At first glance, it looks as though not a lot has changed and that we're dealing with the same beast, in reality, that's not the case.

What it does say is that the identifiers for each part should be fixed within the project's information standard, hopefully by the client in the ISO, possibly by the assumption that the client always knows what they're doing, which isn't always going to be the case.

Nevertheless, the standard says this should be defined by the employer within the information standard and then rolled out. That means that on a project basis, or hopefully if you're a repeat client across all that client's projects, there will be a naming convention which is applicable. It's the variation where I think where I think that there is a missed opportunity here, but I will discuss this in the next part of this series.

There were some optional portions of the previous naming convention which could be added in and they were classification status and revision. Those sections I've just discussed could be expanded to include those now under ISO 19650. However, whereas those fields were optional, although most would always have captured status and revision within the CDE (common data environment), they are no longer optional. You must fill in classification and stats and revision. The standard says that any item downloaded from your CDE should have those fields added to the end of the naming convention.

Personally, I think that's a really good thing. In particular, I think that having classification as a compulsory field is a good thing. The first field is a project and this is a designation to be used by everybody working on the project. It then becomes everybody’s call throughout the project and it's initiated by the client.

The next section is form. What this is referring to is what is the form of the uploaded information container, whether it’s a model, video, or even a text file. Previously, we knew if it was a file, note or minutes because there were more designations. To accommodate this, the standard says that if you need to, you can expand these with project specific codes, which can extend the standard closure of the digital characters. A suffix is fine, but I would suggest that the bulk of people are going to want to know whether a uploaded model is a 3D representation, a 2D model, or a flat auto CAD file or a 3D Revit file.

The issue is, I think the bulk of people are going to want to know those additional bits of information. I also think codes are going to be expanded and I think people are going to want to expand them. It's good that we are saying you have to document how you want things labelled, but I don't think this constitutes a naming convention.

The industry is beginning to settle around a name for an information container file. I would suggest if you are a large tier-one contractor working on multiple projects, it's useful to be able to do metadata searches to extract the data and information about deliverable types across projects. The only way to do that is by having enough regularity in the way that you retrieve all of these particular types of schedules. If these are defined project by project, you're losing that ability.

The last section of the naming convention is EIR (Exchange Information Requirements) which is very similar to what it used to be. This is where all parties involved agree on how to transfer project data, what this looks like for each team, and in what format this should be shared. Whereas you previously might’ve said architect, you now say architecture, etc. But essentially this hasn't changed — it will still be a short list. The standard says that this list may be expanded with two character projects, specific codes. I would then argue that using this expansion further splinters the ability to search by metadata.

However, in the next blog, we’ll explore how Uniclass 2015 can be used to bring more standardisation across projects when used alongside ISO 19650.