Tug of war in reality
As an international standard, the core value of IFC lies in consistency. Only with consistency across environments, we can achieve true data interoperability. Regardless of country, region, industry, or software—data should flow freely.
But here’s the thing: different countries follow different building codes and methods of working. Industries may describe the same concept in entirely different ways. Even within the same company or project, people may interpret the same thing very differently.
That’s why we often hear two seemingly contradictory complaints:
- Some say “IFC is too complex”—there are thousands of entities and properties, while their project only needs the basics. They want a simpler way to express data.
- But more often, people says “IFC isn’t enough”—it doesn’t cover what they need because their project has unique definitions that aren’t reflected in the standard.
We want IFC to be stable, strict and reliable in its consistency, yet also flexible and adaptable.
We want it to be both simple and minimal, yet also able to serve a wide range of specialized needs.
It’s a constant tug of war.
Back to basics: F stands for Foundation
Standards are shared foundations, not tailor-made solutions for specific individuals or projects.
The “F” in IFC (Industry Foundation Classes) stands for Foundation. IFC isn’t designed to serve just one company or one situation, it represents a shared agreement, formed by the industry to enable openness and neutrality. To support interoperability, the standard must be broadly applicable.
You won’t find highly specific classes like IfcOffice or IfcRestaurant in IFC. Regardless of purpose, spaces are represented as IfcSpace, because names and classifications vary across cultures, regions, and projects.
Take a cinema for example, should it be labeled as a Multimedia Area, Entertainment Area, or simply part of a Commercial Area? The classification depends entirely on local context.
And yet, what a “space” is doesn’t change. It’s defined by area or volume, with boundaries. And common descriptors remain the same: is it indoor or outdoor? Is it public? Is it accessible? These basic facts don’t change based on culture or location.
That’s what IFC focuses on: foundational semantics. It gives us the stable core.
But how do we adapt to diversity across environments? That’s where the data dictionary comes in.
Data Dictionaries: Born for Semantics
Data dictionaries were created to solve exactly this problem—the complexity of semantic variation. They provide:
Precise Semantic Expression
A data dictionary offers a structured semantic framework. You can define classes, properties, units, allowed values, include descriptions, examples, and relationships. Every element is uniquely identified and versioned.
Multilingual and Cross-Cultural Collaboration
Terminology and translation are common sources of confusion. With multilingual support in data dictionaries, you don’t have to worry about naming conflicts or misinterpretations across languages. Localization and global collaboration no longer contradict each other.
Domain Adaptation and Ecosystem Growth
Specialized industries like airports, railways, tunnels or hospitals, they can create their own extensions. Countries can develop localized dictionaries tailored to their specific regulatory and cultural contexts. These extensions can coexist, and even reference each other, avoiding redundant reinvention while enabling collaborative growth.
Data dictionaries act like bridges—connecting different sources, needs, and perspectives within a coherent system. It doesn’t force everything into one mold. Instead, it embraces diversity, as long as each “difference” is clearly defined and traceable.
It’s not an ultimate solution to all semantic problems, but it offers something crucial: a way to build shared understanding across varied contexts.
The Semantic Partner of IFC
So how do IFC and data dictionaries work together?
Think of it this way:
- IFC provides the grammar—a consistent structure and syntax with fundamental vocabulary.
- The data dictionary is an extendable semantic library—giving meaning to each “word,” including units, constraints, translations, and relationships.
IFC offers a standardized backbone. The data dictionary builds on top of it to create a richer, more adaptable ecosystem.
Most importantly: this extension is compatible. It doesn’t break the consistency of IFC. Instead, it enhances its expressiveness. You can rely on IFC’s core framework, and use the dictionary to express localized, project-specific semantics.
Take an example: we defined a space in the model, it’s an IfcSpace in IFC. But we want to express that this space is an Office Area, with custom properties like number of workstations or whether it has a meeting room.
That’s where the data dictionary comes in. We could define a new Office Area concept and its properties in a data dictionary. Then, we reference this concept in the IFC model using IfcClassificationReference.
Software still reads it as a space, because the base definition hasn’t changed. But now it also understands its additional semantic meaning, and can even retrieve the full definition via URI.
This is the ideal balance: Stable structure + Open semantics. Data dictionary serves as a semantic extension, connecting IFC’s consistency with real-world diversity.
So... Is IFC Really “Not Enough”?
Let’s return to the question: when people say “IFC isn’t enough,” do they mean it's not enough to support data exchange?
Most of the time, nope.
It’s not that IFC can’t handle data exchange—it’s that it doesn’t express the specific semantics of a unique context or project. In other words, “IFC doesn’t have the special definition for my specific use case.”
What we are looking for is not to redefine basic concepts like “unit,” “property,” or “material” from scratch, we’re simply trying to express additional, customized meanings on top of those foundations.
So, do you need to change the standard for every use cases? No, you just need to create your semantic entries.
Think of it like a natural language: when new things emerge, we invent new words—we don’t invent a whole new language.
And where do we find or store those words? You definitely knows that—in the dictionary.
In Summary
When you feel limited in how you can express meaning in your model, here’s what you can do:
- Check the IFC documentation to see if the core class or concept already exists.
- Look up a relevant data dictionary, either industry-specific, regional, or create your own using services like bSDD.
- Attach semantics to your model using IfcClassificationReference.
Voilà! Your data now has both standard structure and custom semantics. Ready for both collaboration and context.
Of course, IFC isn’t perfect. It still has gaps. Especially in niche domains like maritime engineering, power facilities, or hydraulic dams. But remember, IFC is an open standard. You’re always welcome to reach out buildingSMART and work with the community to push the boundaries of openBIM.