BIM Collaboration Format (BCF) as an Example of Reification and Serialization in Building Information Modeling (BIM) Practice

Abstract

Building Information Modeling (BIM) has fundamentally changed the way interdisciplinary coordination works in construction projects; however, the theoretical mechanisms underlying open collaboration standards in this field remain insufficiently explored. This article fills this gap by presenting a systematic analysis of the BIM Collaboration Format (BCF) through the lens of reification and serialization, two fundamental concepts in information systems theory. Although the BCF format is widely used in the industry and implemented in major BIM tools for clash detection and issue tracking, the existing literature treats it primarily as an operational tool, overlooking the deeper information systems principles that govern its architecture. The analysis demonstrates that BCF achieves reification by transforming informal coordination knowledge—such as verbally communicated clashes, scattered email threads, and undocumented design decisions—into first-class objects (Topic, Comment, Viewpoint) equipped with unique identifiers, typed attributes, ownership, temporal metadata, and formalized inter-object relationships. Further analysis was conducted on BCF’s serialization mechanisms, including XML encoding for file exchange, JSON for RESTful API communication, and ZIP archiving as a distribution container, each of which was selected to balance human readability, schema validation, compression, and cross-platform portability. The complementarity of these two mechanisms was examined: reification determines what to preserve and in what structure, while serialization determines how to encode and in what format, which together enable interoperable, auditable, and automatable coordination workflows in heterogeneous software environments. The analysis was illustrated with a real-world BCF example from a major infrastructure project in Poland, demonstrating practical alignment between theoretical constructs and their implementation. The research results provide both a conceptual foundation for researchers working on openBIM standards and practical guidance for practitioners seeking to optimize issue management, the implementation of a Common Data Environment (CDE), and the specification of Exchange Information Requirements (EIR). The study contributes new knowledge in three areas: (1) To the best of the authors’ knowledge, it provides the first systematic theoretical analysis of BCF through the lens of reification and serialization, filling a gap between the format’s widespread practical use and its limited theoretical understanding. (2) It demonstrates how the formal criteria of reification (unique identity, typed attributes, ownership, temporal metadata, and inter-object relationships) map onto specific BCF entities, offering a transferable analytical framework for evaluating other openBIM standards. (3) It identifies the complementarity of reification and serialization as a design principle that can guide the development of future standards for digital twins and IoT-based facility management.

1. Introduction

1.1. Research Background

The Building Information Modeling (BIM) methodology is transforming the construction sector by introducing a work paradigm based on a shared digital model instead of traditional two-dimensional documentation [1]. The central element of BIM is a digital model containing not only geometry but also semantics, i.e., information about the function, materials, relationships, and properties of elements [2]. This rich information layer distinguishes the BIM model from a simple three-dimensional representation (e.g., 3D CAD) and serves as the foundation for advanced analyses, simulations, variant studies, and the automation of construction processes. However, the BIM model alone is not sufficient for effective interdisciplinary collaboration on complex construction projects, especially so-called mega-projects (large-scale and interdisciplinary). Additional mechanisms are needed for communicating issues, comments, and design decisions among project participants, who often work in different proprietary tools and use different data formats.

The BIM Collaboration Format (BCF) was developed in response to this need and quickly became one of the key standards of the openBIM initiative [3]. It is an open standard developed by buildingSMART that enables the exchange of information about issues detected in a model without the need to transfer the entire model (geometry and semantics), making it an extremely effective communication tool for large design teams. BCF is an excellent example of the practical application of two fundamental IT concepts, reification and serialization, which originate from database theory and software engineering and have direct implications for information management practices in the construction industry.

1.2. BCF in the Context of the openBIM Concept

The first version (BCF 1.0) provided basic functionality for exchanging viewpoints and comments regarding issues detected in BIM models. Subsequent versions (2.0, 2.1, and the current 3.0) gradually expanded the specification to include workflow management capabilities, the assignment of priorities or deadlines, and integration with REST API interfaces for cloud-based Common Data Environment (CDE) platforms [3]. A key feature distinguishing BCF from other openBIM standards is the deliberate separation of issue information from the model’s geometric data. While another popular format, Industry Foundation Classes (IFC), serves as a comprehensive data model for exchanging building geometry and semantics, BCF focuses exclusively on coordination issues, referencing model elements via their GlobalId identifiers rather than duplicating geometric information. This architectural decision results in lightweight files, typically a few kilobytes in size, enabling rapid exchange via traditional and modern digital communication channels (email, CDE platforms, or API-based integrations), even in environments with limited bandwidth.

Previous research on BCF has focused mainly on practical implementation aspects. However, the theoretical foundations underlying the BCF data model have received relatively little attention in the scientific literature. The concepts of reification and serialization, though fundamental to understanding how BCF transforms informal coordination knowledge into structured, exchangeable data, have not been systematically analyzed in the context of openBIM collaboration standards. This theoretical gap limits the ability of researchers and practitioners to fully understand the design rationale behind BCF and to apply similar principles when developing new standards or extending existing ones for emerging use cases, such as digital twins and facility management.

1.3. Research Gap and Objective

A review of the literature indicates a significant asymmetry between the practical application of the BCF format and its theoretical understanding. On the one hand, BCF is widely used in the construction sector and implemented in most leading BIM tools for information modeling or clash detection, including Solibri Model Checker, Autodesk Navisworks, Trimble Connect, BIMcollab, and as plugins for proprietary applications such as Autodesk Revit and Graphisoft ArchiCAD. On the other hand, the scientific literature treats BCF primarily as an operational tool, neglecting a deeper analysis of the computational mechanisms that enable its functioning.

