3 Minute Read
April 12, 2022
In the previous blogs in this series (linked below), we discussed the huge improvement that is taking place around naming conventions in UK construction. The more detail we can get throughout a project’s lifecycle, the better.
Read our previous blogs:
However, I think a trick has been missed with ISO 19650. This blog will discuss standardising detail, and the role that Uniclass 2015 can play.
There are so many common designations that are going to have to be captured and which are being captured differently at the moment. I think it would have been really good to perhaps suggest that at least what these two character projects specific codes might be.
As I have previously mentioned, this opinion may seem a little controversial. On the one hand, I think it's great that we're being asked as part of our project to define what the numbering system is. On the other, I think this is going to mean that the naming convention will very definitely be a project-specific naming convention, not a naming convention that is applicable across the board.
Now, I think this leads to problems for a lot of the design and construction team. You will be inheriting ways of naming things which are highly personal to the project, which may not suit you or your ability to set things across.
One shortfall of the naming convention now becoming so fluid is that it then becomes difficult to search for items based upon it. In addition, the naming convention is very clearly set up just for the project's lifetime.
So for the OpEx period by the client or should be set up by the client and the information standard, and what the design and construction team inherit may not be what the types of things that they need to search for. In short, different teams are still referring to items in different ways.
The brilliant thing about having predetermined values for elements, equipment and so forth is that these remain unchanging across multiple projects that use Uniclass 2015. There are tables which deal with tools and equipment or the information roles product systems, elements, function spaces, locations activities, entities, complexes really the whole gamut of things that you might wish to designate things.
I think this would allow for example, a contractor to give a code to a package which isn't identified within the brickwork, for instance, which isn't identified within the naming convention or to a system.
There is a huge opportunity to use classification to fill in for what I see as the shortcomings of the naming convention as it currently stands. As these classifications can then be appended as metadata to any information content downloaded from the CDE, you are always going to be capturing this information.
If a contractor, for instance, wants to compare across most projects, a brickwork package is always going to be that set Uniclass 2015 code and searches can be based upon that.
I must reiterate that I think the naming convention has come such a long way in a relatively short period of time. However, too much fluidity when it comes to the detail within projects is a key shortcoming.
For teams that may work with several different clients, this then becomes a new way of working every time. If the aim is standardisation, there almost needs to be a compromise between niche detail and predetermined codes.
We’re getting ever closer to real standardisation, but we’re not there yet.
3 Minute Read
April 12, 2022