IFC has its detractors, but Simon Dilhas (aka the BIM Pirate) at Abstract explains that the schema is a digital treasure map that can lead you to clarity and collaboration across teams.
The Industry Foundation Class (IFC) has been unfairly criticised, with its actual value often overlooked. While some focus on its flaws, particularly the STEP file format, they miss the broader significance of IFC as a schema and ontology. Here, I’ll show you that IFC is more than just a file format. It’s a unique digital treasure map, a software-agnostic way of structuring projects and ensuring clarity and collaboration across teams. I’ll demonstrate this by explaining the big why and introducing the essential IFC concepts, empowering you to use this standard effectively in your projects.
Imagine an architectural office where every project has a set of color-coded physical folders. Each folder represents a category of information: the first holds project details, the second contains site data, the third covers buildings, and so on. The colour coding makes it easy to spot missing folders – and, therefore, missing information – at a glance.
IFC works the same way but for the digital age. It provides a structured approach to organising information within a single office and across multiple companies. Almost every piece of information has its place. It even uses the IDS language to find missing information quickly.
“IFC provides a structured approach to organising information within a single office and across multiple companies. Almost every piece of information has its place.”
A shared digital standard is crucial in the AEC industry, where projects are always collaborative and involve several companies using different tools. With most AEC companies being SMEs, having a standardised way to store, share and retrieve project data is essential for efficiency gains. By adopting IFC, we establish a shared language for communication, not only on a human-to-human basis, but also on a human-to-machine and machine-to-machine level. This standardisation, facilitated by IFC, ensures information is accessible.
When trains replaced horse-drawn coaches, it was no longer sufficient for each village to display roughly the same time on its church clock. Railway companies needed a standardised time to maintain and communicate schedules – thus, Greenwich Mean Time was introduced. To stretch the analogy further, standardising time did not do away with different types of watches (the different serialisations of IFC) it was an enabler that drove watchmaking – as IFC drove and drives the development of never-before-seen software solutions.
Similarly, a shared standard is essential to ensure communication and understanding, not only mere data exchange, of different tools as the AEC industry embarks on the digital journey.
IFC in the machine learning age
We can start asking the computer questions about the project. The only prerequisite is that the information is stored in a machine-readable and structured manner. And we can query in natural language using a large language model (LLM). Therefore, the question arises: is a strict schema still necessary?
First, data ambiguity can lead to costly errors. IFC’s schema ensures data is unambiguous, unlike LLMs, which operate probabilistically.
Second, the economic and ecological impact of relying on LLMs is unsustainable. Querying a structured database consumes significantly less energy than running an LLM.
Third, a common ontology cannot replace machine learning – it enables it. Standardised schemas provide the structure and consistency machine learning models require for training and interpretation.
While LLMs are potent tools for interacting with and augmenting structured data, they work best as a complement to, not a replacement for, the reliability of strict schemas.
The IFC schema comes in different versions: IFC2x3, IFC4.0 and IFC4.3. It comprises roughly 1,400 entities, each representing a fundamental building block in the digital representation of construction and project data. These entities mirror how we structure projects mentally, making them intuitive for industry professionals once we overcome the strange IFC in front of the word, as well as, often, the language barrier. For example, IfcWall represents a wall, an IfcDoor a door, etc.
Each entity comes with a set of core attributes:
- GUID (globally unique identifier) – this ensures every entity is uniquely identifiable across projects and platforms.
- Name – a human-readable label for easier reference.
- Description – additional context.
- Predefined Type – specifies the entity’s subtype, such as whether a window is a “Single Panel”, “Double Panel Window with a Vertical configuration”, etc.
Entities also have geometry to define their physical form and relationships to other entities, creating connections. For instance, an IfcWall might belong to an IfcBuildingStorey and an IfcClassification, e.g. OmniClass.
In addition to attributes and relationships, entities can also hold properties. The most significant and widely used properties are grouped into Common Property Sets (Psets). The naming convention is Pset*Common, with the * replaced by the entity name. For example:
- Pset_WallCommon for walls
- Pset_DoorCommon for doors
“Understanding the ‘why, how, and what’ behind digital standards like IFC helps eliminate inefficient, error-prone document-based workflows and enables collaboration.”
These property sets bundle critical information like status, fire rating, thermal performance, load-bearing capacity and more.
While the IFC schema includes thousands of entities, only a handful are critical for specific roles. For architects, the most relevant entities include IfcProject, IfcSite, IfcBuilding, IfcStorey, IfcSpace, IfcWall, IfcDoor, IfcWindow and IfcSlab. By filtering the schema down for different roles, we avoid overwhelming users!
Digital treasure
Becoming an architect, engineer or construction worker has always required learning a common language: plan graphics. While regional variations exist – for example, a concrete wall in Switzerland uses a crossed hatch, while in Germany, it’s represented with a dash-dot pattern – the foundational principles make adapting to these “dialects” straightforward.
As the industry sails the stormy digital seas, mastering the basics of this common language is critical. Understanding the “why, how, and what” behind digital standards like IFC helps eliminate inefficient, error-prone document-based workflows and enables collaboration. No single company is in a position to push its solution as a standard – although some try and would like to.
That said, the shift to digital standards has its challenges. One of the critical issues with IFC schema is that its descriptions and implementation are often overly technical. For non-technical users, it’s very hard to approach. This complexity creates a barrier to adoption, much like a hard-to-decipher treasure map. Articles like this act as a compass, guiding you to the treasure of efficient, collaborative digital workflows, making the new digital language of construction accessible to everyone in the industry.
Simon Dilhas portrait photo: Olivia Pulve.
Don’t miss out on BIM and digital construction news: sign up to receive the BIMplus newsletter.