None of the existing perspectives undertake a systematic analysis of the format’s theoretical foundations, particularly the reification mechanisms that transform informal coordination problems into structured objects, and the serialization mechanisms that enable their persistent storage and exchange between heterogeneous systems. The lack of such an analysis has practical consequences that extend beyond the academic sphere. BIM practitioners who do not understand the principles of reification may underestimate the importance of fully populating BCF object attributes, treating fields such as priority, completion date, or responsible person as optional extras rather than key elements of the reified problem. Similarly, a lack of understanding of serialization can lead to inefficient data exchange practices, such as sending full IFC models instead of lightweight BCF files or relying on screenshots and text descriptions instead of structured viewpoints. In a broader context, understanding these mechanisms is essential for the informed design of potential future openBIM standards and for the effective integration of BCF with other digital technologies, where the reification and serialization of operational events take on new significance.

Thus, the aim of this article is to fill this gap through a systematic analysis of the BCF format through the lens of the concepts of reification and serialization. The article sets three specific research objectives. First, to explain how BCF reifies informal coordination problems into Topic, Comment, and Viewpoint objects with precisely defined attributes and relationships. Second, to analyze the serialization mechanisms used in BCF, including the XML format for files and the JSON format for APIs, along with a discussion of the ZIP archive structure as a container for serialized data. Third, the identification of the practical implications of these mechanisms for BIM project management, with particular emphasis on interoperability, auditability, and the potential for automating coordination processes. The article illustrates these issues using the example of a real-world communication system employing BCF files, native tools, and a CDE platform at Port Polska (formerly Centralny Port Komunikacyjny), demonstrating the relationship between theoretical concepts and their practical implementation.

To achieve these objectives, the article addresses the following research questions:

RQ1: How does the BCF standard reify informal coordination knowledge into structured, first-class objects, and what attributes and relationships characterize these objects?

RQ2: What serialization mechanisms does BCF employ, and how do their technical properties (human readability, schema validation, compression, cross-platform portability) support interoperable data exchange?

RQ3: How do the complementary mechanisms of reification and serialization translate into practical benefits for issue management in large-scale BIM projects, as illustrated by a real-world implementation case?

2. Research Methodology

This study adopts a qualitative research approach combining conceptual analysis with an illustrative case study, a design consistent with research aimed at bridging theoretical constructs and professional practice in information systems [4]. The primary method involves a systematic conceptual analysis of the BCF standard (version 2.1) through the theoretical lens of reification and serialization. The analysis followed a structured protocol: first, the official buildingSMART BCF-XML and BCF-API technical specifications were examined to identify all data entities, their attributes, and inter-entity relationships; second, each identified entity was evaluated against the formal criteria of reification, namely the possession of a unique identity, typed attributes, ownership metadata, temporal metadata, and formalized relationships with other entities; third, the serialization mechanisms (XML, JSON via REST API, and ZIP archiving) were analyzed with respect to their technical properties, including human readability, schema validation capability, compression ratio, and cross-platform portability. This protocol ensures that the findings are reproducible by any researcher with access to the publicly available BCF specifications. To demonstrate the practical alignment between the theoretical constructs and their real-world implementation, the conceptual analysis is complemented by an illustrative case study drawn from the Port Polska (formerly Centralny Port Komunikacyjny) infrastructure program in Poland. The case was selected purposively as a representative mega-project that employs multiple issue management approaches simultaneously: proprietary tools (Autodesk Navisworks viewpoints), a CDE platform module (Bentley ProjectWise Issue Resolution), and the open BCF standard (via BIMcollab BCF Manager). This multi-tool environment provides a rich context for examining how the reification and serialization mechanisms of BCF operate alongside and in comparison to alternative approaches. The case material consists of project documentation, tool interface observations, and BCF file structures generated during the coordination workflow of the Master Civil Engineer contract. The findings are validated through triangulation at two levels. Theoretical validity is established by grounding the analysis in well-established information systems concepts and verifying that the identified BCF mechanisms satisfy the formal definitions of reification and serialization. Practical validity is assessed by demonstrating that the properties identified through the theoretical analysis, such as unique identity of reified objects, typed attributes with ownership and temporal metadata, and serialization across multiple interoperable formats, are observable in the operational artifacts of the case study project. The research does not claim statistical generalizability but aims for analytical generalization, where the theoretical framework developed for BCF can be transferred to the analysis of other open standards in the BIM ecosystem and beyond. It should be noted that due to restrictions imposed by the information protection policy of Port Polska, detailed quantitative metrics such as issue statistics, time-to-resolution, or coordination outcomes could not be disclosed. The case study therefore serves an illustrative rather than empirical–quantitative purpose, demonstrating the alignment between theoretical constructs and their practical implementation without reporting project-specific performance data.

3. Literature Review

3.1. Reification as a Mechanism for Structuring Knowledge

The term “reification” comes from Latin, where res means “thing” and facere means “to make,” which can be translated as “turning into a thing” or “making something a thing.” In the context of information systems, reification involves transforming something abstract into a concrete entity that can be manipulated in a formal and repeatable manner [5]. This means representing relationships, events, or processes as first-class objects with their own attributes and identity, which allows them to be stored, searched, modified, and analyzed on par with other entities in the system [6]. This concept is of fundamental importance for the design of information systems, as it allows for the precise modeling of aspects of reality that would otherwise remain hidden or dispersed.

In the classical data model, the relationship between two entities is merely a connection, a line linking two entities without their own identity or attributes. After reification, it becomes an independent entity with full rights to participate in the data model [7]. This makes it possible to track history, report changes, or perform analysis, which would be impossible with a simple relationship. In the context of BIM, reification is of particular importance due to the complexity of relationships found in building models. The IFC standard makes extensive use of reified relationships, and classes such as IfcRelSpaceBoundary, representing the boundary between a space and a bounding element, IfcRelConnectsElements, describing the connection between structural elements, or IfcRelAssociatesMaterial, assigning a material to an element, represent relationships as full-fledged objects with their own properties and the ability to be extended [8]. Research indicates that a proper understanding and use of models is one of the key factors for the success of BIM implementations [9], which brings practice closer to the concept of the Digital Twin.

