Common Language of Interoperable Data
From Governance to Shared Data As presented in the previous article “The Contributors & Information Management, according to ISO 19650″, the structure of a BIM project relies on a rigorous organisation of roles and information flows. But this management can only be effective if the data exchanged between disciplines and tools retain consistent meaning and coherent structure.
That is precisely the purpose of this article, to understand how BIM is built on two complementary foundations: the exchange formats, which ensure the technical transmission of information from one software to another, and the classifications, which give them shared and lasting meaning. These two mechanisms lie at the heart of digital continuity: they transform a set of heterogeneous files into an interoperable, accessible and enduring knowledge base.
BIM Formats: a Grammar for Exchange and Continuity The idea of interoperability did not originate in the construction sector. It finds its roots in the manufacturing and aerospace industries, which, as early as the 1980s, faced the need to coordinate thousands of components, suppliers and software within the same digital process. The standardisation programmes STEP (Standard for the Exchange of Product Data) and PDES (Product Data Exchange Specification) enabled aerospace and automotive industries to move from 2D drawing to full digital product description. These industries learnt to design “objects” endowed with properties, behaviours and logical relationships, independent of the software used. It is this philosophy that inspired the BIM approach: transpose to the built asset the principles of the product digital model, by considering the building no longer as an assembly of drawings, but as a system of interconnected information. This systemic approach has profoundly transformed the design, construction and operation of assets. Interoperability has become a strategic as well as technical requirement: it guarantees the continuity of information, the traceability of decisions and especially the digital sovereignty of participants. A project should no longer depend on a software, a vendor or a proprietary format. Data now constitute an asset in their own right, on the same footing as the physical building. Preserving their accessibility and intelligibility over time is a major economic and heritage issue.
IFC From this philosophy was born the format IFC (Industry Foundation Classes), developed by the International Alliance for Interoperability (now buildingSMART International) in 1996. The IFC is today recognised as an international standard under ISO 16739-1. It constitutes the technical foundation of OpenBIM. Its principle is based on an object-oriented data model: each building entity (wall, window, slab, equipment, space) is described by a set of properties (materials, dimensions, performance) and by the relationships it maintains with other elements. Thus IFC does not limit itself to representing geometry: it models the interactions that give meaning to the building’s structure, thereby allowing a global and coherent understanding of the building, where each element is defined not only by its shape, but also by its function and its role in the overall construction system. Over the years, IFC has expanded: version IFC 4.3, finalised in 2023 and incorporated into ISO 16739-1:2024, now includes geolocation, linear infrastructure (roads, bridges, railways, pipelines) and linkage to Geographic Information Systems (GIS). This evolution marks a turning point: BIM leaves the scope of the isolated building to be inscribed in the urban continuum, up to City Information Modeling (CIM). IFC thus ensures a lasting interoperability between software, disciplines and scales, allowing a design model to be re-read ten years later, without depending on the original software. Its complexity constitutes its downside: its rich schema requires rigorous implementation, and differences of interpretation between publishers may generate information loss. These challenges explain the growing role of complementary formats and automatic validation standards.
COBie While IFC structures the full representation of the building, it does not directly meet the specific needs of operational management. During the transfer between construction and operations, a large part of the information was lost: technical sheets, warranties, maintenance plans, intervention histories. To fill this gap, the US Army Corps of Engineers launched in 2007 COBie (Construction-Operations Building information exchange). This tabular format aims to organise data useful for maintenance in a simple, readable language, exploitable by CMMS (Computerised Maintenance Management Systems). COBie does not constitute a parallel model to IFC, but a standardised extraction view of it, based on the Model View Definition (MVD) COBie. This view selects and reformats only the information necessary for operations — spaces, equipment, components, zones and systems — by translating them into structured tables. In other words, COBie is derived from the IFC model, from which it exploits the properties and relationships to produce a management-oriented file rather than a geometry-oriented one. Each line of a COBie file thus corresponds to an exploitable object (door, luminaire, air-handling unit) accompanied by its attributes: location, manufacturer, serial number, maintenance frequency, documentation. The issue is no longer modelling the form, but ensuring the completeness and reliability of the information transmitted to the operator. Integrated since 2022 into the ISO 19650-4 standard, COBie has become an essential contractual link. It embodies the digital continuity between design, construction and operations: what the builder constructs can be transmitted directly to the operator, without re-entry. Well configured and connected to the IFC model, COBie becomes an effective interface between BIM and CMMS, the first step towards the digital twin.
BCF In the early years of BIM, communication between teams often relied on email exchanges, screenshots or annotated models, leading to confusion and duplicates. The BCF (BIM Collaboration Format), launched by buildingSMART in 2009, brought an elegant solution: separate the discussion from the model. Each BCF issue is a digital form that describes a coordination issue: it contains a view of the model, an annotation, a comment, a status and the list of concerned objects, identified by their IFC GUID (Global Unique Identifier). This GUID is a unique identifier, automatically generated when each object is created in the IFC model. It ensures traceability and uniqueness of elements across all exchanges, regardless of the software used or the number of file revisions. Thanks to this identifier, it is possible to retrieve, follow or update the same object in different versions of the model without risk of confusion. Teams can thus exchange targeted remarks without sending back the entire model, while maintaining an exact correspondence between BCF comments and the IFC objects concerned. This lightweight format, based on an XML file or an API, has deeply changed the project culture. It established decision traceability and coordination agility that traditional methods could not allow. In current collaborative environments, BCF has become essential for interdisciplinary exchanges, from “clash” tracking to final DOE validation.
IDS The IDS (Information Delivery Specification), standardised by buildingSMART, formalises the information requirements of a project in the form of machine-readable rules. Each IDS file, written in XML or JSON, describes the properties expected for each type of object, the allowed formats, the admissible values and their link to a classification system. This principle allows replacing the textual specification, often ambiguous, with a verifiable digital reference. At delivery, the control software compares the IFC model with the IDS file and generates an objective compliance report. IDS thus acts as both a contractual and technical tool linking the owner’s information requirements to the models produced by designers. Its implementation nevertheless faces several obstacles. Few BIM tools yet natively integrate reading and automatic validation of IDS files, which limits its adoption. Formalising the information needs remains also complex for stakeholders often little trained in data structuring. The absence of a common interpretation framework, notably in terms of tolerance, units or exceptions, leads to divergences in validation between software. Finally, automatic generation of IDS files from a specification remains at an experimental stage, which slows its generalisation in operational practices.
OpenCDE The OpenCDE (Common Data Environment) extends the logic of standardisation to collaborative project management. It defines a set of standard APIs allowing data platforms, BIM software and document management systems to exchange information, metadata and notifications directly without using intermediary files. This approach aims to establish real-time interoperability, where information is available at the source, synchronised and traceable in a secure environment. In practice, this ambition still faces several constraints. OpenCDE remains in the progressive deployment phase: few platforms have implemented the full set of standardised APIs, and the coexistence of proprietary solutions slows the implementation of complete interoperability. Governance and data security issues remain complex, particularly regarding access rights, hosting and versioning of documents. Added to this is an organisational maturity still insufficient in many owners, who struggle to adapt their processes to a fully interconnected data environment.
bSDD The bSDD (buildingSMART Data Dictionary) guarantees semantic coherence of exchanges. This global online dictionary links the properties, units and classifications derived from different reference systems such as Uniclass, OmniClass, ETIM or CCI (Classification Commune des Infrastructures). Each concept receives a unique identifier, a universal definition and multilingual translations, thus ensuring that all participants speak the same technical language, whatever their discipline or software. The bSDD acts as a global semantic pivot, essential to mutual understanding of data between systems, software and territories. Its implementation remains however uneven. Some fields, notably civil engineering and HVAC, do not yet have exhaustive definitions. The differences between national reference systems sometimes make concept alignment uncertain, which complicates the creation of a common vocabulary. Moreover, the terminological rigour required for coherent use of bSDD still exceeds the common practice of many project teams, poorly trained in semantic data management. Finally, the dynamic connection between bSDD and BIM software remains partial or dependent on specific plug-ins, limiting its exploitation continuously in digital workflows.
Classifications: Giving Meaning to Information If formats guarantee the structure and flow of data, classifications ensure its understanding. They form the grammar of BIM, the system that allows elements to be named, organised and assigned a functional meaning. To classify is to make the model readable and durable: an object identified by a code remains understandable regardless of software or language. Classifications are not an invention of digitalisation. They extend the tradition of specifications and tender documents, where each trade and each constructive element had to be identified, quantified and hierarchised. This movement gradually transformed with computerisation, shifting from textual lists to logical structures exploitable by databases.
MasterFormat Designed in the 1960s by the Construction Specifications Institute (CSI) in the United States, MasterFormat was initially a pragmatic response to the needs of designers and contractors. Its principle was simple: group information according to execution specialties and types of works. Each division (Division 03 – Concrete, Division 09 – Finishes, Division 26 – Electrical…) corresponded to a lot of contract. This approach long constituted the international norm for writing technical specifications and bills of quantities. It enabled unprecedented document standardisation in tender and technical specification management. But its organisation by trades, effective on paper, proved inadequate for BIM: a digital model does not describe “works”, but “objects”. In a modelled wall, the concrete, insulation and facing coexist in the same entity; the logic of MasterFormat, segmented by trade, therefore cannot account for such integration. The system is nevertheless still used today for structuring specifications and contracts, notably in North America, as a documentary complement to the BIM model.
UniFormat II In the 1990s, the standard ASTM E1557 introduced UniFormat II, a classification oriented to functions and elements. Unlike MasterFormat, UniFormat does not focus on the trade that executes, but on the function performed: foundations, envelope, structure, interior finishes etc. This logic, inspired by value analysis and functional modelling, allows evaluating the global cost of a building at an early stage, before choosing materials or methods. In BIM, UniFormat is particularly useful for programming and design phases: it structures estimations, variant studies and preliminary performance models. However, its level of granularity remains limited: it describes functional families, not individual objects. UniFormat thus serves as an economic and functional skeleton, but must be combined with a finer classification for detailed modelling.
OmniClass Around the 2000s, the CSI and the Canadian Construction Association (CCA) undertook to merge the logics of MasterFormat and UniFormat into a coherent framework: OmniClass. OmniClass is based on an innovative principle for its time: a multidimensional classification, composed of fifteen independent but inter-connected tables. Each table describes a particular viewpoint of the built environment: products (Table 23), spaces (Table 13), activities (Table 31), works (Table 22), functions (Table 21), or project phases (Table 11). The ambition was to enable each actor, designer, cost consultant, asset manager, to classify information according to their own logic while preserving overall coherence. In practice, OmniClass paved the way for systemic BIM thinking, but its complexity and North American anchorage limited its international dissemination. Today OmniClass remains a valuable theoretical reference, notably for the structuring of object libraries and integrated databases, but it has been overtaken by lighter and natively digital systems.
Uniclass 2015 The real turning point for BIM came from the UK with Uniclass 2015, developed by the National Building Specification (NBS) within the government programme “BIM Level 2”. Designed from the start for digital use, Uniclass 2015 is distinguished by its hierarchical and multi-scale structure: it allows classification indifferently of a complex (Co), an entity (En), a space (SL), a system (Ss) or a product (Pr). This fine granularity makes fluid navigation between levels possible. Uniclass 2015 is updated quarterly to follow the evolution of techniques and trades. It integrates natively with BIM tools and relies on the bSDD (buildingSMART Data Dictionary) to ensure international compatibility. Thanks to its clear organisation and continuous maintenance, it has become the de facto BIM standard in Europe, used for both design and asset management. Its limits lie less in its structure than in its adoption: outside the English-speaking world, translation and adaptation to local practices remain challenges. In France, where no national reference system has yet been imposed, Uniclass 2015 constitutes a pragmatic basis for owners wishing to standardise their assets.
Normative Frameworks and Semantic Federation Rather than imposing a single system, international standardisation has chosen federation. Standards such as ISO 12006-2 and ISO 81346 define the common principles of structuring: functional decomposition, hierarchical coding and correspondence between functions, products and locations. The bSDD, developed by buildingSMART International, acts as a universal dictionary linking the different systems: it allows aligning a Uniclass code with its OmniClass, ETIM or even internal enterprise equivalent. This semantic interconnection paves the way to a global interoperability of meanings: the same object can be understood by all, regardless of its reference system of origin. Thus classification becomes the guiding thread of semantic BIM. It gives the model its ability to dialogue with management systems, maintenance tools and future digital twins.
Key Takeaways
Updated: October 202
