How does Uniclass support interoperability?
The classification of ‘things’ is integral to the successful delivery of interoperable data, allowing information to be organized and easily retrieved. To support the industry in assigning classification, NBS and the Government Industry Interoperability Group (GIIG) have undertaken an alignment exercise between Uniclass and IFC, reducing the need to work through a manual decision-making process and improving consistent selection within the industry.
Both Uniclass and IFC are referenced within BS EN ISO 19650-2 National Annex, with Uniclass used for classifying both information containers and their contents, and IFC used as an open data schema and format to support the exchange of graphical and non-graphical information. It is, therefore, important to understand where there is commonality across the two to form these relationships and ultimately complement each other in the information exchange process.
This article looks at the structure of both approaches which underpins this work to date.
Uniclass classification structure
Each classification code consists of two letters to identify which table is being used and then up to four sets of two-digit numbers, depending on the table. These number groupings, or levels, allow for increasingly detailed sets of items, starting with groups, then subgroups, sections, and object codes. Classifying to a particular level can vary according to the information available at a particular stage in the life cycle of an asset.
The granularity at object level is what makes Uniclass suitable for the purposes of classifying modelled objects and as ISO 12006-2 is the underpinning framework to the tables, relationships to other classifications following this standard becomes easier.
IFC classification structure
IFC Entities, not to be confused with Uniclass Entities (En), are the main objects/ nodes within its data model or schema. These can be found on the IFC2x3 website by clicking on the ‘Alphabetical listing’ link to the top left and selecting the ‘Entities’ link underneath. The list of applicable entities in the schema is then displayed at the bottom left. The product entities provide a basic classification for familiar items we use within construction, such as columns, boilers and walls.
For the purposes of establishing a greater level of granularity for products (Pr), we are concerned with all entities that contain the word ‘Type’ (or ‘Style’) after the entity name, such as ‘IfcBeamType’. International Standard ISO 19650-4 National Annex indicates the general equivalences between IFC and Uniclass Tables.
Note: within IFC 2x3 not all entities have a directly equivalent Type, and this is covered in the IFC Introduction blog series by Emma Hooper, Bond Bryan Digital Ltd. Within IFC4.3 RC4 there is always a direct relationship.
At this level, we can now see all the attributes related to a particular entity, and although there can be many relationships to additional information, the ‘PredefinedType’ attribute allows a value to be selected from a predefined list.
These values are referred to as enumerated values and give us the opportunity to specialize objects, thus giving us the ability be more granular. Clicking the ‘IfcEntityTypeEnum’ link will take you to the applicable list for selection.
Although it is important to understand the structure of the schema and the associated relationships, an alternative route to the predefined lists is to click through the ‘Alphabetical listing’ link, then ‘Enumerations’ and then the required predefined list.
Relationships
To join up Uniclass and IFC (where possible), the object codes for the Products (Pr) table have been aligned to their equivalent IFC predefined type(s).
These relationships have been added to the Uniclass website and are formatted with a point that separates the different levels of the IFC 2x3 TC1 schema, for example ‘IfcBeamType.LINTEL’ is referring to the entity ‘IfcBeamType’ and the predefined type ‘LINTEL’.
| Where to use Pr_20_85_48_15 | |
| COBie | Pr_20_85_48_15 : Concrete lintels |
| IFC 2x3 TC1 | IfcBeamType.LINTEL |
Uniclass uses simple terminology where possible, using everyday plain language and standard industry terms. Uniclass can therefore provide a tag to an IFC Entity allowing this information to be more easily retrieved.
However, a series of rules were identified which have been followed to manage more complex alignments.
|
Scenario |
Description |
|
1 |
The Uniclass title contains more than one IFC entity.
Pr_20_85_90_11 : Carbon steel lattice floor joists and purlins
NOTE: Such occurrences can inform a required update to the Uniclass tables.
Products v1.26, April 2022: Pr_20_85_90_10 Carbon steel lattice joists Pr_20_85_90_11 Carbon steel lattice purlins
|
|
2 |
Multiple IFC predefined types apply.
Pr_25_93_72_37 : Hardwood shingles
Some products can be installed in different scenarios, prompting a decision to be made from the narrowed down suggestions. |
|
3 |
The product is multi-functional. Pr_40_20_87_17 : Combined tap and hand dryers A decision needs to be made as to what is the primary function from the narrowed down suggestions.
|
|
4 |
Where there is no suitable IFC entity, IfcBuildingElementProxy.USERDEFINED is to be used.
NOTE: Within IFC4 ADD2 TC1 the entity IfcSolarDeviceType contains the PredefinedType ‘SOLARPANEL’. |
|
5 |
Where a predefined type could be applied but there is no suitable one within the enumerated list. IfcLampTypeEnum:
In these scenarios, USERDEFINED can be used and the additional value held within the IfcElementType or IfcObjectType attribute. NOTE: Within IFC4 ADD 2 TC1 the PredefinedType ‘LED’ is available.
|
|
6 |
Where a predefined type cannot be applied. Typically, this could occur at the early design stage where a particular type may not be known. Pr_20_76_51: Metal sections IfcMemberType.NOTDEFINED
NOTE: In this example the Uniclass classification has been used to section level (three sets of 2 digit codes).
|
|
7 |
Where there is no predefined type associated to an IFC entity i.e. no enumerated list.
NOTE: PredefinedTypes for the above entities are available in IFC4 ADD2 TC1.
|
Many alignment outcomes create one-to-many relationships, such as that described in Scenario 2. Providing a filtered set of possible outcomes allows the user to then make a decision based on the additional information they have.
Further information:
Find a Uniclass code: https://uniclass.thenbs.com/
Acknowledgements:
Chris Vickers, NBS
Emma Hooper, Bond Bryan Digital Ltd
Nick Nisbet, COBie & IFC Workstream Consultant for Government & Industry Interoperability Group.