3.2. Serialization as a Mechanism for Preservation and Exchange

Serialization is the process of converting data structures or objects existing in a computer’s main memory into a format that allows them to be stored on a permanent medium, transmitted over a network, and later reconstructed in the same or a different system [10]. The reverse process, deserialization, reconstructs the original structures from the saved form, restoring the objects’ full functionality and relationships. Serialization is essential for the permanent storage of data beyond the application’s runtime and for data exchange between applications built in different ways. Without serialization mechanisms, modern information systems could not function, as data would exist only in volatile operating memory and be lost with every application shutdown.

In the BIM environment, serialization takes various forms tailored to specific use cases and technical requirements. The IFC-SPF format, based on the STEP standard, is compact and widely supported but difficult for humans to read. The IFC-XML format offers better readability at the cost of larger file sizes. The newer IFC-JSON format is gaining popularity in web applications due to native support in JavaScript environments [11]. In addition to open formats, there are also application-specific formats, such as .rvt for Autodesk Revit or .pln for Graphisoft Archicad, which serialize not only the model but also application-specific settings, views, and configurations. Each of these formats serializes the same conceptual model into a different textual or binary representation, and the choice of the appropriate format depends on the context of use, interoperability requirements, and technical limitations of the target systems.

3.3. The Relationship Between Reification and Serialization in the Context of BIM

Reification and serialization are mechanisms for representing knowledge that together form the foundation for sustainable and exchangeable information management in construction projects. Reification creates objects worth preserving by giving structure and identity to phenomena that previously existed only as informal knowledge (e.g., a modeling error) or ephemeral messages (a succinctly described geometric collision). Serialization enables the preservation of these objects (or phenomena) in a form that can be stored, transmitted, and reproduced in various technological and organizational contexts. This can be summarized as follows: reification answers the question of what to record and what structure to give to the recorded information, while serialization answers the question of how to record and in what format to represent the reified objects. These two questions are interdependent, as decisions regarding reification affect serialization options, and the limitations of serialization formats may necessitate specific approaches to reification.

Without reification, much valuable information remains ephemeral and exists only in the minds of project participants, in informal conversations, or in emails that are difficult to search, aggregate, and analyze. Knowledge about why a specific design decision was made, who reported an installation conflict, and what alternatives were considered before choosing a particular solution remains hidden unless it is reified into objects with attributes and relationships. Without serialization, even reified information remains ephemeral and is lost when the application is closed, the system crashes, or the application session ends. Research shows that effective knowledge management in BIM projects requires a conscious approach from various parties, especially if a so-called “BIM mandate”—that is, the mandatory use of BIM methodology in public procurement—is to be adopted in a given country [12]. While the concepts of reification and serialization are well established in information systems theory, no prior study has systematically applied them as an analytical lens to evaluate the architecture of openBIM collaboration standards. The existing BCF-related literature focuses on implementation workflows, software interoperability testing, or user adoption, without examining the deeper information systems mechanisms that underpin the format’s design and functionality. This article addresses that gap by operationalizing these concepts as formal evaluation criteria, as described in the methodology (Section 2).

3.4. Prior Research on BCF and BIM-Based Coordination

While the theoretical foundations of reification and serialization are well established, a growing body of research has examined the practical aspects of BIM-based coordination and interoperability that are directly relevant to the present analysis. Beach et al. [13] investigated the management of collaborative BIM data through the federation of distributed models, demonstrating that effective coordination in multi-stakeholder environments requires both structured data representations and robust exchange mechanisms, a finding that resonates with the reification–serialization complementarity explored in this article. Lee et al. [14] proposed an interoperable coordination method for sharing communication information using BCF, providing early empirical evidence that BCF can serve as a structured bridge between heterogeneous BIM platforms, although their analysis did not examine the deeper theoretical mechanisms that enable this interoperability.

More recently, de Marco et al. [15] explored the enrichment of BIM models through Information Delivery Specification (IDS), highlighting the importance of formal attribute definitions for ensuring data quality, a concern that parallels our analysis of attribute completeness in reified BCF objects. Zhao et al. [16] compared centralized, decentralized, and distributed BIM collaboration paradigms for digital twin readiness, concluding that the choice of data management architecture significantly affects interoperability and traceability. Their findings provide a broader architectural context within which BCF’s serialization mechanisms can be situated. Hagedorn et al. [17] developed toolchains for interoperable BIM workflows in a web-based integration platform, demonstrating the practical challenges of achieving seamless data exchange across tools, challenges that BCF’s dual serialization strategy (XML for files, JSON for APIs) is specifically designed to address. Finally, Xiang et al. [18] proposed a CDE framework for structural life cycle assessment that coordinates multiple information sources, underscoring the need for standardized formats that can preserve structured coordination data across the building lifecycle.

Despite these contributions, no prior study has systematically analyzed the BCF standard through the combined theoretical lens of reification and serialization. The existing literature treats BCF either as a practical interoperability tool or examines individual aspects of BIM coordination without providing an integrated theoretical framework that explains why BCF is effective at structuring and exchanging coordination knowledge. The present study addresses this gap.

4. Reification in BCF

4.1. The Coordination Problem as a First-Class Object

