With previous new IFC versions there has been much celebration on how many new entities have been added and how large and comprehensive IFC now is (an astonishing 776 classes and counting).
But if it isn’t already, there is a serious danger of IFC becoming bloated.
Rather than extending, I think now is the right time to be talking about streamlining and modernising the fundamentals of the standard to improve the ease of implementation and accessibility into the future.
Here are some ideas based on practical usage experience.
Remove all property sets
Currently IFC is a schema (entities and attributes) and property sets. I believe IFC would be much stronger if it was schema only.
While a schema can be universally adopted across every project in the world, the properties can change completely depending on client requirements and project specific processes.
I would remove all predefined property sets (like Pset_SanitaryTerminalTypeCommon) because compared to the schema, they add relatively little value.
This would be a good first step to slimming down and focusing on the IFC schema.
Properties are very important, but should be handled by an entirely separate standard, such as the buildingSMART Data Dictionary.
Remove the ‘Ifc’ prefix from all entities
A simple one, but it is incredible how much more readable and clear the standard becomes once the ‘Ifc’ prefix is removed. A wall should be a Wall, not an IfcWall.
Clean up the inheritance tree
(The following are based on IFC4add2, but the same applies to most versions)
Microsoft advises that having classes with more than 4 levels of inheritance is bad design and “can be difficult to follow, understand, and maintain”.
The IFC specification has 353 classes that are 5 or more levels deep, of those an incredible 117 are 9 levels deep!
Having that many layers of abstraction is incredibly excessive. Just because some entities share attributes doesn’t mean a parent class should be created at the expense of readability.
As a start, Relationships can be removed from the main Rooted tree. A relationship does not really need a name, description, or owner history. It is debatable whether they even need a GlobalId.
I also don’t think anyone could convincingly argue that nearly 50 different classes are required to meaningfully represent relationships and remain easily implementable.
Remove IfcPropertySets from the rooted tree too and then IfcObject and IfcTypeObject can be the new top level entities. This reduces the maximum inheritance to 7, which is still extremely high!
A single IfcPropertySet class
The property set concept of a list of name-value pairs is very simple and highly universal. There’s no need for all the predefined sets, including quantity sets, and templates. I’m certain a single IfcPropertySet class would be sufficient for 99% of use cases and also does not need to inherit from Root.
Remove Base64 GlobalIds
It is for purely historical storage reasons that IFC uses GUIDs converted to Base64 using a unique character mapping scheme. The amount of space that it saves in the modern IT environment is nothing.
GlobalIds should now be in the standard Base16 format so that more existing software libraries can read, process, and create them, rather than requiring a custom algorithm.
Scrap the ISO10303 support
Currently there is an XSD and a ISO10303 EXPRESS schema definitions. Rather than continue with such an outdated and unsupported format, the EXPRESS schema should be scrapped with the focus on the XSD schema definition that is far easier to develop against. I’m aware that there are some aspects that can’t be specified in XSD, but if thousands of other formats can be specified using just XSD, then I don’t believe IFC is so special as to be an exception.
Because the STEP file format has relatively very few tools supporting it, IFC in XML format and zipped should be the only format recognised by buildingSMART.
A zipped XML file is the standard approach for all Open Office and Microsoft Office files and should be more than sufficient.
Summary
The aim of this blog post is to encourage people to consider streamlining the IFC standard to make it easier to use, understand, and implement by everyone.
These are just a few ideas to get things rolling, and I’ve not even mentioned issues like the complexity of interpreting IFC geometry and possible improvements to how it’s documented.
If you have any ideas please free to add them below.
Constructing Data 
“GUIDs are the sewing needles that tie the data together”. For models used for fabrication or construction (LOD400) such as rebar or steel it makes absolute sense, but I never understood how you could keep the thread alive across LOD’s as they are usually authored in different software or by different users so any data against the LOD300 GUID model is lost when the LOD400 model is produced. Maybe if you transfered GUIDS at conversion, the GUID ‘old GUID’ could be mapped during conversion from software to software, but often one object becomes many so don’t know how that would work in practice. Also for a LOD400 to LOD500, Imagine you have a widow in your model with all the history of installation and quality records. but the window that went in on site is a different one to what was modelled, so for the as built the a new window would be created and have a new GUID, which would need mapping back to the old one via a common name, . Summarised into a question.. How do you manage the golden thread across LOD versions? If the thread is based off a common name… lets say Window 1 (LOD300), Window 1(LOD400), Window 1(LOD500), Then the data can flow across the revisions based on ‘Window 1’..
I think you need both… GUIDS and common naming to achieve a golden thread.
LikeLiked by 1 person