Content uploaded by Fan Xue
Author content
All content in this area was uploaded by Fan Xue on Nov 08, 2022
Content may be subject to copyright.
1
A semantic differential transaction approach to minimizing information 1
redundancy for BIM and blockchain integration 2
Fan Xue and Weisheng Lu 3
xuef@hku.hk ; wilsonlu@hku.hk 4
The University of Hong Kong 5
6
This is the peer-reviewed post-print version of the paper:
Xue, F., & Lu, W. (2020). A semantic differential transaction approach to minimizing
information redundancy for BIM and blockchain integration.
Automation in
Construction, 117, 103270. Doi: 10.1016/j.autcon.2020.103270
The final version of this paper is available at: https://doi.org/10.1016/j.autcon.2020.103270.
The use of this file must follow the Creative Commons Attribution Non-Commercial No
Derivatives License, as required by Elsevier’s policy.
7
Highlights 8
• A novel semantic differential transaction (SDT) approach for BIM and blockchain 9
integration was proposed. 10
• The SDT core identifies the incremental semantic changes in BIM development cycle. 11
• The SDT approach was implemented in Python with state-of-the-art algorithms and JSON 12
data structures. 13
• The SDT approach has a smart contract-like change consensus protocol, which is ready for 14
blockchain. 15
• The SDT approach was validated on two BIM cases. 16
• BIM changes in the tests were captured with minimum information redundancy, e.g., the 17
SDT results were as small as 0.02% of the BIM file size. 18
• The tests confirmed the bi-directional operations between BIM and SDT results in near 19
real-time. 20
21
Abstract 22
Those attempting to integrate building information modeling (BIM) and blockchain soon 23
encounter the enormous challenge of information redundancy. Storage of duplicated building 24
information in decentralized ledgers already creates redundancy, and this is exacerbated as the 25
BIM model develops and is utilized. This paper presents a novel semantic differential 26
transaction (SDT) approach to minimizing information redundancy in the nascent field of BIM 27
and blockchain integration. Whereas the conventional thinking is to store an entire BIM model 28
or its signature code in blockchain, SDT captures local model changes as SDT records and 29
assembles them into a BIM change contract (BCC). In this way, the version history of a BIM 30
project becomes a chain of timestamped BCCs, and stakeholders can promptly synchronize 31
2
BIM changes in blockchain. We test our approach in two pilot cases. The results show that SDT 32
captures, in near real time, sequential and simultaneous BIM changes at less than 0.02% of the 33
Industry Foundation Classes file size. We also prove model restoration from the lightweight 34
BCCs in a small-scale BIM project. In addressing the fundamental issue of information 35
redundancy in BIM and blockchain integration, this research can help the industry advance 36
beyond the rhetoric to develop operable blockchain BIM systems. 37
38
Keyword: Building information modeling, Semantics, Blockchain, Industry foundation classes, 39
Interoperability, Information redundancy. 40
41
1 Introduction 42
Various researchers have articulated the challenges of construction. Every building is a unique 43
prototype developed by a team of stakeholders that may never have worked together before and 44
may never again (ICE 2019). Construction processes such as design, manufacturing, 45
transportation, and site work suffer discontinuity and are deeply fragmented, distributed, and 46
specialized (Egan 1998). This situation is made worse by the long construction supply chain for 47
design for manufacturing and assembly (DFMA) and industrialized construction (Molloy et al. 48
2012; Larsson et al. 2014). The fragmentation and distribution features cause widespread and 49
chronic problems, such as inferior quality, escalating cost, severe delay, and lackluster 50
productivity. Successful delivery of any construction project requires seamless collaboration 51
among stakeholders and efficient information exchange, and a broad spectrum of model 52
specifications and software tools for specialized construction tasks have been adopted to this 53
end. In addition, interoperability of building information is critical (Eastman et al. 2011). 54
Building information modeling (BIM) provides this interoperability through a trustworthy, 55
shared information platform. As the “digital representation of physical and functional 56
characteristics of a facility and a shared knowledge resource for information about a facility, 57
forming a reliable basis for decision during its life-cycle” (NIBS 2015), BIM is a game-58
changing technology that has been successfully mainstreamed across the global construction 59
industry. 60
61
Recently emerging from the technology sphere, blockchain is potentially an alternative means 62
of building trustworthy collaboration in construction. A blockchain is a cryptographically 63
secured distributed ledger within a decentralized consensus mechanism (Risius & Spohrer 64
2017). It keeps an immutable, secure, and transparent database through which users can transact 65
valuable assets in a public and pseudonymous setup without the presence of an intermediary or 66
central authority (Beck et al. 2016; Xia et al. 2017). Traditional exhortations of trust building 67
have a strong root of normativism. According to this school, trust is a quintessence to business 68
success, an intrinsic value of human being, and a social norm (Laan et al. 2011). Therefore, we 69
do anything positive to build it. Blockchain-based trust building, in contrast, has a root of 70
naturalism. Untrusting behavior in construction transactions is a state that is accepted as natural, 71
like it or not. However, blockchain adopts an alternative approach by keeping custody of 72
3
immutable, cryptographic, and verifiable information in decentralized ledgers that construction 73
stakeholders cannot deny or falsify but choose to trust each other. Blockchain is not based on a 74
single centralized server or company’s cloud. Rather, it is supported by a network of computers 75
(peers), each holding all duplicated transactions in a blockchain. The duplicated transaction 76
histories introduce information redundancy for the sake of credibility (e.g., by safeguarding 77
immutable, decentralized, and distributed information) but sacrifice time, storage, and access 78
efficiency in comparison with native computer storage. 79
80
Interest in BIM and blockchain integration is growing. For example, Li et al. (2019) review 81
blockchain technology in the built environment and construction industry, presenting 82
conceptual models and practical use cases. Zheng et al. (2019) propose a blockchain-based big 83
data model for BIM modification audit and provenance. According to Penzes (2018), “the 84
fundamental concept that can enable the combination of BIM and blockchain technology is 85
their shared ability to serve as a single source of truth.” He distinguishes two ways of utilizing 86
BIM and blockchain: (1) BIM can take information from the blockchain, such as supply chain, 87
provenance, installation, and payment; and (2) building information can be assigned to a 88
blockchain to be used later, e.g., for smart payment or procurement. Through integration, 89
therefore, BIM and blockchain can offer more value-added applications than either can 90
separately. 91
92
However, those who aim to develop an operable blockchain BIM system face massive 93
challenges. One is information redundancy. The file-based data exchange in BIM (e.g., 94
information delivery manual) leads to massive data volume. A typical model can be of tens to 95
hundreds of megabytes (MB), while block sizes are typically at kilobyte (KB) levels. As 96
mentioned above, to ensure information accountability transactions in a blockchain are 97
duplicated and safeguarded in a decentralized ledger distributed among peers. This process will 98
increase the BIM data volume exponentially, and it will be “sticky” to maneuver it. Even more 99
challenging is that information in BIM is continuously being changed and updated by 100
stakeholders. The archived history of a model is redundant in current practice because saving a 101
small change can lead to a new BIM file. Although it is technically feasible to blockchain an 102
entire model and its history, e.g., using the MD5 hash value of a model, users have to spend 103
considerable time and Internet bandwidth to synchronize a new BIM file. Managing changes, 104
especially those made simultaneously by different stakeholders, is notoriously difficult using 105
existing centralized and cloud BIM platforms (e.g., BIM 360), let alone in decentralized, widely 106
distributed ledgers. Finding a novel way to minimize information redundancy is a fundamental 107
challenge to harnessing the power of BIM and blockchain integration. 108
109
This paper aims to develop an innovative semantic differential transaction (SDT) approach to 110
minimizing information redundancy. This approach is applicable to Industry Foundation 111
Classes (IFC), the de facto open information standard ensuring interoperability across different 112
BIM platforms, and is based on capturing BIM changes, safeguarding them in a blockchain, 113
4
and restoring them when needed. The remainder of the paper is organized as follows. Section 114
2 reviews the literature on information change management in a BIM context, and Section 3 115
reviews blockchain technologies and their promise in construction. Section 4 presents the SDT 116
approach with its three components: a semantic interoperability method, an SDT model, and a 117
BIM change contract (BCC). The SDT approach is further illustrated and validated in two pilot 118
studies in Section 5. The novelties and shortcomings of the approach are discussed in Section 119
6, and conclusions drawn in Section 7. 120
121
2 BIM interoperability and IFC 122
The kernel of BIM is information (Lu et al. 2018), and the product is a 3D or nD digital model 123
of physical and functional characteristics of a facility. This model contains various digital 124
components or objects. In the back end, BIM consists of clustered arrays of information, e.g., 125
organized in a BIM file or a database. The information comprises geometric and non-geometric 126
semantics (Jung & Joo 2011; Xue et al. 2018b). The geometric semantics describe the sizes, 127
volumes, shapes, and textures of individual BIM objects, while the non-geometric semantics 128
describe less visible but arguably more meaningful attributes such as functions, behavior, cost, 129
and maintenance history (Pratt 2004). BIM was developed with a view to providing a one-truth 130
information source facilitating communication amongst stakeholders such as clients, designers, 131
engineers, contractors, and suppliers. However, the models can be developed or enriched by 132
different stakeholders using BIM authoring tools, and neither the digital models nor the back-133
end databases lend themselves to easy communication among these stakeholders. Therefore, 134
interoperability of different stakeholders’ models is highly desired (Eastman et al. 2011) to 135
provide the data foundation for BIM-based project collaboration and decision-making (Taylor 136
& Bernstein 2009). While the industry is reinforcing proprietary BIM platforms and solutions, 137
an open BIM standard is the key to interoperability. 138
139
IFC is an open data exchange schema that facilitates BIM interoperability in the architecture, 140
engineering, and construction (AEC) industry, with ISO certifications such as 16739:2013 and 141
16739-1:2018. Developed by buildingSMART International, IFC defines BIM objects using an 142
EXPRESS (ISO 10303-11)-based entity-relationship model and saves the BIM model in the 143
STEP (Standard for the Exchange of Product model, ISO 10303-21) file format with the .ifc file 144
extension. The latest version of IFC now consists of more than 600 entities organized into an 145
object-based inheritance hierarchy (buildingSMART 2019). Figure 1 illustrates parts of the IFC 146
schema (Version 4, Addendum 2), which is the meta-model of how the standardized IFC data 147
(e.g., objects identities, semantics, relations, and concepts) are organized (buildingSMART 148
2019). IfcRoot is at the top-most abstract level. Derived from it are three fundamental IFC model 149
entity types: IfcObjectDefinition capturing semantically treated tangible object items (e.g., 150
products, processes, and resources); IfcPropertyDefinition, which defines the characteristics of 151
both general object types and specific object occurrences; and IfcRelationship assigning 152
property information to the corresponding BIM objects while specifying the relationships 153
among objects. IFC has been widely adopted as a general standard and is supported by many 154
5
BIM software vendors (Ali & Mohamed 2017; Gao et al. 2017), and is thus the focus of this 155
paper in integrating open BIM and blockchain. 156
157
158
Figure 1. Part of the IFC schema (Version 4, Addendum 2) 159
160
Information redundancy is a problem of continuous BIM data exchange using IFC. The 161
redundancy is rooted in two aspects: STEP format’s sequential identifiers (STEP #-Ids) in each 162
line, and the cross-referencing of IFC objects’ generated globally unique identifiers (GUIDs). 163
The STEP #-Ids are sometimes randomly generated for IFC objects, which leads to considerable 164
byte-level inconsistency in the .ifc files. An IFC object’s GUID ought to be unique and 165
consistent through the BIM lifecycle. However, many GUIDs, regardless of the complex 166
references and relations anchored between them, are randomized on the mainstream BIM 167
platforms. For example, Autodesk Revit retains the GUIDs of IFC objects that are associated 168
with a unique “ElementID,” such as doors (IfcDoor), but randomizes the GUIDs of other objects 169
such as a door’s properties (IfcPropertySet). As a result, one small change in a BIM model, or 170
even no change at all, can result in a considerably different IFC file. With these randomly 171
assigned GUIDs, together with the complex hierarchical structures, BIM objects become very 172
difficult to trace and compare when massive files are exchanged. In contrast to the line-by-line 173
STEP structure, modern tree-like data structures, e.g., in JavaScript Object Notation (JSON) 174
and eXtensible Markup Language (XML), have higher computational efficiency and 175
explainability. Thus, buildingSMART (2020) has developed other IFC formats such as 176
IFCXML based on STEP-XML standard (ISO 10303-28), IFC-ZIP, IFC-JSON, and IFC-177
SQLite. Some new IFC formats, such as IFCXML, have eliminated the inconsistency from 178
STEP #-Ids, though introducing some other types of byte-level inconsistency; E.g., 179
“<Tag></Tag>” and “<Tag />” are equivalent in XML but different in the byte level. 180
181
The global AEC community has endeavored to minimize information redundancy by 182
comparing BIM changes in IFC files. Lee et al. (2011) used a “flattening” method, decoding 183
the relations and nesting all the referenced definitions to form a full description for an IFC 184
instance. Oraskari & Törmä (2015) developed a Short Paths Crossings Algorithm (SPCA) to 185
detect the changes between IFC-derived graphs. Afsari et al. (2017) confirmed the possibility 186
of serializing IFC objects in the JSON format, which is better supported by modern 187
6
programming languages. Shi et al. (2018) investigated the content rather than flattening and 188
developed similarity index software; Shafiq & Lockley (2018) suggested looking into the 189
‘signature’ of IFC objects; Lin & Zhou (2020) implemented a hash code for quick detection of 190
BIM changes in Autodesk Revit; and Li et al. (2020) presented a Tversky similarity-based 191
method for querying IFC objects based on their semantic attributes. Froese (2003) pinpointed 192
another research direction as the GUID-based transactional IFC exchange on distributed 193
systems, beyond the file-based exchange. Later, buildingSMART started to develop the BIM 194
Collaboration Format (BCF) standard of IFC model servers. Jørgensen et al. (2008) 195
demonstrated an IFC model server with code version-control functions such as “check out” and 196
“check in” for editing a subset of the IFC objects with GUIDs; Lee et al. (2014) confirmed 197
object-relational databases could improve the querying performance of such servers. Such 198
GUID-based transactional exchanges of IFC semantics are becoming increasingly important in 199
real-time applications such as virtual reality (Du et al. 2018). In short, BIM objects should be 200
assigned their semantic meanings and associated with specific GUIDs rather than random ones 201
to reduce redundancy and improve interpretability. 202
203
Two essential characteristics of BIM change management inspired this study: (a) the 204
incremental nature of BIM changes, and (b) the systematic nature of BIM semantics. Similar to 205
a Lego stacking process, BIM is developed element by element and phase by phase (Figure 2a). 206
This presents an opportunity to distinguish and blockchain the model development cycle as 207
incremental changes rather than recording the entire model every time a change is made. BIM 208
files are organized in a meaningful way (Figure 2b), and the task of comparing and capturing 209
model changes should focus not on the byte level but the semantic level: the meanings, 210
systematic relations, and their hierarchies. Wang and Meng (2019) regard semantics as the key 211
to managing not only BIM but also other construction processes and knowledge. However, how 212
to identify the incremental semantic changes automatically in BIM, especially for IFC, is yet to 213
be satisfactorily explored by the literature. 214
215
216
Figure 2. The incremental and systematic nature of BIM. (a) Incremental development (Ellis 217
2019); (b) Example relation system between IFC instances (Borrmann et al. 2018) 218
7
219
3 Blockchain in construction 220
Blockchain has recently received construction industry attention for its payment, procurement, 221
supply chain, BIM, and smart asset management potential. For example, Dakhli et al. (2019) 222
propose that blockchain could help achieve a saving of 8.3% of the total cost of residential 223
construction. Allam and Jones (2019) have investigated blockchain potential for air rights 224
development as an urban sprawl prevention measure, and Li et al. (2019) and Wang et al. (2020) 225
establish technical frameworks for blockchain in the construction industry. Nevertheless, 226
empirical blockchain studies for construction have been limited, with Perera et al. (2020) 227
finding barriers such as digital asset privacy and scalability in construction and the 50% 228
vulnerability in blockchain technology. Industrial reports such as Kinnaird et al. (2017) and 229
Penzes (2018) focus more on the potential value-added applications of BIM, blockchain and 230
their integration for smart contracts and quality assurance. Recent construction scandals, e.g., 231
fake concrete tests in the Hong Kong-Zhuhai-Macau bridge (SCMP 2017) and corner-cutting 232
in the Hung Hom MTR Station construction (SCMP 2019), have led to calls for the use of 233
blockchain to safeguard building information for provenance and forensic investigation 234
purposes. Whether BIM and blockchain integration should occur seems to be no longer 235
debatable, and now the industry should move beyond envisioning such an integrated system to 236
actually constructing one that is genuinely operable. 237
238
Unlike conventional file systems or relational databases, blockchain adopts a distributed data 239
architecture. Three components support its function, namely, cryptographic algorithms, a 240
distributed database, and a decentralized consensus mechanism (Hawlitschek et al. 2018). 241
Cryptographic algorithms, e.g., Secure Hash Algorithms (SHA), are used to encrypt 242
transactional data based on the agreed blockchain protocol (Beck et al. 2016). The algorithms 243
promise that it is practically impossible to derive the original data from the generated ciphertext. 244
The data is then appended to a chain of data blocks with cryptographic inter-connections (Gipp 245
& Breitinger 2016). The distributed database and decentralized consensus mechanism are 246
rooted in early work on homogeneous distributed database systems (Breitbart et al. 1986). 247
These systems, such as cloud services and distributed database engines, are now widely 248
available (Özsu & Valduriez 2020). Due to the distributed nature of the data, no third party is 249
entrusted with responsibility for its validation and management. Instead, all nodes collect the 250
transactions into a new block and work on the consensus protocols, such as proof of work (PoW) 251
and proof of stake (PoS), to validate the transaction systems (Notheisen et al. 2017). 252
253
Blockchain is built on an information redundancy mechanism that deliberately sacrifices 254
efficiency and speed to achieve its designated merits of immutability and decentralization (Wüst 255
& Gervais 2018). Although to the best of our knowledge there is no literature investigating its 256
exact extent, one can easily imagine duplication in a blockchain as it encrypts pieces of 257
information chained with hash codes and distributes them to decentralized ledgers in different 258
peers. While computer storage space and Internet speed are increasingly affordable, one must 259
8
consider information efficiency and speed when it comes to blockchaining BIM models. Our 260
industrial engagements have shown that these models, depending on project complexity and 261
Level of Development (LoD), are often too “sticky” to be maneuvered using remote Internet 262
computers. This explains why previous studies such as Zheng et al. (2019) only store BIM files’ 263
hashing signatures on chain and do not handle information redundancy in the models, with the 264
result that BIM interoperability still creates a massive amount of network traffic. 265
266
4 The proposed approach 267
The SDT approach to minimizing information redundancy developed in this paper is a 268
computational model of BIM changes over time. Calculating all the essential semantic changes 269
with minimized redundancy, it is an innovative means of mapping BIM onto blockchain, and 270
vice versa. The overall framework is shown in Figure 3. Three layers of the SDT approach 271
connect the distributed BIM systems to the Internet-based blockchain shell: (i) semantic 272
interoperability, (ii) the SDT model, and (iii) BIM change contract (BCC). The first layer 273
connects to the BIM, while the third plugs in blockchain’s distributed implementation. SDT 274
ignores all the semantically unchanged BIM objects and focuses on the changes only, handling 275
not only sequential changes but also distributed simultaneous changes for multi-stakeholder 276
BIM uses. 277
278
279
Figure 3. Framework of the proposed SDT approach for integrating blockchain and BIM 280
281
9
4.1 Semantic interoperability 282
This paper employs IFC as the target BIM format due to its openness and wide recognition. As 283
shown in Figure 3, the semantic interoperability layer focuses on three functions: semantic 284
hierarchy, de-randomization, and bi-directional operations between IFC and blockchain. 285
286
The semantic hierarchy function processes the STEP expressions, representing all the IFC 287
objects and their geometric and non-geometric properties, into systematic tree-like hierarchies. 288
For example, the type and style expression (e.g., of IfcWallType and IfcDoorStyle) can be 289
embedded into the physical BIM objects (e.g., IfcWall and IfcBuilding). The hierarchy 290
generation process removes partial randomized contents, such as the expressions’ line numbers 291
and some ad hoc relations. The embedding results are tree-like efficient data structures 292
compatible with IFC’s non-STEP formats such as IFCXML and Afsari et al.’s (2017) IFCJSON. 293
However, there is a trade-off between full explanatory power and computational efficiency. For 294
example, a material definition referred by twenty structural elements is better attached to a 295
“materials” hierarchy independent of the main hierarchy of building elements. 296
297
The de-randomization function aims to eliminate the remaining random contents to streamline 298
the semantic hierarchy. First, a selected list of attributes of software oracles, i.e., potential 299
names, are examined for each IFC object. For instance, Autodesk Revit can export its internal 300
object IDs into the Tag descriptors in IFC. Another example is the unique names such as Width 301
and Height defined in certain geometric property sets. In addition, the hashing function, which 302
is well known in blockchain, is a baseline method for mapping the semantic expression of an 303
object to a short, semantic content-only code if ultimately the expected attributes cannot be 304
found. By using such a priori identifier or the hashing function, an IFC object can be recognized 305
by a semantic identifier rather than the random GUID. Meanwhile, the references to the de-306
randomized objects can also be updated. 307
308
Bi-directional operability focuses on reconstructing IFC from the de-randomized semantic 309
hierarchy. In order to maintain reconstructability, there should be no semantic (excluding the 310
random contents) losses in the semantic hierarchy function, while auxiliary properties or 311
relations are allowed. The de-randomized semantic hierarchy can be re-randomized with new 312
standard STEP #-Ids to fit the IFC standard, though byte-level accuracy is not guaranteed. The 313
re-randomized IFC model should be semantically identical to the real one, e.g., the same 314
geometries and relations, though the byte-level contents can be considerably different. The bi-315
directional operability is thus more straightforward in the IFCXML format than the IFC STEP 316
format because there is less involvement of randomized contents. 317
318
4.2 Semantic differential transaction (SDT) model 319
The SDT model translates between the BIM changes in IFC and the SDT records on chain. So, 320
for example, if the BIM model’s semantic hierarchies were information “bank accounts,” an 321
IFC version history of the BIM semantics would be a long list of “bank transactions” of 322
10
“deposits/withdrawals.” Figure 4 shows the pseudo-code for computing the SDT from two 323
consecutive (i.e., slightly changed) models, i.e., ifc0 and ifc1, of a BIM project. First, the input 324
IFC models are read into two tree objects (i.e., σ0 and σ1 on Lines 1–2) of semantic hierarchies 325
through the semantic interoperability functions, so that the σ0 and σ1 are free from random 326
contents (both STEP #-Ids and GUIDs). Then, a quick comparison on Lines 3–5 removes the 327
unchanged IFC instances as the intersection tree from σ0 and σ1. The removal can considerably 328
expedite the M to N comparison of σ0c and σ1c, where M is the maximum branching size in the 329
changed semantic hierarchies σ0c, and N is that of σ1c. Finally, the SDT from σ0c to σ1c can be 330
computed as the difference between the two tree objects, through up-to-date tree comparison 331
algorithms (Line 6). Line 1 in Figure 4, i.e., σ0 ← σ1_previous, indicates the possible reuse of 332
previous semantic hierarchy to save time from IFC loading, parsing, and de-randomization. 333
334
335
Figure 4. Pseudo code of the SDT computation algorithm 336
337
As shown in Figure 5, SDT results consist of three types of changes: addition, change, and 338
deletion. An oracle ID is assigned to recognize the BIM object from multiple instances of the 339
same type. Two keywords “insert” and “delete” are preserved for indications, while a value pair 340
such as the item “Property3” stands for a changed property. If the property is an array of values, 341
all types of changes are in value pairs, with possible involvements of the empty JSON object 342
“{},” as shown in Figure 5. 343
344
345
Figure 5. JSON example of SDT records of BIM changes 346
347
11
The BIM semantic hierarchy can be restored at any time by adding up all the transactions to the 348
base model, i.e., σk = σ0 + Σi=1, 2, …, k Δσi, based on the bi-directional operability function in Sect. 349
4.1. The restoration is an inverse operation of the differential in Figure 4. With such data 350
structure, the restored BIM semantic hierarchy is computable for many BIM applications. 351
Because of the small sizes of the SDT records, the proposed approach can achieve minimal 352
information redundancy for BIM data exchange. 353
354
In order to track all the BIM changes in the development, the SDT computation in Figure 4 can 355
be regularly executed, e.g., every minute, or triggered by the task when the BIM project is saved. 356
In terms of disk (and memory) space, the saving will be considerable for large BIM projects; 357
one only needs an initial base model plus a time series of SDT records of the incremental 358
changes to represent the whole development history. Nevertheless, one has to spend time on 359
BIM restoration for the up-to-date or a historical version. Major version checkpoints, like 360
keyframes for video coding, can limit the extra time to a certain amount. Therefore, SDT 361
computation can offer a spectrum of trade-off options between the computational space and 362
time. 363
364
4.3 BIM change contract 365
The BIM change contract (BCC) in the SDT approach aims to provide a smart contract-like 366
protocol for integrating multiple BIM editors’ distributed SDT records for blockchain. Figure 367
6 shows the BCCs on a permissioned blockchain structure, i.e., with restricted access. Generally, 368
permissioned blockchain architectures are slightly preferred over permissionless ones for 369
management purposes, according to a PwC (2018) global survey. The BCC is a smart contract 370
protocol that involves three groups of elements in Figure 6: base models in the middle, the 371
interconnected blockchain nodes, and the stakeholders’ current BIM models with software and 372
hardware oracles. 373
374
12
375
Figure 6. Example blockchain architecture for BIM change contract over SDTs 376
377
A BCC concluded at time t, noted as BCCt, represents the overall BIM changes by all the 378
stakeholders between time t – 1 and t. Therefore, at time t, the base model (as shown in the 379
middle of Figure 6) is the initial BIM model with accumulated historical BCCs up to time t − 380
1, i.e., ifct-1 = ifc0 + Σt-1 BCCi. A special case is that the base model at t = 1 is the initial model 381
(ifc0), when no BCCs are stored in the blockchain. The base model is identical but is not 382
centralized or shared. Instead, it is computed, trusted, and cached by every stakeholder 383
individually on top of the trusted initial model (ifc0) and the trusted historical BCCs on the chain. 384
385
Each BIM stakeholder runs a blockchain node for conflict resolution and version control in the 386
permissioned architecture in Figure 6. Each blockchain node has the base model in its local 387
cache, a reserved memory space, and monitors the local changes regularly, as described in 388
Section 4.2. The local SDT records computed by the algorithm in Figure 4 only reflect the 389
stakeholder’s local BIM change. In a distributed BIM context, there can be conflicts in SDT 390
records submitted by different stakeholders simultaneously. The conflict resolution 391
mechanisms are thus necessary to conclude a contract on the overall changes. Conflict resolving 392
13
methods can be as complicated as Jäger’s (2018) directed acyclic graph (DAG) model for 393
Turing completeness, or simple divide-and-conquer of all BIM objects’ editorships to 394
designated stakeholders, e.g., all the air ducts to one sub-contractor. The latter mechanism leads 395
to a single version of the base BIM model, while the DAG approach may generate a major and 396
several minor versions. 397
398
Each stakeholder works on its current BIM model independently. For example, Stakeholder 1 399
updates the glass curtain wall of the lobby in BIM#1 in Figure 6, while Stakeholder 3 changes 400
a facade on the third floor in BIM#3. Both changes are tracked as local SDT records (indicated 401
in red boxes) and integrated into the BCC at time t. Due to the bi-directional operability of the 402
SDT model, other stakeholder’s SDT records can be restored immediately to updated BIM 403
objects based on the cached identical base BIM model. As a result, each stakeholder, including 404
Stakeholder 2 who makes no changes, can be aware of the non-local changes (indicated in blue 405
boxes) in the meantime. Software and hardware oracles in Figure 6 can automate the 406
identification of BIM objects in the construction processes and local SDT records. For example, 407
a software oracle is a good naming convention based on the hierarchy of BIM objects such as 408
the “function/type/vertical-location/horizontal-location/description” format (Chen et al. 2017). 409
An example of a hardware oracle is the Internet of Things attached to the construction elements 410
(Xue et al. 2018a). 411
412
4.4 Software implementation 413
We implement the SDT approach in Python (Ver. 3.7). Three classes, namely, Interop, 414
SdtModel, and BCContract, are created to realize the three layers in Figure 3, respectively. The 415
Interop class employs the ifcconvert tool (ver. 0.6, available at: http://ifcopenshell.org/) to 416
convert the IFC files to XML contents, and accepts IFCXML inputs as well. The difference 417
between the two is that IFCXML is lossless from IFC but redundant, while ifcconvert’s XML 418
export is concise but lossy. Then, the XML contents are reformatted to tree-like JSON objects 419
using the xmltodict library (ver. 0.12). The Python native hashing function is used as the 420
software oracle to represent an IFC instance’s semantic “signature” if no other oracles are 421
identified. The SdtModel class employs the jsondiff library (ver. 1.2, available at: 422
https://github.com/xlwings/jsondiff) to compare the differences between the JSON objects. The 423
BCContract class integrates local SDTs to homogeneous BCC. We implement a simplistic BCC 424
mechanism by ticking out all the conflicting SDT records from the major version BIM. This 425
simplistic BCC mechanism, rather than the complex contracts based on DAG, serves our proof-426
of-concept purpose. 427
428
5 Pilot study 429
5.1 Experimental settings 430
We employ two pilot cases to verify the proposed SDT approach. The first case, shown in 431
Figure 7a, involves the architect as the only stakeholder. An IFC wall with a 750mm x 1400mm 432
window at t0 is changed to a 1400mm x 1400mm window (circled) at t1 in this case. The GUIDs 433
14
in the IFC files were de-randomized by pre-processing to mitigate the randomization in the 434
computational tests. The second case, in Figure 7b, has two stakeholders, i.e., an architect and 435
a client, co-editing roof windows in a sample project in Autodesk Revit 2018. First, at t1 one 436
window on the roof was moved towards the living room to capture daylight. The window was 437
reverted to its original position by the client at t2. The client noted “Please keep this” in the 438
property “Comments” of the BIM object at t3. Also at t3, the architect added a new roof window 439
for the living room. Clearly, this case is more sophisticated than the first because it creates new 440
instances, changes non-geometric properties (e.g., text comments), and handles simultaneous 441
changes. The IFC versions of both cases were IFC 2x Edition 3 (2x3). The models in the second 442
case were exported to IFC immediately using Revit 2018’s native exporter once changed. We 443
also conducted auxiliary tests on IFCXML formats exported from the same IFC models via 444
xBIM Xplorer (ver. 4.0, https://docs.xbim.net /) Export function on a desktop computer with a 445
4-core Intel i5-6500 3.2GHz CPU and 8 GB memory. To avoid hard disk operation latency, a 446
500MB virtual hard disk was emulated in the memory. 447
448
449
Figure 7. Two pilot IFC cases. (a) A wall model with a changed window; (b) Collaborative 450
roof window design on a sample BIM project using Autodesk Revit 2018 451
452
5.2 Experimental results 453
Figure 8 shows the results of file difference and the SDT in the first case, already de-randomized. 454
We tested two formats of IFC inputs. The first is IFC, in which each file is 7.4KB and has a .ifc 455
extension. The SDT result was computed as a 0.36KB JSON object in 0.003s, as shown in Table 456
15
1. The JSON object correctly notes four semantic changes in the IFC, including file save time, 457
two changes of lengths in IfcElementQuantity (i.e., one for the window and the other for the 458
opening), and the OverallWidth of the only window. We compared the SDT results to the file 459
comparison method, which has a 1.00KB result of 6 changed lines in the IFC files in 0.041s. In 460
contrast, the IFCXML files with the “.ifcxml” extension are about four times larger than IFC on 461
disk. The SDT result contains six changed values, as shown in Table 1. The result is 0.89KB in 462
JSON, and the computational time 0.012s, four times that of the IFC test. The file comparison 463
cost 0.042s for a 0.56KB difference of six changed lines. To sum up, the proposed SDT can 464
correctly extract the semantic changes in IFC files, as well as IFCXML files, and achieve the 465
first directional interoperability (i.e., from IFC to SDT). 466
467
468
16
Tab l e 1 . Comparison of the IFC file difference and SDT results in the first de-randomized case 469
Input
Item
Line-by-line file comparison
The proposed SDT
IFC
(7.4KB
each)
Size (KB)
1.00
0.36
Time (s)
0.041
0.003
SH?*
Output
6 changed lines:
4 changed properties:
IFCXML
(32.9KB
each)
Size (KB)
0.56
0.89
Time (s)
0.042
0.012
SH?*
Output
6 changed lines:
6 changed properties:
*: With semantic hierarchies?
470
Table 2 shows the results of the second directional interoperability, i.e., IFC restoration from 471
SDT records, in the first case. The restoration utilizes the semantic hierarchy in SDT. In the 472
semantic hierarchy, the extract positions of all the changes are recorded in a tree-like data 473
structure. The restoration process is almost instant because of the small size of SDT records. 474
All restoration tests were completed in less than 0.0001s, which was much faster than the SDT 475
computation. With the IFC inputs, the restored XML of BIM semantics was 100% identical to 476
the expected values, though the semantic hierarchy was reformatted. However, the conversion 477
from XML to STEP failed due to lack of support from the ifcconvert library. With the IFCXML 478
inputs, the semantic hierarchies are more consistent, and the restoration resulted in 100% 479
correct IFC files in IFCXML and STEP formats. However, the correct files are not identical to 480
the expected IFC files at the byte level. The restored XML output has 86.0% lines identical to 481
those expected, while the restored STEP file has a mere 4.8%. The differences come from 482
alternative expressions in XML syntax and the re-randomization of IFC instances’ numbers (i.e., 483
the STEP #-Ids). In short, the changed IFC files can be restored from small SDT records and a 484
17
base model, particularly for IFCXML formats. 485
486
Table 2. Comparison of IFC restoration from SDT at t1 in the first case 487
Input
Item
Restored BIM
semantics (XML)
Restored IFC (STEP)
Ground truth IFC-STEP
file
IFC
Time (s)
< 0.001
(Not supported by
ifcconvert)
–
Byte-level
100% identical
–
Semantic
level
100% identical
–
Semantic
hierarchy
3D view
IFCXML
Time (s)
< 0.001
< 0.001
–
Byte-level
86.0%* identical
4.8%# identical
–
Semantic
level
100% identical
100% identical
–
Semantic
hierarchy
3D view
*: Due to flexible XML syntax, e.g., “<Tag></Tag>” and “<Tag />” are equivalent but different in bytes.
#: The STEP #-Ids in the “.ifc” files were re-randomized, e.g., Sample Site’s #28 was restored as #77.
488
The second case is very close to a real-world BIM project. Tests of the four local changes were 489
conducted first. As listed in Table 3, each input IFC file exported from Autodesk Revit becomes 490
18
about 27.4MB. The SDT approach spent around 6.66–7.00s (over 90% of the time) converting 491
the input IFC models to JSON, i.e., algorithm Lines 1–2 in Figure 4. The results showed the 492
SDT time consumption increased almost linearly from Case 1 to Case 2, i.e., from 0.003s for 493
7.4KB to 7.00s for 27.4MB, for IFC files based on ifcconvert function. The SDT computational 494
time (algorithm Lines 3–6) is less than 0.5s, comparable with the file comparison method. The 495
SDT results win in several aspects. First, there is minimal redundancy. For instance, local 496
changes to the roof window (moving, reverting, and writing comments) were extracted as small 497
(0.34–0.47KB) SDT outputs in JSON, while the addition of a new window was concluded as a 498
3.37KB output. All the SDT outputs were less than 0.02% of the IFC models, and small enough 499
for blockchain systems. It is worth noting that the SDT outputs, even though small, incorporate 500
the IFC semantic hierarchies. In contrast, the comparison of IFC files resulted in an unnecessary 501
amount of changed lines and huge files without pre-processing for de-randomization. The sizes 502
were almost twice the input file size in three out of four changes, indicating failures of 503
meaningful change detection. We also tested Shi et al.’s (2018) IFCdiff method in the second 504
case, with no result in any local changes in three hours. In summary, the SDT approach can 505
effectively (correctly) and efficiently (in small file sizes and short time) detect local IFC 506
changes. 507
508
Tab l e 3. Results of IFC file difference and the proposed SDT in the second case 509
Input Change
Line-by-line file comparison
The proposed SDT
Size (KB)
(lines)
Time
(s)* SH?#
Size
(KB)
Interop.
time (s)*
SDT
time (s)* SH?#
IFC
(27.4MB
each)
t
0
→ t
1
11,400
(99,369)
0.398
0.47
6.664
0.435
t
1
→ t
2
55,000
(538,443)
0.784
0.47
6.641
0.463
t
2
→ t
3
(Arch.)
54,700
(533,923)
0.789
3.37
6.681
0.414
t
2
→ t
3
(Client)
53,900
(514,192)
0.756
0.34
7.004
0.411
IFCXML
(141.7MB
each)
All$ (Exceeded memory limit)
(Program halted by authors after waiting
for three-hour execution)
*: Average of 10 runs; #: With semantic hierarchy or not?; $: All changes failed in the tests.
510
Similar crashes and failures were observed in the IFCXML tests for the second case. Neither 511
the SDT approach nor the plain comparison method returned results in comparing the four pairs 512
of 141MB IFCXML files. One key reason is that IFCXML is scrupulous but too lengthy. For 513
example, an IfcWindow’s ObjectPlacement property is a 4x4 transformation matrix. That 514
property can be a pre-computed finalized 4x4 matrix, such as “[-0.798636 -0.601815 0 0 … -515
18094.7 -16609.2 4610.17 1]” (111 bytes) in IfcOpenShell; in contrast, the same property in 516
IFCXML included 106 XML lines (4,231 bytes) by referring to 4 instances of 517
19
IfcLocalPlacement, 4 instances of IfcAxis2Placement3D, 4 instances of IfcCartesianPoint, 3 518
instances of IfcDirection, and 12 instances of IfcLengthMeasure. By tracing the iterations of 519
the failed SDT tests on the IFCXML inputs, we found the problem was an unexpectedly lengthy 520
comparison task, which involved solving a longest common subsequence (LCS) problem 521
between two lists of 140,833 IfcCartesianPoints. The complexity of the problem exceeded the 522
classical algorithm’s capacity, which has an O(n²) time complexity (billions of comparisons in 523
this case). To sum up, the SDT approach using ifcconvert works for industrial-level IFC cases, 524
while IFCXML inputs are appropriate for blockchaining small-scale BIM cases, but 525
inappropriate for large-scale cases until novel comparison algorithms are developed. 526
527
Figure 8 shows the result of the BCC test for the second case. Between t2 and t3, the blockchain 528
nodes of the architect and the client computed local SDT records. The architect’s SDT records 529
mainly involve four parts. The first is the changed time of file save; the next two are about the 530
properties of the changed roof elements and the new roof window; and the final part describes 531
the semantics of the new roof window instance, including all the properties and references. The 532
client’s SDT record, as shown in Figure 8, contains a short section of the newly added comment 533
beside the changed time block. The final BCC is a 3.45KB JSON expression, integrating the 534
blue and green parts into the IFC semantic hierarchy and excluding the conflicted date changes. 535
The BCC on the IFC semantic hierarchy can be applied to compute the BIM model in consensus 536
for all the stakeholders based on the IFC model on t2. 537
538
539
Figure 8. Results of BIM change contract test for the second case (t2→ t3). 540
541
5.3 Simulation on a minimal blockchain 542
We uploaded the experimental results in the second case on a minimalized blockchain for proof-543
of-concept validation of the compatibility of the SDT approach. The blockchain structure is a 544
20
distributed blockchain with the essential functions run on a webpage 545
(https://andersbrownworth.com/blockchain/distributed). As shown in Figure 9a, each 546
blockchain peer independently stores the three BCCs in three blocks at t1, t2, and t3. Each block 547
refers to the previous one by including the previous hashing value, as indicated by the blue 548
arrows in Figure 9a. As a result, the BIM changes, including the moving, reverting, addition, 549
and comments, can be recorded with timestamps and managed in a distributed manner with 550
minimal redundancy. The time series of BIM changes are fundamental for managing BIM 551
versions. In addition, the blockchained BCCs become immutable. For example, Figure 9b 552
shows that a falsification of BIM change can be detected at t2 in the mismatch between the 553
block content and its hashing value (underlined in red). Such BIM falsifications should be rare 554
but possible, e.g., for claiming false authorships, destroying evidence, or being hacked. 555
Nonetheless, the correct SDT blocks and the blockchain continued working among other peers 556
in the consortium blockchain while the problematic peer was identified and refused by the 557
consortium network. 558
559
21
560
Figure 9. Simulation of SDT results in the second case on a minimal blockchain. (a) Distributed 561
blockchain storage of BCCs; (b) Falsification detection 562
563
6 Discussion 564
There are five aspects to the novelty of our SDT approach, as follows. 565
• Firstly, the information safeguarded in a blockchain is significantly reduced by 566
capturing BIM changes instead of entire BIM files. In our pilot tests, the version history 567
of BIM changes was captured and placed in a blockchain with only around 0.02% of 568
the BIM file size, satisfactorily addressing the challenge of information redundancy in 569
BIM and blockchain integration. 570
• Secondly, our SDT approach possesses an elegant architecture with three succinct layers: 571
(1) semantic interoperability; (2) SDT model; and (3) BCC mechanism. This 572
22
architecture and its included functions represent several original ideas not seen in 573
previous research. 574
• Thirdly, our research takes IFC as a point of departure. IFC is the de facto open standard 575
ensuring interoperability across different commercial BIM platforms and empowering 576
open BIM. However, IFC has its shortcomings. One is the randomization of its identities, 577
which adds to the difficulty of comparing and identifying BIM changes. The semantic 578
interoperability layer of our SDT approach satisfactorily develops de-randomization 579
functions and adopts modern data structures to allow bi-directional operations between 580
IFC and blockchain. Specifically, SDT computation can be done in near real time, while 581
IFC restoration from SDT is in real time. 582
• Also novel is the SDT core developed to identify the BIM changes and assemble them 583
in a time series of SDT records. The algorithm of the SDT core is light and lean, suitable 584
for performing heavy computation to identify BIM changes throughout its service life. 585
• Lastly, our research develops a BCC layer to realize the smart contract-type protocol in 586
blockchain. This layer can deal with simultaneous BIM changes (i.e., SDT records) by 587
different BIM stakeholders and reach a consensus on the global changes before 588
integration into a blockchain. 589
590
Despite these innovations, our research is not free from limitations. 591
• Firstly, some parts of the SDT approach are not perfect, such as the conflict-resolving 592
mechanisms to achieve the BCC. We expect to develop more sophisticated models such 593
as DAG-based reasoning for the BCC in the future. 594
• Secondly, only limited pilot case studies were conducted. The experiments and the 595
results, therefore, can only be treated as a proof of concept of the SDT approach, rather 596
than a final version for benchmarking performance, or proof of extensibility and 597
compatibility to other construction projects. Future tests should be conducted in more 598
diverse projects. 599
• Thirdly, the pilot case studies were conducted on a distributed blockchain with basic 600
functions running on a webpage. It is expected that future research should incorporate 601
real blockchain shells, e.g., a permissioned consortium structure. On top of that, a 602
relevant yet unexplored question is the types of blockchain (e.g., public or private) 603
appropriate to a project-based setting such as that of construction. 604
• Next, the SDT approach is applicable to the IFC format. However, efficiency in 605
computing IFCXML is not satisfactory for large-scale BIM projects. One reason is the 606
O(n²) optimization of the LCS problem. With proper algorithmic modifications, such as 607
an approximate algorithm returning 1% redundant results with a sheer O(n log n) time 608
complexity, the approach can be applied to prevailing commercial BIM software 609
platforms. Future research work can be directed to developing efficient IFCXML 610
computation modules and plugins for these commercial BIM platforms as a way to 611
promote BIM and blockchain integration. 612
23
• The SDT model in this paper focuses on a whole IFC file. Yet, the time spent for large-613
scale projects was still unsatisfactory, e.g., over 7 seconds for the tests on Case 2. We 614
noticed that most of the time was consumed by the semantic interoperability layer to 615
understand IFC files. One possible solution is to record the BIM changes directly from 616
BIM software, e.g., Lin and Zhou’s (2020) hashing code for Autodesk Revit, with a 617
semantic interoperability add-in that monitors the BIM changes in real time. The de-618
randomization process in the semantic interoperability layer can be omitted when BIM 619
software can offer a whole lifecycle GUID naming system for all types of IFC objects, 620
including structural elements, materials, and relations. 621
• Lastly, we would like to stress that the SDT approach is not the only approach for 622
minimizing information redundancy for BIM and blockchain integration. There are 623
other approaches, such as open BIM web service (van Berlo 2015), the BCF standard, 624
and the ‘signature’ of IFC objects (Shafiq & Lockley 2018) awaiting development. 625
626
7 Conclusion 627
By providing rich semantics of the physical and functional characteristics of a building to 628
facilitate communication and decision-making amongst stakeholders, BIM can alleviate 629
problems related to time, quality, cost, and productivity in construction. Also attractive to the 630
construction industry is blockchain technology, which safeguards important information in 631
immutable, cryptographic, and decentralized ledgers. The integration of BIM and blockchain 632
has enormous potential to enable value-added applications but faces numerous technological 633
hurdles, one of which is information redundancy. The volume of information in a BIM increases 634
dramatically when developed and represented in IFC format, and then reaches an overwhelming 635
level of redundancy when duplicated, encrypted, and distributed in blockchain. Minimizing this 636
information redundancy is a fundamental challenge for BIM and blockchain integration. 637
638
This study reports a novel Semantic Differential Transition (SDT) model to capture and 639
blockchain BIM changes instead of entire BIM files, thereby minimizing information 640
redundancy and supporting BIM and blockchain integration. Our SDT approach has three 641
function layers. First, the BIM interoperability layer extracts the BIM semantics from IFC files, 642
applying de-randomization and modern data structures such as JSON objects. The SDT layer 643
then computes the semantic difference, instead of file difference, in a short time and forms a set 644
of local SDTs. The BCC layer offers blockchain a smart contract, e.g., DAG model of versions 645
or designated subsystem editorships, to cope with sequential and simultaneous local SDTs. We 646
demonstrated the proposed model in two IFC cases for blockchain BIM systems. The 647
experimental results confirmed that SDT is effective (correct) and efficient (less than 0.02% 648
BIM file size, in near real-time) for blockchain BIM systems. By following this innovative SDT 649
approach, researchers and practitioners alike can develop truly operable BIM and blockchain 650
integration solutions. 651
652
24
Future research work could improve this SDT approach. For example, the de-randomization 653
and JSON objects are rather innovative but are more tied to IFC and STEP formats, which are 654
involved in relatively ineffective identifier management. Perhaps in the long run, researchers 655
need to work with IFC stakeholders to improve the consistencies for both BIM objects’ GUIDs 656
and STEP #-Ids ordering. Directed acyclic graph (DAG)-based reasoning could be a more 657
accurate solution than that reported in this paper to realize BCC. More empirical tests on real-658
life BIM cases with different LoD and project complexities are expected to gauge the 659
performance of the SDT approach further. Going beyond the SDT, domain-specific blockchain 660
structures for construction projects could also be critical to realizing real-life blockchain BIM 661
systems. 662
663
Acknowledgements 664
The authors would like to acknowledge the financial support by the Hong Kong Research Grant 665
Council (Grant No. 17201717) and partial support by Department of Science and Technology 666
of Guangdong, China (Grant No. 2019B010151001). We wish to express our gratitude to the 667
anonymous reviewers for their constructive comments to improve the quality of the paper. 668
References 669
Afsari, K., Eastman, C. M. & Castro-Lacouture, D. (2017). JavaScript Object Notation (JSON) 670
data serialization for IFC schema in web-based BIM data exchange. Automation in 671
Construction, 77, pp. 24-51. doi:10.1016/j.autcon.2017.01.011 672
Ali, M. & Mohamed, Y. (2017). A method for clustering unlabeled BIM objects using entropy 673
and TF-IDF with RDF encoding. Advanced Engineering Informatics, 33, pp. 154-163. 674
doi:10.1016/j.aei.2017.06.005 675
Allam, Z. & Jones, D. S. (2019). The potential of blockchain within air rights development as 676
a prevention measure against urban sprawl. Urban Science, 3(1), Article ID 38. 677
doi:10.3390/urbansci3010038 678
Beck, R., Czepluch, J. S., Lollike, N. & Malone, S. (2016). Blockchain–The gateway to trust-679
free cryptographic transactions. Proceedings of 2016 European Conference on 680
Information Systems. Association for Information Systems. Retrieved March 9, 2020, 681
from https://aisel.aisnet.org/ecis2016_rp/153 682
Borrmann, A., Beetz, J., Koch, C., Liebich, T. & Muhic, S. (2018). Industry Foundation Classes: 683
A standardized data model for the vendor-neutral exchange of digital building models. 684
In B. A., K. M., K. C. & B. J., Building Information Modeling (pp. 81-126). Cham, 685
Switzerland: Springer. doi:10.1007/978-3-319-92862-3_5 686
Breitbart, Y., Olson, P. L. & Thompson, G. R. (1986). Database integration in a distributed 687
heterogeneous database system. 1986 IEEE Second International Conference on Data 688
Engineering (pp. 301-310). IEEE. doi:10.1109/ICDE.1986.7266234 689
buildingSMART. (2019). Industry Foundation Classes Version 4.2 bSI Draft Standard. 690
Retrieved March 9, 2020, from 691
https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/ 692
25
buildingSMART. (2020). IFC Formats. buildingSMART International. Retrieved March 9, 693
2020, from https://technical.buildingsmart.org/standards/ifc/ifc-formats/ 694
Chen, K., Lu, W., Wang, H., Niu, Y. & Huang, G. G. (2017). Naming objects in BIM: A 695
convention and a semiautomatic approach. Journal of Construction Engineering and 696
Management, 143(7), Article ID 06017001. doi:10.1061/(ASCE)CO.1943-697
7862.0001314 698
Dakhli, Z., Lafhaj, Z. & Mossman, A. (2019). The Potential of Blockchain in Building 699
Construction. Buildings, 9(4), Article ID 77. doi:10.3390/buildings9040077 700
Du, J., Zou, Z., Shi, Y. & Zhao, D. (2018). Zero latency: Real-time synchronization of BIM data 701
in virtual reality for collaborative decision-making. Automation in Construction, 85, pp. 702
51-64. doi:10.1016/j.autcon.2017.10.009 703
Eastman, C. M., Eastman, C., Teicholz, P., Sacks, R. & Liston, K. (2011). BIM Handbook: A 704
guide to building information modeling for owners, managers, designers, engineers and 705
contractors (2nd ed.). ISBN 9780470541371, John Wiley & Sons. 706
Egan, J. (1998). Rethinking construction. London, UK: Department of the Environment, 707
Transport and Regions. Retrieved April 19, 2020, from 708
https://webarchive.nationalarchives.gov.uk/20040722115001/http://www.dti.gov.uk/co709
nstruction/rethink/report/index.htm 710
Ellis, M. (2019, July 12). Level of Detail or Development: LOD in BIM. Retrieved November 711
6, 2019, from REBIM: https://rebim.io/level-of-detail-or-development-lod-in-bim/ 712
Froese, T. (2003). Future directions for IFC-based interoperability. Journal of Information 713
Technology in Construction, 8(17), pp. 231-246. Retrieved March 9, 2020, from 714
https://www.itcon.org/2003/17 715
Gao, G., Liu, Y. S., Lin, P., Wang, M., Gu, M. & Yong, J. H. (2017). BIMTag: Concept-based 716
automatic semantic annotation of online BIM product resources. Advanced Engineering 717
Informatics, 31, pp. 48-61. doi:10.1016/j.aei.2015.10.003 718
Gipp, B. K. & Breitinger, C. (2016). Securing video integrity using decentralized trusted 719
timestamping on the Bitcoin blockchain. Proceedings of 2016 Mediterranean 720
Conference on Information Systems, (p. 51). Retrieved March 9, 2020, from 721
https://aisel.aisnet.org/mcis2016/51 722
Hawlitschek, F., Notheisen, B. & Teubner, T. (2018). The limits of trust-free systems: A 723
literature review on blockchain technology and trust in the sharing economy. Electronic 724
Commerce Research and Applications, 29, pp. 50-63. doi:10.1016/j.elerap.2018.03.005 725
ICE. (2019). Supply chains in construction. Institute of Civil Engineers. Retrieved March 9, 726
2020, from https://www.designingbuildings.co.uk/wiki/Supply_chains_in_construction 727
Jäger, M. (2018). VCS 4 CDE–Version control systems as common data environments. Munich, 728
Germany: Technical University of Munich. Retrieved March 9, 2020, from 729
https://www.cms.bgu.tum.de/images/teaching/abim_seminar/Report_J%C3%A4ger_V730
CS_as_CDE.pdf 731
Jørgensen, K., Skauge, J., Christiansson, P., Svidt, K., Sørensen, K. B. & Mitchel, J. (2008). 732
Use of IFC model servers: Modelling collaboaration possibilities in practice. Aalborg, 733
26
Denmark: Aalborg University. Retrieved March 9, 2020, from 734
https://www.kaj.person.aau.dk/digitalAssets/199/199580_12176_reportifcmodelserver735
-final.pdf 736
Jung, Y. & Joo, M. (2011). Building information modelling (BIM) framework for practical 737
implementation. Automation in Construction, 20(2), pp. 126-133. 738
doi:10.1016/j.autcon.2010.09.010 739
Kinnaird, C., Geipel, M. & Bew, M. (2017). Blockchain technology: how the inventions behind 740
bitcoin are enabling a network of trust for the built environment. London, UK: Arup. 741
Retrieved February 1, 2020, from https://www.arup.com/-742
/media/arup/files/publications/b/arup--blockchain-technology-report_comp.pdf 743
Laan, A., Noorderhaven, N., Voordijk, H. & Dewulf, G. (2011). Building trust in construction 744
partnering projects: An exploratory case-study. Journal of Purchasing and Supply 745
Management, 17(2), pp. 98-108. doi:10.1016/j.pursup.2010.11.001 746
Larsson, J., Eriksson, P. E., Olofsson, T. & Simonsson, P. (2014). Industrialized construction in 747
the Swedish infrastructure sector: core elements and barriers. Construction 748
Management and Economics, 32(1-2), pp. 83-96. doi:10.1080/01446193.2013.833666 749
Lee, G., Jeong, J., Won, J., Cho, C., You, S. J., Ham, S. & Kang, H. (2014). Query performance 750
of the IFC model server using an object-relational database approach and a traditional 751
relational database approach. Journal of Computing in Civil Engineering, 28(2), pp. 752
210-222. doi:10.1061/(ASCE)CP.1943-5487.0000256 753
Lee, G., Won, J., Ham, S. & Shin, Y. (2011). Metrics for quantifying the similarities and 754
differences between IFC files. Journal of Computing in Civil Engineering, 25(2), pp. 755
172-181. doi:10.1061/(ASCE)CP.1943-5487.0000077 756
Li, J., Greenwood, D. & Kassem, M. (2019). Blockchain in the built environment and 757
construction industry: A systematic review, conceptual models and practical use cases. 758
Automation in Construction, 102, pp. 288-307. doi:10.1016/j.autcon.2019.02.005 759
Li, N., Li, Q., Liu, Y. S., Lu, W. & Wang, W. (2020). BIMSeek++: Retrieving BIM components 760
using similarity measurement of attributes. Computers in Industry, 116, Article ID 761
103186. doi:10.1016/j.compind.2020.103186 762
Lin, J. R. & Zhou, Y. C. (2020). Semantic classification and hash code accelerated detection of 763
design changes in BIM models. Automation in Construction, 115, Article ID 103212. 764
doi:10.1016/j.autcon.2020.103212 765
Lu, W., Lai, C. C. & Tse, T. (2018). BIM and big data for construction cost management. New 766
York, NY, USA: ISBN 9781351172301, Routledge. 767
Molloy, O., Warman, E. A., Tilley, S. & . (2012). Design for Manufacturing and Assembly: 768
Concepts, architectures and implementation. ISBN 9780412781902, Springer. 769
doi:10.1007/978-1-4615-5785-2 770
NIBS. (2015). National BIM Standard - United States V3. National Institute of Building 771
Sciences, USA. Retrieved March 9, 2020, from https://www.nationalbimstandard.org/ 772
Notheisen, B., Cholewa, J. B. & Shanmugam, A. P. (2017). Trading real-world assets on 773
blockchain. Business & Information Systems Engineering, 59(6), pp. 425-440. 774
27
doi:10.1007/s12599-017-0499-8 775
Oraskari, J. & Törmä, S. (2015). RDF-based signature algorithms for computing differences of 776
IFC models. Automation in Construction, 57, pp. 213-221. 777
doi:10.1016/j.autcon.2015.05.008 778
Özsu, M. T. & Valduriez, P. (2020). Principles of distributed database systems. Cham, 779
Switzerland: ISBN 9781441988331, Springer. doi:10.1007/978-1-4419-8834-8 780
Penzes, B. (2018). Blockchain technology in the construction industry: Digital transformation 781
for high productivity. London, UK: Institute of Civil Engineers. Retrieved March 9, 782
2020, from 783
https://www.ice.org.uk/ICEDevelopmentWebPortal/media/Documents/News/Blog/Blo784
ckchain-technology-in-Construction-2018-12-17.pdf 785
Perera, S., Nanayakkara, S., Rodrigo, M. N., Senaratne, S. & Weinand, R. (2020). Blockchain 786
technology: Is it hype or real in the construction industry? Journal of Industrial 787
Information Integration, 17, Article ID 100125. doi:10.1016/j.jii.2020.100125 788
Pratt, M. J. (2004). Extension of ISO 10303, the STEP standard, for the exchange of procedural 789
shape models. Proceedings of Shape Modeling Applications 2004 (pp. 317-326). IEEE. 790
doi:10.1109/SMI.2004.1314519 791
PwC. (2018). Global Blockchain Survey 2018: Blockchain is here. What’s your next move? 792
PricewaterhouseCoopers (PwC) China. Retrieved February 1, 2020, from 793
https://pwc.to/37LRuMK 794
Risius, M. & Spohrer, K. (2017). A blockchain research framework. Business & Information 795
Systems Engineering, 59(6), pp. 385-409. doi:10.1007/s12599-017-0506-0 796
SCMP. (2017, May 23). Officers arrest 21 over faked concrete test results for Hong Kong-797
Zhuhai-Macau bridge project. South China Morning Post. Retrieved March 9, 2020, 798
from https://www.scmp.com/news/hong-kong/law-crime/article/2095389/officers-799
arrest-21-over-faked-concrete-test-results-hong 800
SCMP. (2019, May 28). Main contractor at scandal-hit Hung Hom MTR station accused of 801
using wrong rebar, as inquiry of Hong Kong government-appointed commission 802
continues. South China Morning Post. Retrieved March 9, 2020, from 803
https://www.scmp.com/news/hong-kong/transport/article/3012015/main-contractor-804
scandal-hit-hung-hom-mtr-station-accused 805
Shafiq, M. & Lockley, S. (2018). Signature-based matching of IFC models. Proceedings of the 806
35th International Symposium on Automation and Robotics in Construction (pp. pp. 807
993-1001). IAARC. doi:10.22260/ISARC2018/0138 808
Shi, X., Liu, Y. S., Gao, G., Gu, M. & Li, H. (2018). IFCdiff: A content-based automatic 809
comparison approach for IFC files. Automation in Construction, 86, pp. 53-68. 810
doi:10.1016/j.autcon.2017.10.013 811
Taylor, J. & Bernstein, P. (2009). Paradigm Trajectories of Building Information Modeling 812
Practice in Project Networks. Journal of Management in Engineering, 25(2), pp. 69-76. 813
doi:10.1061/(ASCE)0742-597X(2009)25:2(69) 814
van Berlo, L. (2015). BIM Service interface exchange (BIMSie). National Institute of Building 815
28
Science, USA. Retrieved March 9, 2020, from https://www.nibs.org/page/bsa_bimsie 816
Wang, H. & Meng, X. (2019). Transformation from IT-based knowledge management into 817
BIM-supported knowledge management: A literature review. Expert Systems with 818
Applications, 121, pp. 170-187. doi:10.1016/j.eswa.2018.12.017 819
Wang, Z., Wang, T., Hu, H., Gong, J., Ren, X. & Xiao, Q. (2020). Blockchain-based framework 820
for improving supply chain traceability and information sharing in precast construction. 821
Automation in Construction, 111, Article ID 103063. doi:10.1016/j.autcon.2019.103063 822
Wüst, K. & Gervais, A. (2018). Do you need a blockchain? Proceedings of 2018 Crypto Valley 823
Conference on Blockchain Technology (pp. 45-54). IEEE. 824
doi:10.1109/CVCBT.2018.00011 825
Xia, Q. I., Sifah, E. B., Asamoah, K. O., G. J., Du, X. & Guizani, M. (2017). MeDShare: Trust-826
less medical data sharing among cloud service providers via blockchain. IEEE Access, 827
5, pp. 14757-14767. doi:10.1109/ACCESS.2017.2730843 828
Xue, F., Chen, K., Lu, W., Niu, Y. & Huang, G. Q. (2018a). Linking radio-frequency 829
identification to Building Information Modeling: Status quo, development trajectory 830
and guidelines for practitioners. Automation in Construction, 93, pp. 241-251. 831
doi:10.1016/j.autcon.2018.05.023 832
Xue, F., Lu, W. & Chen, K. (2018b). Automatic generation of semantically rich as‐built 833
Building Information Models using 2D images: A Derivative‐Free Optimization 834
approach. Computer‐Aided Civil and Infrastructure Engineering, 33(11), pp. 926-942. 835
doi:10.1111/mice.12378 836
Zheng, R., Jiang, J., Hao, X., Ren, W., Xiong, F. & Ren, Y. (2019). bcBIM: A blockchain-based 837
big data model for BIM modification audit and provenance in mobile cloud. 838
Mathematical Problems in Engineering, 25, Article ID 5349538. 839
doi:10.1155/2019/5349538 840
841
842