Before the introduction of BCF, a typical problem in a BIM project was handled through a conversation (e.g., a coordination meeting), an email sent to a group of recipients (an attempt to resolve a clash), a meeting note jotted down in a participant’s personal notebook, or a verbal instruction given in the design office. Information about a collision between a pipe and a beam might have been phrased as: “There’s a collision somewhere on the second floor, near the elevator; it needs to be fixed by next week.” Such information is unstructured because it lacks unambiguous attributes that allow for systematic processing. It is also incomplete due to the lack of a precise location that would enable the problem to be quickly found in the model. It is unassigned due to unclear responsibility for the solution, which leads to blurred accountability and potential conflicts. Finally, it is difficult to track due to the lack of status and history, which prevents verification of progress and auditing of the problem-solving process. In mega-projects with hundreds of participants and thousands of potential clashes, such an informal mode of communication quickly leads to information chaos, overlooked problems, and costly delays.

BCF reifies the problem into a Topic object (name) with precisely defined attributes compliant with the buildingSMART specification [19]. This object has a unique Guid identifier in UUID format, which ensures global uniqueness and enables unambiguous reference to the problem in any system. It has a TopicType category specifying whether the issue is a geometric clash, a procedural problem, a design query, or an informational note, allowing for filtering and prioritization by type. It includes a TopicStatus indicating the current resolution status in the cycle from opening through work in progress to resolution and closure. It stores a title that serves as a concise description of the problem, as well as a detailed description containing the full context, detection history, and proposed solutions. It specifies the priority—ranging from critical through high and normal to low—the creation date along with the reporter’s ID, the person responsible for the resolution, and the completion deadline. After reification, the problem becomes a first-class entity that can be managed systematically by assigning it to the appropriate people, filtering by various criteria, reporting its status at coordination meetings, escalating it if deadlines are missed, and formally closing it with documentation of the actions taken.

It should be noted that the BCF specification distinguishes between mandatory and optional attributes. Only a small subset, namely the GUID and the title, is required for a valid Topic object; all remaining attributes, including priority, assigned person, deadline, status, and description, are optional and may be omitted depending on project requirements and organizational maturity. This design reflects a deliberate trade-off between the completeness of the reified object and the flexibility needed to accommodate diverse workflows across organizations of varying size and BIM experience. However, this flexibility also means that a minimally populated BCF Topic, when considered solely in terms of its alphanumeric attributes, may carry little more information than an informal email notification, reducing the practical benefits of reification. It should be noted, however, that even a minimal Topic can be accompanied by a Viewpoint with a camera position, a snapshot image, and references to specific model elements via their GlobalId identifiers, features that substantially exceed the capabilities of email communication and represent a significant added value of the BCF format even at its most basic level of use. The question of whether the current set of BCF attributes is sufficient also deserves consideration. The specification does not include fields for issue interdependency (linking related Topics), estimated resolution effort, cost impact, or risk classification, all of which are commonly tracked in mature project management systems. While the BCF schema allows for custom extensions via the BimSnippet element, such extensions are not standardized and therefore compromise cross-platform interoperability. This suggests that future revisions of the BCF standard could benefit from formalizing additional attributes that reflect the needs of advanced project management without sacrificing the format’s characteristic lightness.

4.2. Comments and Viewpoints as Supporting Objects

BCF also reifies comments, which in a traditional work model would exist as scattered email correspondence that is difficult to link to specific issues and impossible to search systematically. In BCF, each comment becomes a Comment object with attributes such as a unique GUID, the date and time of addition accurate to the second, an author identifier enabling the assignment of responsibility, the comment content containing the substantive statement, and an optional reference to a viewpoint illustrating the context of the comment. Comments are linked to a Topic by being embedded in an XML structure, creating an easy-to-follow discussion thread with a complete chronological history. Thanks to this reification, it is possible to reconstruct the entire decision-making process, understand the arguments of individual participants, and draw conclusions for the future as part of the learning process (adaptation through assimilation and accommodation).

A particularly innovative example of reification is Viewpoint, a reified way of looking at a model that transforms subjective visual experience into an objective, repeatable record. Instead of a verbal description such as “look from the elevator, from above, and you’ll see that pipe entering the beam,” BCF records precise mathematical parameters that enable the view to be accurately recreated in any compatible tool. Viewpoint contains the camera position defined by X, Y, Z coordinates in the model’s global coordinate system, the viewing direction as a unit vector, a vector defining the top of the frame, and the viewing angle for a perspective view or the scale for an orthogonal view. It also includes a list of selected elements identified by their IfcGuid, visibility information for individual elements allowing irrelevant objects to be hidden, coloring that highlights problematic components by assigning warning colors, and optional section planes that allow hidden elements to be revealed. The reification of a viewpoint enables its exact reproduction in any BCF-compatible tool, allowing the user in the office to see exactly what the author of the submission saw in a completely different location, regardless of the software used [20].

It is worth noting that the reification of the point of view in the BCF format serves as a bridge between the mathematical precision of the model and human visual perception. By recording parameters such as camera position coordinates and direction vectors, the designer’s subjective perspective is reduced to a deterministic dataset. In practice, this eliminates so-called information noise because the recipient does not have to guess the sender’s intentions, as the system automatically positions the virtual camera in the exact same position where the problem was defined. This approach can significantly reduce the time required for so-called context switching, allowing the engineer to immediately transition from analyzing the report to substantive work on resolving the collision.

4.3. Relationship with the IFC Model and Maintaining the Format’s Lightness

BCF does not duplicate geometric or semantic information from the IFC model, but refers to it via GlobalId identifiers, which is a deliberate design decision aimed at maintaining the format’s lightness and avoiding data synchronization issues. The Component element in BCF contains the element’s IfcGuid, which is a globally unique 22-character base64 identifier, the source system name indicating the authoring tool, and an optional internal identifier within that tool. Thanks to this approach, a BCF file containing dozens of issues typically takes up a few dozen kilobytes, while the corresponding IFC model can weigh hundreds of megabytes or even gigabytes. This separation enables the rapid exchange of issue information via email, CDE systems, or instant messengers without the need to transfer heavy geometric models.

