openBIM is an approach to digital built-asset information that favors open standards, transparent exchange, and collaboration across different software tools and organizations. It is not a single file type and it is not a single product. It is a way of making information usable beyond one vendor, one discipline, or one project phase.
The main idea is control of information. A project team should be able to create, exchange, check, discuss, and reuse built-asset information without forcing every participant into the same proprietary environment. That matters because built assets are designed, built, maintained, refurbished, and operated by many parties over many years.
buildingSMART describes openBIM as a way to enable data sharing and collaboration across platforms and stakeholders. In practice, openBIM depends on agreed standards, clear exchange purposes, consistent terminology, and a disciplined information process. The standards do not replace project management; they make project management less dependent on private file formats.
IFC means Industry Foundation Classes. It is the best-known openBIM standard and describes built-asset information in a vendor-neutral way. IFC is not only a file extension. It is primarily a data schema: a structured way to describe objects, properties, relationships, classifications, systems, spaces, processes, resources, and other built-environment concepts.
An IFC exchange may appear as an IFC file, but the file is only one way of serializing the IFC data. The important point is that IFC gives different tools a common language for model information. A design authoring tool, coordination viewer, checking tool, analysis tool, asset system, or archive can use IFC for a specific information exchange.
IFC is powerful, but it is not magic. An IFC export should be prepared for a purpose. A model for design coordination may not contain the same information as a model for energy analysis, quantity support, construction planning, or asset handover. If the exchange purpose is unclear, the IFC may be technically valid but practically disappointing.
As of 27 September 2026, buildingSMART lists IFC 4.3.2.0, commonly referred to as IFC 4.3, as the latest official IFC version and lists IFC 4.4 and IFC 5 as under development. This version detail is reviewed once a month because standards pages and implementation guidance can change.
BCF means BIM Collaboration Format. BCF is for model-based communication about issues, topics, comments, viewpoints, and coordination matters. It helps teams discuss a problem in context without sending a full model every time.
A BCF topic can point to a model location, selected elements, a viewpoint, snapshots, comments, assignments, status, and other issue metadata. That makes it useful for clashes, design queries, quality observations, change questions, review comments, and coordination decisions.
BCF is not the same as IFC. IFC exchanges model information. BCF exchanges issue communication around model information. The two often work together: the model is exchanged or viewed through IFC, while issues about that model are exchanged through BCF.
BCF can be used through file-based exchange or through a web service/API workflow. In modern coordination, the API approach is often more practical because issue status, comments, assignments, and resolution history can stay synchronized in a shared issue environment.
IDS means Information Delivery Specification. IDS is a buildingSMART standard for defining information requirements in a computer-interpretable form. In plain language, IDS lets a team specify what data should be present in an IFC model and then check whether the model satisfies that specification.
An IDS can require certain objects, classifications, properties, values, materials, or relationships. For example, a project may require doors to carry fire rating information, spaces to have classification codes, or selected equipment to include maintainable asset data. The value of IDS is that the requirement can be checked automatically instead of only being described in a PDF or spreadsheet.
IDS is closely tied to IFC. buildingSMART describes IDS as a way to specify how objects, classifications, properties, and values should be delivered in an IFC model. IDS is especially useful when a client or lead appointed party wants clearer exchange requirements and repeatable validation.
As of 27 September 2026, buildingSMART describes IDS 1.0 as an approved final standard. This statement is reviewed once a month because software support, implementers agreements, and future IDS versions may evolve.
bSDD means buildingSMART Data Dictionary. It is a service for shared definitions of built-environment terms, classes, properties, allowed values, units, translations, and relationships. The point is semantic consistency: different people and tools should understand the same term in the same way.
bSDD is not a project file store and it is not a replacement for IFC. It is a shared vocabulary service. It can help teams choose consistent names and definitions for information requirements, properties, classifications, product data, and model checks.
The relationship between IDS and bSDD is especially important. IDS can define what information must be delivered. bSDD can provide consistent definitions for the terms used in that requirement. Together, they help reduce ambiguity in model data.
A simple openBIM workflow might look like this. The client defines information needs. The delivery team translates those needs into exchange requirements and, where useful, IDS checks. Model authors create information in their chosen tools. The team exchanges model data through IFC for specific purposes. Reviewers communicate model issues through BCF. Shared terms and properties are aligned through bSDD where suitable.
The workflow only works when the team agrees the purpose of each exchange. IFC should not be treated as a general dump of everything inside an authoring model. BCF should not become an unmanaged message archive. IDS should not be introduced only at the end when the model is already difficult to correct. bSDD should not be used as decoration; it should support agreed terminology.
A useful way to remember the difference is this: IFC carries structured model and asset information, BCF carries model-based issues and communication, IDS defines and checks information requirements, and bSDD helps define the terms used in the information. openBIM is the wider principle that connects them.
There are common misconceptions. One is that using IFC automatically means openBIM success. It does not. A poor export, unclear exchange purpose, missing properties, wrong coordinate setup, or weak acceptance process can still fail. Another misconception is that openBIM means avoiding native files entirely. Many projects still use native files for authoring and open standards for agreed exchanges, checking, coordination, archive, and handover.
Another misconception is that open standards remove the need for a CDE or information governance. In reality, open standards make governance more important. Teams still need to know which file is current, what status it has, who accepted it, what issue remains open, which requirement it satisfies, and what information was delivered at each milestone.
For project teams, the practical question is not which acronym sounds modern. The practical question is what problem each standard solves. IFC helps exchange model data. BCF helps discuss model issues. IDS helps define and test requirements. bSDD helps align meaning. A BEP or information management plan should say when each one is used.
A workspace platform can support openBIM-adjacent work by keeping records, issue decisions, delivery dates, responsibility registers, review tasks, and handover evidence organized around the model exchange process. The platform does not need to author the model to support the information trail around it.
Useful references: buildingSMART openBIM ↗, buildingSMART IFC ↗, buildingSMART BCF ↗, buildingSMART IDS ↗, buildingSMART bSDD ↗.
Related: What Is BIM?, BIM Execution Plan, Model Coordination and Clash Detection, Information Requirements in BIM.