This is also an example of reference reification, where the reference to an element itself becomes an object with additional metadata that enriches the context [21]. In addition to the GlobalId identifier itself, the reference may contain information about the system in which the element was created, which is important in multi-tool environments where the same project is developed in various applications from a given vendor. It may also contain an identifier specific to the authoring tool, allowing the element to be opened directly in the source application. This approach implements the principle of the so-called “single source of truth,” where geometry and semantics remain in the IFC model, and the BCF contains only information about issues and references to elements, avoiding data duplication and the associated version synchronization problems.

5. Serialization in BCF

5.1. XML Format as a Container for Reified Objects

BCF uses XML as the primary serialization format for the reified Topic, Comment, and Viewpoint objects. The choice of XML as the serialization format was driven by a number of technical and organizational factors relevant to the buildingSMART ecosystem [19]. XML offers human readability, enabling the inspection and debugging of files without specialized tools, using only a text editor. It has broad tool support across all popular programming languages and development environments, which lowers the implementation barrier. It enables formal validation via XSD schemas, allowing for automatic verification of the structural correctness of files before processing. Finally, it ensures compatibility with other buildingSMART ecosystem standards, such as IFC-XML and mvdXML, which facilitates integration and the development of consistent solutions. Alternative formats, such as JSON or binary formats, were considered, but ultimately XML was deemed to best meet the requirements for interoperability and long-term archiving [19].

The coexistence of three serialization paths in BCF, XML encoding within ZIP archives for file-based exchange, JSON encoding for RESTful API communication, and the ZIP container as a packaging mechanism, reflects distinct technical requirements, but also raises questions about maintenance burden and long-term sustainability, a topic actively discussed within the buildingSMART BCF working group. XML offers formal schema validation via XSD, broad compatibility with the buildingSMART ecosystem, and human readability, but suffers from verbosity and declining adoption among modern web developers. JSON provides native compatibility with JavaScript and web frameworks, a more compact syntax, and alignment with contemporary development practices, but lacks natively enforced schema validation equivalent to XSD and introduces the risk of subtle semantic differences when the same reified object is serialized differently for file exchange and API communication. The ZIP container serves a fundamentally different purpose as a packaging and compression mechanism rather than a data encoding format, bundling multiple XML files and screenshots into a single portable unit. If the buildingSMART community were to pursue simplification, the most viable path would be to converge on JSON as the primary data encoding format for both file-based and API-based exchange, while retaining ZIP solely as a packaging container, thereby reducing the implementation burden for software vendors and eliminating the risk of semantic divergence between parallel representations of the same objects, at the cost of losing XSD-based validation and breaking with the XML tradition of the broader buildingSMART ecosystem.

A BCF file with the .bcf or .bcfzip extension is a ZIP archive containing XML files and optional raster images representing screenshots of views (Figure 1). Using a ZIP archive as a container provides compression that reduces transmission size, where a single file represents a complete set of problems, and ensures portability thanks to universal support for the ZIP format across all operating systems. The structure of a typical BCF 2.1 file includes a bcf.version file in the root directory that specifies the format version and allows applications to adapt their parsing to the appropriate specification. The optional project.bcfp file contains project metadata such as the name and identifier. The optional extensions.xsd file defines allowed values for enumerated fields, enabling adaptation to specific organizational requirements. For each topic, there is a directory named after its GUID, containing the markup.bcf file with the main topic and comments, one or more viewpoint files with camera viewpoints, and corresponding screenshots in PNG or JPEG format.

5.2. Example of a BCF (Issue Resolution) in Port Polska

The Port Polska investment program includes the construction of a new domestic airport, a high-speed rail network, roads around the airport, a logistics center, Airport City, and activities related to regional development, and is being implemented by the company Port Polska (formerly Centralny Port Komunikacyjny). The state-owned company was established pursuant to Article 11 of the Act of 10 May 2018, on the Central Transport Hub [22] to prepare and implement the Central Transport Hub’s Multi-Year Program. The program’s goal is to create a modern transportation hub of international significance, connecting various modes of transport: air, rail, and road. The new airport will be designed to handle 34 million passengers annually in its initial years of operation and will be structured in such a way that, in the long term, it can be flexibly expanded in accordance with market needs and growth projections. This is a unique mega-project, the only one of its kind in Poland, integrating many industries, located across three municipalities, and impacting as many as 18 surrounding municipalities. The estimated cost of the investment through 2032 is 131.7 billion zlotys. In implementing such a complex project, it is essential to maintain continuity and efficiency in communication.

The program’s objectives are achieved through the execution of specific tasks within individual projects. One of these is the Master Civil Engineer project, which constitutes one of four key contracts. The Contractor’s strategic tasks include developing multidisciplinary design plans and technical specifications for the hub’s infrastructure, including runways and taxiways, aprons, utilities and service lines, as well as civil engineering structures. The entire program is being implemented in accordance with BIM methodology. The Company has procedures in place specifying information exchange requirements, work on the CDE platform, document review and versioning processes, as well as document naming and numbering conventions. Individual EIR (Exchange Information Requirements) and OPZ (Scope of Work) documents contain requirements regarding the method of communication between the Client and the Contractor.

One of the key tasks in the investment implementation process according to the BIM methodology is model verification. This involves checking the geometric data as well as the semantics of the model, which is intended to reflect the actual structure. Two-dimensional documentation is created based on these models. The process of verifying the representation of requirements and technical specifications can take various forms, but the focus here is on the next step in this process: reporting comments. In the construction sector, it is common to encounter an approach where all errors are reported informally—that is, verbally during a conversation, a coordination meeting, or via messages on communication platforms or email. In such information exchanges, key recipients are typically overlooked, communication continuity is not maintained—and thus its timeliness is compromised—and the messages themselves contain selective data. This leads to delays in construction, increased unplanned costs, and poor quality of the work produced. An approach consistent with BIM methodology clearly specifies, among other things in ISO 19650 [2], how and between which groups effective information exchange should take place. Comments regarding the model should refer directly to it. This eliminates the need to take screenshots, search for information about a faulty element, and locate, for example, a clash each time. The BCF standard is precisely such a solution. Nevertheless, providers of native software or CDE platforms are also introducing their own solutions to increase competitiveness and retain customers within their own product ecosystems. One example is Autodesk, which provides the Autodesk AEC Collection, which includes Navisworks for coordination, clash detection, as well as 4D and 5D simulations. One of the tools available in this environment is the creation of “viewpoints,” which are a list of comments related to the model. Such a note consists of the comment content, includes the date and time, author, status, its ID, as well as the viewpoint itself—that is, the camera view specified by the creator—and any markings, e.g., in the form of a revision cloud. The default export of viewpoints from the program is to the XML format. In addition to the displayed information, it stores the comment’s source (file name, path, schema), position, rotation, camera vector, view clipping, and element selection. A file exported in this way differs from BCF primarily in terms of compatibility, as it is not suitable for open import into other software but is used for internal information exchange. It also lacks the ability to assign a person responsible for a given issue and to create a history of discussions and changes.

The Navisworks interface allows users to display a list of comments and browse through them, export individual comments or groups of comments to XML format, as well as views in the form of PNG files. Comments are numbered (Figure 2).

Error communication can also take place within the CDE platform, which serves as a shared working environment for stakeholders in the investment process. The design phase of the Port Polska program is being carried out using the CDE from Bentley Systems. The web version of the ProjectWise platform includes an Issue Resolution (IR) module responsible for exchanging comments and feedback on documentation (Figure 3). This tool allows users to set up information flows between defined user groups, create form templates with specific fields, attach comments to a specific location in a document (creating a reference in the form of a link to the document and markings such as underlining or highlighting with a rectangle), organize comments according to project phases, exchange comments, and add attachments. Each IR form includes a revision history showing the date, time, author, and type of modification made. The IR module provides statistics on, among other things, the statuses of created comments, the time taken to resolve comments, and the number of reports assigned to specific individuals. By using this solution, project participants have constant access to the event history and the resolution status of an issue; they can request further details, and no participant is left out of the comment exchange sequence.

IRs can also be easily filtered, sorted, and exported as PDF, CSV, ZIP, and even BCF files. The color-coded division of sections clearly indicates which fields should be filled out by the Contractor and which by the Client. A resolved thread is closed, but if there is a need to revisit a specific case, the form can be reopened. By comparison, finding information from two years ago within an email inbox might be impossible. Personnel changes are a natural occurrence. IR retains the personal information of discussion participants; however, if an employee who resolved a given issue via email leaves without adding the appropriate people to the recipients, the rest of the team loses the source of information regarding the verification process. Additionally, that same employee could have moved the thread to the trash, whereas on the CDE Platform, no information is lost.

The Issue Resolution module is also designed for annotating models using the internal iModel tool. This tool allows users to view IFC and native models, review their content, verify clashes, and add comments to specific elements. Bentley ProjectWise includes functionality for importing BCF comments into iModel; however, this capability is limited and has seen little development due to the vendor’s own native tools, specifically Issue Resolution (Figure 4).

Another option for exchanging comments is the open BCF standard, which is a package of information about an issue, supported by and across many applications. The format provides complete information about a note created in the BIM process. It is the best solution for use in interdisciplinary coordination. Using the free BIMcollab BCF Manager plugin, created viewpoints are exported to the BCF format. The author can enter additional information, such as the note’s priority, type, resolution deadline, and additional comments (Figure 5). The created comments are saved in the project within the BIMcollab environment, which allows for managing comments, verifying their resolution, conducting discussions, and reviewing statistics. This server-based approach to BCF management, enabled by the BCF-API specification [23] and first explored by van Berlo and Krijnen [24], extends the original file-exchange paradigm by enabling real-time, centralized coordination [25].

The example of projects implemented by Port Polska illustrates that in mega-projects, the BCF format ceases to be merely a technological curiosity and becomes a critical management resource. The use of BCF Manager-type plugins allows for the creation of an efficient feedback loop between coordination software and the proprietary tool, without the need to leave the designer’s native work environment. In the context of massive-scale projects, where the number of comments runs into the thousands, automating the process of creating a reified issue by directly retrieving element GUIDs from the model eliminates human errors resulting from manual data entry, which is crucial for maintaining data integrity across the entire CDE ecosystem.

5.3. Comparison with Alternative Approaches

To contextualize the contribution of BCF, it is useful to compare its reification and serialization mechanisms with alternative approaches to issue communication that coexist in current practice. The simplest and still widely used method is informal communication via email or instant messaging platforms (such as Microsoft Teams, Slack, Discord, or WhatsApp) with attached screenshots. In this approach, the issue is described in natural language in the message body, the visual context is provided by a manually captured screenshot, and the relevant recipients are selected by the sender. This method offers maximum flexibility and requires no specialized tools, but it lacks structured attributes (there is no machine-readable status, priority, or element reference), produces no auditable history beyond the email or chat thread, and depends entirely on the sender’s diligence in selecting recipients and providing sufficient context. Locating a specific issue months later requires searching through email or chat archives with keyword-based queries, which is unreliable when descriptions are informal or inconsistent.

Proprietary issue management tools, such as the Autodesk Navisworks viewpoint system or the Bentley ProjectWise Issue Resolution module described in Section 5.2, represent an intermediate step. These tools reify issues to varying degrees: Navisworks viewpoints capture camera position, element selection, and timestamps, but lack fields for responsible person, priority, or workflow status. The ProjectWise IR module offers a richer attribute set, including configurable forms, color-coded responsibility assignment, and built-in statistics, but operates within a closed ecosystem that does not support open exchange with tools from other vendors. Both approaches achieve partial reification and proprietary serialization, which limits interoperability.

BCF, by contrast, combines a standardized reification model with open serialization formats, enabling the reified objects to be created, exchanged, and processed across tools from different vendors.

Table 1. Comparison of issue management approaches in BIM projects. Source: own elaboration.

Dimension	Email with Screenshots	Proprietary Tools (e.g., Navisworks, ProjectWise IR)	BCF
Reification level	None (free text)	Partial (vendor-specific attributes)	Standardized (Topic, Comment, Viewpoint)
Unique identifier	No	Vendor-internal	GUID (globally unique)
Element reference	Manual description	Vendor-specific ID	IfcGuid (IFC-compatible)
Camera viewpoint	Screenshot (static image)	Recorded but proprietary format	Mathematically defined, reproducible
Workflow attributes	None	Varies by tool	Status, priority, assigned person, deadline
Serialization format	MIME/email	Proprietary (XML, database)	Open (XML, JSON, ZIP)
Cross-vendor exchange	Copy-paste only	Export/import with data loss	Native interoperability
Audit trail	Email thread (fragmented)	Within platform only	Complete, portable history

summarizes this comparison across key dimensions.

This comparison illustrates that BCF’s principal advantage lies not in individual features but in the combination of standardized reification with open serialization, which together enable a level of interoperability and auditability unattainable by informal or proprietary alternatives.

6. Discussion and Conclusions

6.1. The Lifecycle of a Reified Problem in Project Practice

The combination of reification and serialization enables a complete, easily traceable lifecycle of a coordination issue from detection to final closure, while maintaining a complete history. The process begins with the detection of a problem, which can occur automatically via a collision detection tool such as Solibri Model Checker or Navisworks, or manually by a project participant during a model review. At the moment of detection, the problem exists only as an observation in a person’s mind or as the result of an algorithm, without a permanent digital representation. Reification then takes place, during which the problem is transformed into a Topic object with a full set of attributes, supplemented by a comment explaining the context and circumstances of detection, and a viewpoint enabling precise localization within the model. From this point on, the problem has an identity and structure and can be the subject of operations within the management system.

The reified object is then serialized into a bcfzip file or sent via API to a central server or CDE platform. Serialization transforms the object existing in the application’s memory into a persistent record that can be stored and transmitted. The file or API message is forwarded to the responsible person or team via distribution mechanisms appropriate for the given project environment, whether via email, the CDE system, or automatic notifications from a collaboration platform. The recipient opens the file in their authoring tool equipped with BCF functionality or in a dedicated BCF manager, where deserialization occurs—that is, the reconstruction of objects from their saved form (Figure 6). The designer views the problem within the context of their model, can navigate to the specified viewpoint, and proceed with analysis and making changes.

After changes are made to the model, the BCF object is updated by changing its status, adding a comment describing the actions taken, and optionally adding a new viewpoint showing the state after modification. The updated object is serialized again and returned to circulation, closing a single iteration of the cycle. The cycle may repeat multiple times in the case of complex problems requiring consultation among multiple participants or iterative refinement of the solution. Ultimately, the problem is formally closed by changing the status to Closed, while retaining the full history of all comments, viewpoints, and status changes, which serves as valuable material for analysis and audits.

6.2. Practical Benefits of Reification and Serialization

Thanks to standardized reification, which defines what to record and in what structure, and serialization, which defines how to record and in what format, BCF ensures true interoperability between tools from different vendors, which is one of the pillars of the openBIM concept [24]. A task created in Solibri by the BIM coordinator can be opened in Navisworks by the site manager, commented on in BIMcollab Zoom by the MEP designer, and closed in Autodesk Revit by the architect, with all these operations taking place without loss of information and while preserving the full context. This interoperability is possible precisely because the BCF standard precisely defines both the reification model—which specifies which aspects of the problem are represented as attributes and relationships—and the serialization format—which specifies how these aspects are stored in XML files.

The reification of comments and status changes, along with precise timestamps and author identifiers, creates a complete audit trail that can be reconstructed and verified at any point in the project and building lifecycle [24]. It is possible to answer questions such as who reported the issue and under what circumstances, exactly when it was detected, who was assigned responsibility for resolving it and whether that assignment was changed, what subsequent solutions and arguments were proposed by individual participants in the discussion, who and when the issue was finally closed, and how long it took to resolve the problem from reporting to closure. This information has not only operational value during the project but also strategic value for process improvement and the resolution of potential disputes.

Reified and serialized data in a structured XML or JSON format can be processed automatically by analytical tools and reporting systems, opening up possibilities unattainable through informal communication [26]. It is possible to automatically generate reports on the status of issues, broken down by industry, priority, or responsible person. It is possible to create dashboards that visualize coordination progress and identify so-called bottlenecks, which aligns with the current trend of storytelling. It is also possible to configure alerts for issues that exceed the set resolution deadlines or are escalated to a higher priority. Another capability is conducting statistical analyses regarding collision types, resolution times, or the distribution of issues across industries, which provides data for improving design processes. However, the reliability of such automated analyses depends on the quality and consistency of the structured data, a challenge well documented in the context of automated IFC validation [27].

6.3. Transformation of Tacit Knowledge into Explicit Knowledge

Thus, BCF implements in construction practice the theoretical knowledge transformation model described by Nonaka and Takeuchi, transforming tacit knowledge into explicit knowledge that can be stored, searched, and transferred [28]. Design decisions that would normally remain in the minds of participants or in emails are captured in a structured form linked to specific model elements and a visual context. This externalization of knowledge is of fundamental importance for construction projects characterized by long lifecycles, high participant turnover, and complex interdependencies between decisions made at different stages [29].

As demonstrated by the systematic comparison presented in Section 5.3 and Table 1, the differences between issue management with and without BCF are noticeable at every level. An imprecise issue location is replaced by camera coordinates that allow for immediate navigation to the exact spot, and GUIDs for elements that enable their programmatic retrieval and analysis. Vague responsibility scattered among meeting participants is replaced by a specific person assigned in the AssignedTo field, with the ability to track assignment changes. A history scattered across dozens of email threads and meeting notes becomes an organized sequence of comments with precise dates, authors, and optional viewpoints. A status that previously required follow-up via phone or messenger becomes immediately visible in the system to all authorized participants. Manual, time-consuming, and error-prone reporting is replaced by automatic report generation from structured data, with the ability to filter and aggregate as desired.

The BCF format serves as a modern and illustrative example of the application of reification and serialization in construction engineering, demonstrating how abstract IT concepts translate into concrete benefits in the management of complex projects. Reification transforms the ephemeral coordination problems inherent in informal communication and participants’ memories into persistent objects with attributes, identities, and relationships that enable systematic processing. Serialization enables the preservation of these objects in formats suitable for long-term storage, secure exchange between heterogeneous systems, and automatic analysis by IT tools. The combination of both mechanisms creates the foundation for interoperable, auditable, and automatable collaboration in BIM projects, delivering theoretically grounded benefits such as reduced coordination time, fewer errors, and improved quality of project documentation.

Understanding the concepts of reification and serialization allows BIM specialists to better design information processes, consciously select and configure tools, and more effectively utilize available openBIM standards. This knowledge is particularly valuable when implementing CDE platforms, defining EIR (Exchange Information Requirements) and BEP (BIM Execution Plan) requirements, and training project teams in BIM methodology. The future development of the BCF standard and its integration with digital twin technologies and facility management systems will require further consideration of what information is worth reifying in the context of building operations and how to effectively serialize it for various use cases, including IoT (Internet of Things) monitoring, predictive maintenance, and energy management [30]. It can be expected that the principles of reification and serialization will find application in future buildingSMART standards, expanding the possibilities for structuring and exchanging knowledge about building objects throughout their entire lifecycle.

6.4. Authors’ Critical Reflection

While the analysis presented in this article demonstrates the theoretical soundness and practical utility of BCF, several critical observations deserve attention. From the authors’ perspective, the BCF standard, despite its strengths, exhibits limitations that become apparent when viewed through the very theoretical lens applied in this study. The reification model of BCF, although well-suited for clash detection and design coordination, remains focused on discrete, point-in-time issues. It does not adequately capture process-level knowledge, such as the rationale behind a sequence of design decisions or the interdependencies between issues that, taken individually, appear unrelated but collectively indicate a systemic problem in the design. In the authors’ experience with mega-projects such as Port Polska, this limitation means that higher-order coordination patterns must still be reconstructed manually by project managers, which partially undermines the automation potential that reification and serialization are meant to enable.

Furthermore, the coexistence of three serialization formats (XML for file exchange, JSON for API communication, and ZIP as a distribution container) introduces a practical tension. While each format serves a justified technical purpose, as analyzed in Section 5.1, the maintenance of three parallel serialization paths increases the implementation burden for software vendors and creates subtle interoperability risks when the same reified object is serialized differently across systems. The authors believe that the buildingSMART community should consider whether a convergence toward a single primary serialization format, most likely JSON given current web technology trends, would better serve the long-term goals of the openBIM ecosystem, while retaining ZIP archiving solely as a packaging mechanism.

Another observation concerns the gap between the theoretical completeness of BCF’s reification model and its practical utilization. The case study revealed that many BCF attributes, particularly those related to priority, deadlines, and responsible persons, are frequently left unpopulated by practitioners, not because the standard lacks these fields but because organizational workflows do not enforce their completion. This suggests that the success of reification depends not only on the design of the data model but also on the maturity of the organizational processes that surround it. Standards such as ISO 19650 [2] provide a framework for information management, but the effective use of reified objects requires specific training and procedural enforcement that go beyond what the standard itself can prescribe. This observation aligns with broader research on BIM adoption, which highlights the role of user profile characterization [31] and the need for context-sensitive collaboration strategies [32] in ensuring that the potential of BIM standards is fully realized in practice.

Finally, looking forward, the authors observe that the principles of reification and serialization analyzed in this article are not limited to issue management. As the construction industry moves toward digital twins and IoT-enabled facility management, new categories of operational knowledge, such as sensor readings, maintenance events, and occupancy patterns, will require their own reification models. The analytical framework developed in this study, based on evaluating data entities against formal reification criteria, can serve as a methodological tool for designing these future standards, ensuring that the lessons learned from BCF are systematically transferred to emerging domains. This perspective is further supported by recent critical analyses suggesting that BIM data exchange is evolving from monolithic file-based approaches toward granular, kernel-independent data representations using formats such as glTF, USD, and structured JSON [33], which reinforces the need for well-designed reification and serialization mechanisms in future open standards.

This article contributes to the body of knowledge in three specific ways. First, to the best of the authors’ knowledge, it offers the first dedicated theoretical analysis of BCF grounded in the concepts of reification and serialization, moving beyond the operational perspective that dominates the existing literature. Second, by mapping the formal criteria of reification onto BCF entities (Topic, Comment, Viewpoint, Component), the study provides a transferable analytical framework that researchers can apply to evaluate other openBIM standards or propose new ones. Third, the illustrative case study from the Port Polska mega-project illustrates that the theoretical properties identified through conceptual analysis align with operational practice, thereby bridging the gap between abstract information systems theory and the concrete needs of BIM project management. Thus, the BCF not only streamlines ongoing communication but transforms the individual, scattered experiences of process participants into structured and strategic knowledge capital that can be leveraged in the design of future standards and during the building’s operational phase.