Automation in Construction 156 (2023) 105109

Contents lists available at ScienceDirect

Automation in Construction
journal homepage: [Link]/locate/autcon

Knowledge graph-based data integration system for digital twins of

built assets
Carlos Ramonell *, Rolando Chacón, Héctor Posada
Department of Civil and Environmental Engineering, Universitat Politècnica de Catalunya, Spain

A R T I C L E I N F O A B S T R A C T

Keywords: The emergence of digital twin technologies offers a promising avenue for improving decision-making through the
Digital twin integrated use of up-to-date physical or synthetically simulated data. Nevertheless, the practical implementation
BIM of digital twins in the built environment remains a significant challenge. This paper describes a system that
Data integration
seamlessly integrates data into digital twins of built assets. The system uses a knowledge graph to achieve data
Knowledge graph
Microservice architecture
integration, which is designed to be modular, flexible, and interoperable. The graph includes BIM models,
metadata from an external IoT platform, and process-related information. The system is microservice-based and
revolves around a graph database housing the knowledge graph. It employs dynamic operations to update the
knowledge graph and is tested using civil engineering infrastructure examples. Results from this work can be
used to create pipelines that extract and operate with data connecting computational agents integrated into the
system as microservices or connected through the system API.

1. Introduction exchange. Cloud computing enables remote data and application stor­
age, enhancing software management for various purposes. Advanced
The built environment is a dynamic system of systems that inter­ simulation (AS), Data Analytics (DA), and Artificial Intelligence (AI)
connect economic infrastructure, social infrastructure, and the natural unlock the value of data, transforming it into a crucial business asset.
environment. The built environment serves as a vital network of services These advancements lead to intricate data structures, linking physical
that knit the proper functioning of societies. It continuously evolves and assets to their Digital Twins (DTs): virtual replicas integrating physical
as a result, the Architecture, Engineering, Construction, and Operation data, virtual models, simulations, AI, and other layers. These DTs
players navigate the intricate process of designing, constructing, oper­ become unexpected asset interfaces for end-users, potentially serving as
ating, maintaining, and decommissioning the constituent assets which comprehensive decision-making hubs. While Building Information
are unique, but whose digital forms tend to be different for all involved Modelling (BIM) offers dependable virtual representations and digital
agents. Efficiency in pre-digital ecosystems was maximized with collaboration in the built environment, there remains a gap in inte­
decentralized organizational and data structures. Efficiency on such grating DTs with BIM, IoT systems, cloud data, simulations, and AI into
ambitious information constructs such as digital twins can only be an adaptable solution capable of addressing stakeholder diversity and
maximized with more adaptive data structures. The successful execution specific built asset requirements.
of projects throughout the lifespan of an asset relies on the collaboration European efforts are directed towards bridging this gap. Exemplary
of multidisciplinary stakeholders who simultaneously manage multiple Research and Innovation Actions (RIA) such as Ashvin [1], BIMprove
projects across various locations, with independent collaborators, and [2], COGITO [3], or BIM2TWIN [4] altogether explore the development
with diverse contexts. In this sense, presently, AECO is a complex of digital twin solutions from a vast perspective. This particular research
network that generates, consumes, and exchanges an extensive volume paper is framed within one of these projects, Ashvin, whose vision for
of data of diverse natures, in multiple formats, and through different demonstrating digital twin applications at design, construction, and
communication channels. operation was based on implementing a DT cloud platform and a series
The Internet of Things (IoT) is increasing data sharing among a wide of cohesive tools on ten very varied demonstrators. Ranging from
range of physical and virtual devices, facilitating real-time information buildings to bridges, from industrial to residential buildings, or from

* Corresponding author.
E-mail address: [Link]@[Link] (C. Ramonell).

[Link]
Received 31 May 2023; Received in revised form 20 September 2023; Accepted 25 September 2023
Available online 5 October 2023
0926-5805/© 2023 The Author(s). Published by Elsevier B.V. This is an open access article under the CC BY-NC license ([Link]
nc/4.0/).
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 1. Built environment across domains and life cycle stages.

airport runways to quay walls in ports, these demonstrators shaped the The research focused on developing digital twin applications is
need for embedding such variety. Aggregated information from diverse relatively mature in other disciplines such as the aerospace industry [5],
assets reveals strengths, weaknesses, and system needs. Flexible archi­ healthcare [6], and manufacturing [7]. More recently, the term shows a
tectures must accommodate varied tools, use cases, and data. digitization path in the construction industry [8] whose ultimate goal is
This paper outlines a system for integrating data from various efficiency maximization. The construction sector is very varied. Thus,
sources to create comprehensive digital twins of built assets. The system the design and implementation of Digital Twins are not yet consensually
utilizes a knowledge graph as the primary integration mechanism of defined within the sector. The level of development is still patchy
varied pieces of information that comprise a digital twin. This proposal ranging from models that cannot be updated easily with physical data to
relies on the present nature of BIM and existing Standards. The knowl­ hyper-specific yet accurate single-function DTs that serve one particular
edge graph allows for efficient querying and exploration of contextual­ solution. Those actions are presently driven by the industry needs and by
ized asset data. It also establishes a base for generating information use-case-specific outcomes.
pipelines that operate with data and that provide services. On a service- In the realm of the built environment, the digital twin concept
based platform, end-users can retrieve information for timely assistance initially drew inspiration from the aerospace and manufacturing sectors
in decision-making processes. In the remainder of this paper, section 2 [10]. These industries utilize tailored, prolonged monitoring systems in
introduces the concept of vast-scoped digital twins and elaborates on all controlled industrial settings, offering highly accurate predefined sim­
needs and challenges for implementation in the built environment. ulations for enhancing product productivity and life-cycle management.
Section 3 elaborates on the objectives of the study and introduces the Nevertheless, the diverse and complex nature of the built environment
methodology, based on a set of civil engineering infrastructures in which introduces unique challenges, which hinder the direct application of
the system is tested. Section 4 elaborates on the BIM-to-Twin transition strategies employed in other industries.
(or evolution) whereas Section 5 describes more comprehensively, the
use of Knowledge Graphs in Digital Twins (KGDT) and finally section 7 2.1. The virtual representation of built assets
describes the knowledge graph-based proposed system.
To create a comprehensive virtual representation of a given asset of
2. Digital twins of built assets in the AEC industry: vision and the built environment, multiple knowledge domains must be described
challenges and integrated within a Unified Virtual Model (UVM). For instance, a
UVM of a building should encompass domains such as architecture,
The term “Digital Twin” still deserves lines of presentation. structural engineering, HVAC, MEP or building management. This UVM
Consensus about a unique definition is far from reached. In an attempt to model constitutes the core of an ambitious, comprehensive digital twin:
identify a general definition of the term, Vanderhorn and Mahadevan a single source of truth in which geometric representations, built
[9] reviewed 65 different definitions published between 2010 and 2020 product descriptions, process representations, multi-physics and mana­
from which they abstracted the following: gerial information are seamlessly intertwined.
A Digital Twin is “a virtual representation of a physical system (and its The built environment also encompasses different asset scales. These
associated environment and processes) that is updated through the exchange scales span from individual elements within an asset to, for instance, a
of information between the physical and the virtual systems” [9]. large network of assets in a city [11]. At the element level, virtual
Noticeably, this definition is generic, and specific questions arise models must capture detailed physical properties and behaviour of in­
regarding many topics such as i) the nature of all virtual representations dividual asset components. At the asset level, the models must account
of physical systems, ii) the type of data that can be obtained from the for the components’ spatial arrangement, interactions, and asset systems
physical system and how it is transported and integrated within the behaviour. The models must describe the broader context at the infra­
virtual system or, iii) the level of development of the Digital Twin. structure and city levels, including the natural and urban environment,
Understanding industry specifics, context, and use case needs shapes a transportation systems, and utilities.
digital twin’s functionality and technology components. Moreover, built assets are unique. Built assets are bespoke, with

2
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 2. Traversing the built environment scale through digital twin intercommunication.

virtualization of the built environment at varied levels (product and

Table 1
building) while models in the field of Geographic Information Systems
Digital twin requirements for built assets.
(GIS) address the virtualization at geographically vaster levels. The
Digital twin requirements challenge remains in how to adapt these modelling paradigms to the
Virtual • Cross-domain and multi-scale conceptual description interoperable, cloud-based, modular and flexible virtual model vision of
Model • Flexibility to be extended or modified. a Digital Twin to which external data sources can be coupled.
• Interoperable.

Data • Integration of different external data sources.

2.2. Data in the built environment
• Support of different formats (time series, images, pointclouds,
etc.).
System • Cloud-based (ubiquitous connectivity). The built environment has seen an increase in the use of data-
• Provision of APIs. capturing technologies. Sensors, cameras, 3D scanners, radars and
• Modularity. other remote sensing devices are increasingly present in the sector [14].
These technologies enable varied data collection and thus varied digi­
different information requirements along the design, construction, and tization of the physical environment of an asset, resulting in highly
operational stages. All these requirements are commonly dealt with by a diverse data types and structures [15]. For instance, time series, images,
variety of stakeholders. Consequently, this leads to fragmented asset PDFs, tabular forms or point clouds are collected presently collected in
information storage and a potential loss of data during the handover many built assets.
from one stage to another [12]. On the other hand, the lifespan of built When it comes to transmission and storage, cloud-based services and
assets often surpasses that of assets in other industries as well as sur­ IoT technologies enable new capabilities. Consequently, the amount of
passes human and business life expectancies. Thus, assets are placed available data rises exponentially. Two sources of data are worth
within a constantly evolving social, economic, and technological land­ mentioning: On the one hand, data produced on-site by sensors and
scape. Next-generation digital twins must flexibly maintain their core applications can be continuously streamed in “real-time” from the
virtual model across life-cycle stages, adapting to evolving stakeholder physical asset to its digital counterpart. This helps provide insight into
needs. Information interoperability is crucial for achieving this goal. the processes and the physical behaviour of the asset, although not all
Fig. 1 illustrates these ideas. A physical asset has a virtual representation cases require such levels of real-time synchronicity (it is often more
along its life cycle. This virtual representation is multi-faceted and in­ rational to expect right-time synchronicity). Data collection, transfer,
cludes several domains. Each domain contains different sources of and integration in the Digital Twin require the implementation of
synthetic data, processes and outcomes. human-in-the-loop processes, which shift the approach of the physical-
Standards for information modelling and sharing are essential to virtual connection from “real-time connection” to “right-time connec­
enable interoperability while cloud-based architecture solutions are tion”. Thus, Digital twins must include not only machine-to-machine
needed for ubiquitous access to information. Interoperability also en­ live data streaming enabled by IoT technologies but also well-designed
ables information sharing between digital twins. This fosters the crea­ user interfaces, accessible from multiple locations, for uploading and
tion of modular federated digital twin ecosystems [13] in which every interacting with meaningful data [16]. On the other hand, public ini­
twin has a purpose-driven and outcome-focused scope that can be fed by tiatives are feeding available data platforms that offer free access to
the insights of other digital twins at higher or lower levels, providing historical and stream data through dedicated APIs in varied fields,
means to effectively manage the complexity and scale within the built including hazard-related, environmental, and social data [17]. Digital
environment (See Fig. 2). twins can also benefit from such data types if they are capable of inte­
Currently, Building Information Modelling (BIM) addresses the grating data in distributed storage systems over the internet, managed
by different organizations.

3
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 3. Location of the demonstrators across Europe.

Digital twins are expected to contextualize this data within a single showcasing how this system is structured and how it enables semantic
UVM to provide meaningful and useful access to such varied collected integration and interaction with the information it contains, regardless
data. This contextualization of data enables different computational of its nature.
agents to establish pipelines that extract, analyse and transform this BIM models represent the Standard virtual representation for all
data. This is a more comprehensive way to provide insights for decision- demonstrators. To build their digital twin system, creating a BIM model
making support services. Thus, to improve usefulness, maintainability represents a necessary first step since it provides the semantic basis. This
and adaptability, digital twins must support technologies that allow basis is thus extended for integrating the various types of data collected
adding agents modularly via Application Programming Interfaces (API). in each demonstrator.

4. The BIM to twin transition

2.3. Discussion
The BIM Dictionary [19] defines BIM as “a set of technologies, pro­
Table 1 summarizes the identified requirements to develop and
cesses and policies enabling multiple stakeholders to collaboratively design,
implement digital twins of built assets. Three perspectives are described:
construct and operate a facility in virtual space”. The recently published
requirements of virtual models, the collected data and the software
standard ISO 19650 [20] defines BIM as “the use of a digital representation
system.
of a built asset to facilitate design, construction and operation processes from
a reliable basis for decisions”. These definitions of the BIM concept depict
3. Objectives and methodology the current uses of BIM technology: on the one hand, it is used to enable
collaboration among industry stakeholders, where interoperability of
The primary objective of this study is to present a system that digital assets becomes a major requirement. On the other hand, it is used
seamlessly combines virtual models of built assets with various data as the basis for application development that assists stakeholders in
sources, adhering to the requirements outlined in section 2, and performing specific tasks during the whole project lifecycle.
enabling their unified utilization. The proposed solution is composed of Studies have demonstrated the utility of BIM models in supporting a
i) a central knowledge graph, ii) central mechanisms for semantic data wide range of engineering applications. By establishing data pipelines,
integration and exploration, and iii) a microservice architecture, that these models can support code compliance checking [21], construction
assembles the system, conforming with current cloud-based practices. safety management [22], structural analysis [23], construction planning
As part of the methodology, the developments are imposed by the and progress monitoring [24], as well as the development of various
realistic needs of ten infrastructure assets or systems. These assets are operation and maintenance activities such as energy analysis [25],
testbed demonstrators within Ashvin, the research project [1,18]. This emergency management [26] or condition assessment [27]. These
set of assets provides a realistic landscape of varied typologies, stages pipelines are generated upon information extracted from BIM models
(currently operated or under construction), stakeholders and premises. and additional models or data resources, clearly showing the demand for
Fig. 3 shows information about all ten assets and their contribution to approaches that combine multiple virtual representations with collected
the project. The gathered data are listed in Table 2. data. Solution approaches are based on the combination of disconnected
Because the project employs a diverse range of demonstrators, the software that is not replicable in other use cases.
challenge lies in creating a universally applicable digital twin system, These applications have benefited from the release of open BIM
regardless of asset typology, stage, or use case. This study is aimed at

4
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Table 2 of 3D geometry, infrastructure, construction processes and various tax­

Description of the demonstrators. onomies of products across industry domains [28].
No. Description Contribution Data Phase Currently, the use of BIM is becoming a mandatory data exchange
Standard in many countries. It ensures faster and more collaborative
1 A series of high- Digitize the Time-Series Operation and
speed railway bridges and the from sensors. Maintenance processes during design and construction projects. Despite the release of
bridges in the load tests that Imagery. IFC, the highly demanding coordination and collaboration requirements
Plasencia-Badajoz were performed Tabular forms during the design and construction stages, involving multiple actors and
line in between April fragmented data models, produce a significant amount of disaggregated
Extremadura, and July 2021 to
Spain. verify the
data, which much of it is lost, and only a small portion is transferred to
construction and the facility management stage [12]. Recent advances in cloud and web
start of the technologies are called to improve collaboration, information sharing,
operation stage of and persistently centralised web data platforms, known as Common
the bridges as all
Data Environments (CDEs). The current form of BIM files can thus be
of the network.
2 Renovation of a Digitize the Time-Series Design, substituted by databases. File-based information exchanges among ap­
multi-family building to from sensors Operation and plications can be transformed into data-based transactions made
house in the city of provide insight Maintenance through web APIs, allowing stakeholders to access dynamically the right
Gdynia, Poland. into the energy data in a more granular and flexible way [29]. This aligns with the vision
performance of
the building
of a digital twin that provides ubiquitous access to one asset’s
3 Airport of the city Condition Imagery. Operation and information.
of Zadar, Croatia. monitoring of the Maintenance Enabling efficient database interactions for accessing IFC informa­
existing runway tion is challenging. There is a substantial number of entities that must be
to improve the
accommodated within relational databases. An entity can be an element,
overall
maintenance a surface or a relationship. For instance, in IFC2x3, there exist 653 en­
works. tities and 327 types, while IFC4 comprises 766 entities and 391 types.
4 Industrial Building Support the Imagery Construction Consequently, directly mapping these entities to a relational database
located in planning and represents an intricate task in a relational model. The complexity
Germany. control of
inherent in representing the IFC schema as a table-based model
construction
processes adversely affects performance, particularly when executing complex
5 27-story office Support control of Time-Series Construction queries [30]. Additionally, the rigidity of the relational model and the
building located in construction from sensors, need for a pre-defined data schema hinder the semantic enrichment of
Göteborg, processes Pointclouds
BIM models and the capability of integrating additional information
Sweden.
6 Office Building Support control of Time-Series Construction dynamically, which is an essential need for digital twins.
located in construction from sensors, In this study, the transition from BIM to DT keeps IFC as the basis.
Barcelona, Spain. processes based Pointclouds, The study proposes a graph-based approach for modelling and managing
on multiple data Imagery. BIM. Modern graph databases offer means to manage and transact with
collection,
this BIM information efficiently. Section 5 dives further into this
including
pointclouds, approach and proposes a knowledge graph as the technological solution
sensors and for data management and integration challenges in digital twins.
pictures
7 Composite steel- Seasonal study of Time-Series Operation and
5. Knowledge graph-based digital twins
concrete box- its structural from sensors, Maintenance
girder curved behaviour from Pointclouds,
bridge located in 3D laser scans. Imagery, This section describes the proposed concept of Knowledge Graph-
Barcelona, Spain Vibration-based Tabular forms. Based Digital Twin (KGDT). Firstly, graphs and knowledge graphs are
patterns analysis. described. Current models, standards and technological enablers for
Understand steel-
their proper development are presented. Then, emerging uses of
concrete
interaction. knowledge graphs for digital twins in the AEC sector are described.
Visual Inspections
8 Footbridge in Aid to the design Historical Design 5.1. The graphs
Dortmund, process based on design data
Germany previous projects
9 Sports stadium Seasonal study of Pointclouds Operation and 5.1.1. Graph models
roof structure its structural Maintenance A graph is a data model represented by a collection of nodes, or
located in Munich, behaviour from vertices, that are connected by relationships, or edges. Nodes may
Germany 3D laser scans. represent entities of a specific domain. Relationships define how these
10 Quay wall in the Condition Time-Series Operation and
port of Rotterdam, assessment based from sensors. Maintenance
entities interrelate with one another. Graphs can be defined as directed
Netherlands on historical data or undirected. The former has a one-way relation between two nodes
from sensor whereas the latter has a two-way relation. Graphs provide a simple yet
readings. powerful general-purpose data modelling tool to represent complex re­
lations between entities and how they relate to the world.
Currently, two graph models dominate the scene: The Triple-based
standards such as Industry Foundation Classes (IFC), which offer a
model and the Property graphs [31]. The triple-based model is a
shared semantic specification across domains in the built environment,
directed graph model where nodes are connected using three-part
enabling interoperability and fostering the development of BIM-based
statements called triples. Each triple consists of a subject, predicate,
applications. Originally managed and maintained in EXPRESS lan­
and object. The predicate establishes a relation between the subject and
guage, it established a system of information exchange based on file
the object. The triple-based graph is based on the Resource Description
transactions. Nowadays, IFC is the most complete data schema that
Framework (RDF) schema, the standard developed by the W3C stan­
describes the built environment. Its scope is vast, covering the definition
dardization group for sharing data on the semantic web. RDF graphs are

5
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Table 3 applications, enabling graph data interoperability. RDF-based data can

Description of micro-services forming the data integration system for digital be serialized using multiple syntaxes such as RDF/XML, N-Triples,
twins. Turtle, or JSON-LD, and can be stored in specialized RDBMS-based
Service Description Container systems called semantic stores. The information can be queried using
source SPARQL, a standardized query language.
GraphDB Stores the knowledge graph. Neo4j [66] graph Docker Hub On the other hand, the property graph model provides nodes and
database management system is selected. relationships with an internal structure. Nodes can have multiple labels.
ProcessDB Stores the data of processes. The document- Docker Hub Labels declare the category as well as the node purpose within the graph.
oriented NoSQL database management system
Relationships are assigned a type, which semantically defines how en­
MongoDB [67] is selected.
Ashvin-server It contains the API to interact with the whole Authors tities interrelate. Both nodes and relationships can contain properties,
system. It is the communication endpoint with stored as key-value pairs. Property graphs are gaining popularity and are
the ASHVIN GUI. It contains the business logic becoming the selected option used by widely established native graph
that triggers the use of the rest of the databases such as Neo4j [32]. The structure of property graphs allows
microservices when they are required. It also
stores backup IFC files and geometry files.
for more natural and flexible data modelling, as they are not bonded to
Message Provides a messaging system for internal Docker Hub any standard, and their dedicated graph databases are better suited for
Broker communication among services in the system systems where the driving force is to provide efficient transactions of
thus enabling event-driven functionalities. The information.
open-source message broker RabbitMQ [68] is
The use of mappings between RDF graphs and property graphs has
selected.
IfcConvert Manages the conversion of geometrical Authors become essential to combine operational efficiency and interoperability,
information from IFC to well-known geometry allowing for the creation of hybrid models that leverage the strengths of
file formats such as .obj or. glb among others. It is both modelling approaches [33,34].
based on the IfcConvert application provided by
IfcOpenshell [69]
5.1.2. Ontologies
Ifc2Graph Manages the conversion of semantic information Authors
from IFC to a graph format and stores it in the According to Studer et al. [35] an ontology is a formal, machine-
graph database. readable specification of a shared conceptualization. It describes the
Processes Manages the information related to maintenance Authors meaning of entities within a specific domain through relationships and
processes via a REST API and updates the graph
rules. Taxonomies are a simplified version of ontologies, expressing only
with an abstract of the contained information.
MainfluxSync It bypasses the interaction with an external IoT Authors a hierarchical classification of entities in a domain. The Ontology Web
platform named Mainflux (described in section Language [36] is the most used ontology language, recommended by
6.4) and dynamically updates the information in W3C and based on the RDF schema, making it compatible with RDF
the graph with the platform metadata. graphs.
Ontologies are used to describe the information contained in a graph.
referenced over the web using a Unique Resource Identifier (URI), which By mapping the nodes and their relationships of a graph to entities and
allows linking data over the internet. The use of this standardized their relationships in ontologies, graphs can be shared and interpreted
schema allows sharing and exchanging of data among systems and according to domain-specific knowledge. This is the key.
As a step forward, reasoning engines can also use ontologies to derive

Fig. 4. Schema of the system architecture.

6
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 5. Subsystem for importing IFC files.

Fig. 6. Top-level graph structure formed by Assets and Files.

new knowledge from data through semantic axioms and inference rules. stack, the concept is not limited to these technologies. Companies are
Ontologies can be published openly on the web to promote interopera­ increasingly using property graph models and graph databases to store
bility among graph-based applications or can be created as private in­ and manage their knowledge graphs, where transactional efficiency and
formation assets for cross-enterprise data management. As such, they data privacy are critical concerns [38]. Examples of open-access
have become essential data models that allow for the creation of knowledge graphs built on RDF-related formats include DBpedia [39],
knowledge graphs, interrelating concepts from different domains [37]. Wikidata [40], BabelNet [41], and YAGO [42].

5.1.3. Knowledge graphs 5.2. Knowledge graphs as DT enablers for the built environment
A knowledge graph is a graph-based data structure that emphasizes
contextual understanding of data by interlinking metadata. This is ideal Akroyd et al. [43,44] suggest that a dynamic general-purpose
for application in scenarios that require integrating, managing, and knowledge graph is ideally suited for digital twins. This knowledge
extracting value from diverse sources at a large scale [38]. Knowledge graph should include a combination of ontologies and autonomous
graphs provide several advantages over traditional data models for agents that continually operate on it. By using ontologies, knowledge
modelling, structuring, managing, and analyzing heterogeneous and graphs promote the established use of data, facilitating reuse and
complex data with dynamic relationships [37]. They allow representing interoperability. Their multi-domain nature allows for the addition of
complex abstractions of knowledge in specific domains or across do­ new ontologies and the establishment of relationships between related
mains. Unlike relational or NoSQL models, knowledge graphs allow data terms to enhance interconnectivity. Additionally, their distributed na­
to evolve flexibly, as they do not require pre-defined schemas. Moreover, ture permits hosting diverse data types in different locations while
these constructs can be made interoperable by mapping their entities to providing links to their original repositories. Thus, data owners retain
existing ontologies, enabling transactions of data and its context be­ control over hosting and access depending on data sensitivity. Further­
tween software applications. Modern graph analytics provide further more, the hierarchical and extensible ontological structure allows rep­
insights from the domains described in the graphs. While knowledge resentation at various scales (product, building, city, and national
graphs are often associated with RDF and the semantic web technology systems). The interconnectedness of concepts and instances in

7
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 7. Steps in the IFC to graph conversion process.

Fig. 8. Node labels and properties after conversion.

knowledge graphs, combined with dynamic updates from computational ETH Centre (SEC) to improve city management and planning. Within
agents and live data feeds, enables multiple interactions between players this frame, Chadzynski et al. [46] integrated city information models in
within a given digital twin. These properties suggest high suitability for the knowledge graph based on OntoCityGML ontology [47], and sub­
implementing larger-scale digital twins. sequently implemented a set of intelligent software agents to perform
For instance, at a city scale, City Knowledge Graphs (CKG) [45] are specific data processing and analytical tasks based on interactions with
being developed by the Cambridge Centre for Advanced Research and such graph. A knowledge graph-based system was also used within the
Education in Singapore (CARES) in collaboration with the Singapore- CReDo project (Climate Resilience Demonstrator) as part of the digital

8
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 9. Example of the effect of the conversion in the structure of IFC relations. Relation entities are bridged using the corresponding inverse attributes of the
IFC entities.

The potential lies in the IFC schema, which is an ontology [51] that
Table 4 can be utilized for constructing the knowledge graph. The translation of
Import results for the IFC models of the ASHVIN demonstrators. the IFC schema to a more common ontology language is proposed by
File Demo IFC Schema Nodes Relations Pauwels and Terkaj [52]. These authors generated an OWL version,
[Link] 9 IFC4 44 122 named the ifcOWL ontology. Presently, ifcOWL graphs result in rather
[Link] 10 IFC4 93 199 large models due to the built-in complexity of the IFC schema (mainly its
Valdelinares_IFC4.ifc 1 IFC4 157 517 geometrical definitions). Alternatively, the Linked Building Data (LBD)
[Link] 1 IFC4 205 979 group has developed a set of more granular ontologies conceived to
[Link] 4 IFC2X3 405 1320
StegDortmund-R2021_Neu.ifc 8 IFC2X3 688 2618
contribute modularly and thus, they can be extended with third-party
Kineum_CM.ifc 5 IFC4 721 2249 contributions. These ontologies help generate a more flexible descrip­
[Link] 5 IFC4 820 3301 tion of the built environment that adjusts to each use case’s needs [53].
[Link] 5 IFC4 846 3376 Some of these ontologies are listed below:
MILE_Avila.ifc 6 IFC4 993 4897
GDY_ZB_30_before_renovation.ifc 2 IFC2X3 1148 4984
zadar_airport.ifc 3 IFC4 1714 7244 • Building Topology Ontology [54]
Llobregat_Viaduct.ifc 7 IFC4 2083 8895 • Building Element Ontology [55]
MILE_PE_STR_U1.ifc 6 IFC2X3 6373 42,104 • Ontology for distribution elements [56]
Kineum_plan16_NCC.ifc 5 IFC2X3 12,599 74,595 • Damage monitoring Ontology [57]
A-40-V-4_space.ifc 5 IFC2X3 28,664 219,895
• Bridge topology Ontology [58]
• Building Product Ontology [59]
twin programme in the UK [48], where the knowledge graph combined • Ontology for Managing Properties [60]
the description of assets from energy, water and telecom networks with • Ontology for Managing Geometry [61]
data from flood simulation and with models that describe the effect of • File ontology for geometry formats [62]
the flood on the assets [49,50]. Narrowing the scale to the building level,
knowledge graph-based systems are not yet found in academic Although those ontologies still do not cover the whole semantic
literature. richness of the IFC schema, they are paving the way to more efficient

9
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Table 5
Conversion result of [Link].

Table 6
Conversion result of Kineum_CM.ifc.

methods for modelling, sharing and operating with data in the built 6. A system for data integration in digital twins of built assets
environment. The graph data structure enables the unified management
of federated BIM models, and graph databases enable granular access In this section, a system that dynamically updates a knowledge graph
and management of information through API queries [63]. IFC models is proposed. It represents a unified interface for multiple data sources
can be expressed in graph format and can be mapped to ifcOWL or that contribute to a digital twin of a built asset. The system is built based
existing LBD ontologies and extended with on-demand knowledge and on the varied requirements and challenges posed by ten different varied-
metadata from external data sources. Therefore, a system capable of in-nature demo sites described in Sections 2 and 3.
dynamically maintaining a knowledge graph represents a promising From the BIM perspective, each demonstrator is initially described
candidate to enable multi-scale and cross-domain digital twins in the with an IFC model. These models are processed to transform the infor­
built environment. mation in its original STEP format into two separate parts that are
interlinked: a geometry file and a property-graph-based semantic model.
This graph-based semantic representation of the demonstrators can be

10
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Table 7
Conversion result of GDY_ZB_30_before_renovation.ifc.

Fig. 10. Subsystem for integrating process data.

extended on demand and, if needed, mapped to existing ontologies to the asset semantic description. The ontologies describe the organizing
make the content interoperable. The property graph is the semantic principles of such data sources and relate them with concepts described
backbone of the system. Section 6.1 describes the system architecture. in the IFC schema.
The transformation from IFC files to a property graph is explained in
Section 6.2.
Data integration is performed considering two scenarios described in 6.1. System architecture
Section 6.2 and Section 6.3. The former illustrates the integration of data
from a local database. It contains digitized, machine-readable repre­ The system is developed based on a microservices architecture. This
sentations of asset-related processes. The latter shows the integration of design approach breaks the system into small, independent services.
sensor data from an external IoT platform. The integration of both data Each micro-service represents a specific functionality within the system
sources is driven by ontologies that are explicitly developed to extend that can be developed, deployed and scaled independently. Through
the central knowledge graph and, thus, semantically link the data with lightweight information exchanges, these micro-services collaborate to
form a cohesive application. This architecture offers numerous

11
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 11. IFC task simplified ontology. For more detailed information about their definition and properties, refer to [28].

advantages, including enhanced software resiliency, flexibility, and series of systematic steps.
scalability [15]. Micro-services are increasingly prevalent in the devel­ As a first step, the end-user can employ a graphical user interface
opment of cloud-based applications. (GUI) to transmit the IFC file to the server, where it is securely stored.
One of the key enablers of micro-services development is contain­ Subsequently, two services help: IfcConvert and Ifc2Graph are employed
erization. Containerization is a technology that enables developers to in parallel to handle the processing of geometry and semantics,
package applications and their dependencies into self-contained units respectively. This simultaneous processing ensures the conversion of
called containers. Each container includes codes, runtime environments, both aspects of the IFC model.
libraries and configurations. It represents a lightweight and portable Subsequently, geometrical data is stored in the server in GLB format.
package. In this study, Docker [64] is selected as the containerization Likewise, semantic information is stored in the Neo4j database and
platform. It is a widely used platform and it also provides Docker Hub structured as a property graph, following the IFC schema [28]. The IFC
[65], a cloud-based repository that allows developers to publish, share schema can be mapped to existing ontologies using an open-source
and discover containers. plugin called Neosemantics [70], which extends the capabilities of
Table 3 provides a concise description of the functionality of the Neo4j to handle RDF data. The process is visually depicted in Fig. 5. This
containers that are used to compose the proposed system. All containers, figure zooms within a specific sub-system representation of this part
the ones developed by the authors and those used by third parties are which belongs to the vaster system.
available on Docker Hub. From Fig. 5, two comments are worth pointing out:
The knowledge graph is persistently stored in the Neo4j graph
database, adhering to the principles of the labelled property graph • IfcConvert is built upon an open-source command-line application
model. The graph provides a semantic index of the data available in the provided by IfcOpenshell. This application facilitates the conversion
system, which is contextualized with the asset information model. The of IFC files into geometry file formats that offer greater interopera­
system also provides mechanisms to keep the graph dynamically upda­ bility, such as OBJ, DAE, GLB, STP, IGS, XML or SVG. The binary GLB
ted as new information is added, as described in the following sections. format is selected in this particular research since it enables more
The developed micro-services communicate using HTTP (HyperText efficient storage and retrieval of geometric information.
Transfer Protocol) requests via REST APIs. Additionally, AMQP • IFC2Graph has been developed with Python and IfcOpenShell Python
(Advanced Messaging Queuing Protocol) communication is used to library to parse IFC data and then communicate with Neo4j [71].
enable event-driven functionalities to keep the graph updated based on
events that are triggered by specific system actions. Fig. 4 shows the Fig. 6 displays the fundamental structure within the graph database
overall system architecture schema. after importing IFC files. The database encompasses assets (represented
It is worth emphasizing that the successful usefulness of the system by blue nodes). Each asset can be associated with multiple IFC files
relies upon designing adequate end-user tools with adapted graphical (yellow nodes). Encapsulated information within each file is linked to
interfaces that enable interaction between users and data. the corresponding file node and it is represented following the IFC-to-
graph conversion algorithm.
6.2. Built asset semantic model: IFC to property-graph
6.2.1. IFC to labelled property graph
IFC2Graph is a developed algorithm for converting IFC files in STEP
The generation of DT for the abovementioned demonstrators re­
format to a central Neo4j database. It is specifically designed for
quires a sufficiently comprehensive IFC model that encompasses both
importing the non-geometrical information of IFC models. Similar al­
geometric and semantic information. The process of transferring the
gorithms are found in [72], in which researchers develop ways for
data from the IFC file to the digital twin system is carried out through a

12
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 12. Example of task structure in the knowledge graph for a construction process on Demo 6: Column concrete vibration monitoring. Labels and properties are set
according to the IFC schema. [28].

13
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 13. Digitization process for activity reports.

parsing capabilities (Pydantic [73]). The model includes three classes:

Table 8 class Node(), class Relation() and class Graph() (see Fig. 7). Subse­
Description of maintenance activities.
quently, in the second step, the neo4j Python driver is utilized to import
Activity Name Demo Description the nodes and relations into the database. Nodes and relations are im­
Bridge Load 1 Load tests on bridges are assessments to prove that the ported to the database using Cypher [74], a graph query language
Test structural performance of the bridge after construction is developed by Neo4j. This two-step process enhances the adaptability
as expected. For that purpose, structural simulations are properties of the conversion tool. Only the second step needs to be
compared with measurements collected using on-site
customized to import the IFC data into other available graph databases
sensors to validate the bridge design.
TLS3DScan 7, 9 This activity stands for a 3D scan using a terrestrial laser based on the property graph model.
scanner (TLS), which delivers a point cloud. It has been The conversion process results in a property graph that follows the
performed in demos 7 and 9 as a geometric assessment of concepts and relations defined in the IFC schema. However, it does not
the structure with structural analysis uses.
maintain backward compatibility with the IFC format and solely focuses
Drone 3 This activity is an automated visual inspection of an
Inspection airport runway using images from high-resolution drone-
on semantic information. IFC definitions associated with the geometric
based cameras. Based on the inspection results the user description of assets are not accounted for. Instead, the presence of a
can trigger minor repairs, major repairs or the geometric representation is indicated by a Boolean property called
replacement of parts of the runway. “presentation.” If “presentation” is true, the geometry can be identified
in the GLB file resulting from the IfcConvert process by the IFC GlobalId.
converting IFC files to a labelled property graph. A comprehensive Furthermore, each node is assigned labels containing pertinent details
analysis of the conversion process is provided by those authors. In this about the IFC and its parent classes in the IFC hierarchy. Properties of
paper, only a concise description of the algorithm is presented. entities defined by the class IfcPropertySetDefinition in the IFC file are
IFC2Graph is executed in two distinct steps (Fig. 7). The initial step condensed as properties of the corresponding node, simplifying the
involves translating the entities and relationships of the IFC file into overall structure of the graph (Fig. 8).
nodes and relations. For this purpose, a generic property-graph model is Additionally, relationships specified in the IFC file as entities through
generated using a Python library that provides data validation and the class IfcRelationship are bridged to enable direct relations between
entities in the graph (Fig. 9).

Fig. 14. Simplified taxonomy for maintenance tasks linked to IFC-based ontologies (processes).

14
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 15. Example of task data model for a load test according to [75].

6.2.2. Building information graph-models 6.3. Integration of process data

A set of IFC files belonging to the set of demonstrators within the
research project are converted. It is worth pointing out that those IFC Subsequently, process data is stored in a local database and linked to
files have been generated by different individuals/teams/stakeholders the main knowledge graph. This is enabled by the subsystem depicted in
which helped test the generality of this conversion process. Table 4 Fig. 10:
summarizes the conversion processes for the different IFC models for the First, asset-related activities (processes) need to be digitized. It is still
Ashvin demonstrators. not a common practice among industry stakeholders to have a digitized
Tables 5, Table 6 and Table 7 illustrate the results of the conversion and machine-readable representation of their activities. However, this is
displaying the geometric model on the End-user GUI developed in [1] a step that needs to be done. For the sake of including such information
and the graph model in the Neo4j graph database for three selected cases in a knowledge graph-based digital twin, tasks required a compatible
of Table 4 (one bridge and two buildings). data structure. In this case, digitized information is structured in JSON
objects which are stored in MongoDB (a NoSQL database that natively
supports storing data in JSON format).

15
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 16. Load test tasks in the knowledge graph. Classes for each node are highlighted and framed with a red rectangle. (For interpretation of the references to colour
in this figure legend, the reader is referred to the web version of this article.)

Secondly, the abstract version of those activities needs to be trans­ according to the IFC schema.
formed into a graph and thus, be linked to the central knowledge graph. This ontology is used as a basis for transformation from JSON to its
This is the way to enable the semantic search of information along with graph format. Fig. 12 exemplifies how tasks are represented in this way:
the rest of the asset model. The amount of information retrieved in this Although tasks described according to the IFC schema provide
activity summary is a decision that needs to be made by the designer comprehensive temporal information, they lack a categorization that
depending on the application of the Digital Twin. facilitates the differentiation between task types for construction and
The IFC schema provides a generic data model for representing maintenance purposes. Hence, to enhance the information detail within
processes (tasks). The use of classes such as IfcWorkPlan, IfcWork­ the digital twin and enable the systematic storage of task information it
Schedule, IfcTask, and IfcTaskTime allow managing and grouping tasks to is imperative to develop taxonomies that describe these task categories.
be performed in the asset. Fig. 11 depicts a simplified ontology defined This study is not focused on the development of comprehensive

16
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 17. Mainflux Ontology (blue). Map to IFC (orange). (For interpretation of the references to colour in this figure legend, the reader is referred to the web version
of this article.)

The simplified ontology depicted in Fig. 11 is extended with a tax­

onomy to categorize the maintenance activities described in Table 8.
The taxonomy categorizes maintenance activities into three distinct
groups: “Assessments,” “Inspections,” and “Repairs.” (See Fig. 14).
The process data stored in the processes database is polymorphic:
Each of the activities described in Table 8 (and any other site in the
project) shares the IFC common data structure, which is then extended
to cover their additional information needs. Fig. 15, for instance, de­
scribes the ifcTask data extension for a bridge load test. Fig. 16 describes
an example of a load test according to the defined ontology and taxon­
omy. This is linked to the knowledge graph through the processes
service.

6.4. Integration of external IoT platform

IoT enables the connectivity of things to the internet. It allows the

collection and sharing of data from these devices. IoT platforms are key
players that contain adequate frameworks to connect both physical and
digital information. There are several IoT platforms available in the
market, which operate with different organizing principles to interact
with data and devices. It is required to understand these principles and
explicitly define them in the form of an ontology. Thus, it enables
integrating indirectly the capabilities of a given IoT platform within the
Fig. 18. Subsystem to couple the Mainflux IoT platform. Digital Twin Knowledge Graph. This idea of integration applies to any
data platform that openly describes data access.
taxonomies and data models of construction and maintenance processes. In this case, the IoT platform used in [1,18] is Mainflux, an open-
source IoT solution. The platform accepts connections over various
The information requirements and definitions vary from organization to
organization, and from country to country. Then, if it is desired to have protocols (HTTP, MQTT, WebSocket, CoAP and LoRaWan) enabling the
two-way connection of all sorts of IoT devices deployed on-site. The
an interoperable set of digitized activities, this is a task that should be
realized in a collaborative effort between companies, academia and platform features three basic entities to perform communication be­
tween information producers and consumers: things, channels, and
standardization bodies. One identified requirement is a common library
of processes that can be shared among all parts and enables effective users. A thing represents any data source or producer. Channels are
communication pathways through which things send and receive mes­
application development.
This study uses a case-based approach in which specific reports for sages. Messages can be addressed to specific topics, providing extra se­
mantics to the communication process, and enhancing data querying
maintenance activities performed in the demonstrators are digitized.
Each report has specific information requirements, from which data and filtering. Channels facilitate all complexities of low-level commu­
nication protocols offering a unified and easy-to-use interface for
models have been developed. These data models are then used to
transfer the information in the report to a machine-readable format. messaging. Users represent physical persons and organizations which
own channels and things. The platform provides an open API from which
Fig. 13 depicts this process.
users can perform CRUD operations (Create, Read, Update, Delete) with
Data models have been developed to cover the needs for the inte­
things, channels and connections. Data sent over the platform can be
gration of maintenance tasks performed on demonstrators 1, 3, 7 and 9
consumed as a stream via MQTT and WebSocket or can be retrieved
of Table 1. Table 8 briefly describes these specific maintenance
from a structured time-series database. Sensor messages are sent in
activities:
SenML [76] format and also can be sent using a custom JSON structure.

17
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 19. Mainflux IoT platform setup generated after importing an IFC file.

Fig. 20. Connectivity between IfcSensors and Mainflux things in the graph.

18
C. Ramonell et al. Automation in Construction 156 (2023) 105109

Fig. 21. Enabled retrieval of contextualized data using integrated IFC models, processes and IoT platform metadata.

The platform also accepts files related to point clouds, images or videos. digital twins. In this study, those requirements have been identified and
Fig. 17 presents the ontology used to integrate the data available in dealt with throughout the development of a Knowledge Graph. Among
Mainflux into the knowledge graph. those requirements, it is understood that digital twin data models need
Mainflux is coupled with the digital twin system using a service to be modular, extendable and interoperable. Multiple domains and
(Mainfluxsync). When a new IFC model is imported, an event is trig­ different scales need to be encompassed. Likewise, different types of
gered, and that service automatically sets up the Platform to accom­ data formats with various storage locations need to be contextualized
modate data produced on-site (see Fig. 18). and integrated. It is concluded that a given digital twin base software
Two main channels are created: the “Status” and “RawData” chan­ system needs to be modular, cloud-based, and operable through APIs.
nels. The former is dedicated to communicating and modifying the To develop a software system that can cope with such requirements,
configuration of connected devices deployed on-site. The latter is a knowledge graph-centred system is proposed. Knowledge graphs allow
dedicated to transmitting live measurements. IfcSensors imported into coupling the semantics of the IFC schema with other ontologies,
the system are mapped as things into the IoT platform and subsequently enabling wider data contextualization. The inherent flexibility of the
connected to both channels. Equivalent entities in the IoT platform and graph model allows dynamic model updates, and the use of modern
the BIM knowledge graph share Global Unique Identifiers (GUIDs), a key graph databases provides granular and efficient data exploration and
aspect for integration. Finally, IoT entities are imported into the graph querying.
according to the ontology. Fig. 19 displays the Mainflux IoT platform The system is developed using a micro-service architecture, which
GUI with the initial setup. facilitates Cloud deployment and enables modularly defined function­
Mainflux “Things” and IfcSensors sharing GUID are explicitly con­ alities. Those functionalities include (1) importing IFC models, which
nected using an IS_A relation within the graph, indicating the equiva­ are transformed into a graph model, (2) linking process data stored in a
lency of both entities (see Fig. 20). This enables bridging the gap local database and (3) linking sensor data stored in an external IoT
between BIM and IoT allowing contextualized interaction with IoT data platform. The knowledge graph acts as the contextual interface that
through semantic queries. Fig. 21 shows an example of a human- provides a comprehensive view of all data and all models forming a
readable query subsequently written using Cypher. The result shows Digital Twin. The knowledge graph allows us to perform complex
BIM-IoT-Process linked data. queries across data. The system can be thus extended with additional on-
demand data sources following the ontology-based integration pre­
7. Conclusions sented throughout this paper.
The Knowledge Graph has been tested for practical implementation
Digital twins are being adopted across industries and are continu­ in a set of demonstrators. It is observed that this framework represents a
ously evolving to adapt to industry needs. Wide-scoped and fragmented versatile technological compound for the creation of digital twins for
characteristics of the built environment impose specific requirements on built assets. The framework bridges the gap of how DTs can integrate

19
C. Ramonell et al. Automation in Construction 156 (2023) 105109

BIM with IoT systems and other data silos, regardless of the type of in­ Technologies and Skills, Springer international publishing, 2021, pp. 131–155.
ISBN: 9783030824303.
formation therein contained.
[16] E. Halmetoja, The role of digital twins and their application for the built
The research group is presently developing Knowledge-Graph-based environment, in: Industry 4.0 for the Built Environment: Methodologies,
technologies for many demo cases depicted in this paper. This will result Technologies and Skills, Springer International Publishing, 2022, pp. 415–442.
in a set of information pipelines that extract and operate with data ISBN: 9783030824303.
[17] The official Portal for European Data. [Link]. [Link]
connecting computational agents both internally (integrated into the (accessed May 16, 2023).
system as microservices) and externally (connected through the system [18] A. Lukaszewska, M. Gilun, F. Johansson, R. Jongeling, R. Tomar, C. Claeson-
API). Authentication management, data security, and improvement of Jonsson, M. Jungmann, J. Campos, J. Gonçalves, V.K. Papanikolaou, R. Chacón, D.
G. Carrera, C. Ramonell, H. Posada, L. Ungureanu, S. Skaric, I. Stipanovič, D7.1
interaction workflows with the system are subsequent steps for ASHVIN Technology Demonstration Plan, 2021.
development. [19] BIM Dictionary. [Link] (accessed Feb. 10, 2023).
[20] International Organization for Standardization, ISO 19650 BIM Building
Information Modelling | BSI. [Link]
Declaration of Competing Interest (accessed Feb. 16, 2023).
[21] X.I.N.G. Xuejiao, Z. Botao, L. Hanbin, G.C. Hongliang, G. Chen, Automatic code
The authors declare the following financial interests/personal re­ compliance checking for design drawings of architecture major and its key
technologies based on BIM, J. Civ. Eng. Manag. 36 (05) (2019) 129–136, https://
lationships which may be considered as potential competing interests: [Link]/10.13579/[Link].2095-0985.2019.05.019.
Rolando Chacon reports financial support was provided by Horizon [22] J. Teizer, J. Melzner, BIM for construction safety and health, in: Building
Europe. Information Modeling: Technology Foundations and Industry Practice, 2018,
pp. 349–365. ISBN: 9783319928616.
[23] T. Fink, BIM for structural engineering, in: Building Information Modeling:
Data availability Technology Foundations and Industry Practice, 2018, pp. 329–336. ISBN:
9783319928616.
[24] A. Braun, S. Tuttas, U. Stilla, A. Borrmann, Bim-based progress monitoring, in:
The data that has been used is confidential.
Building Information Modeling: Technology Foundations and Industry Practice,
2018, pp. 463–476. ISBN: 9783319928616.
Acknowledgements [25] C.V. Treeck, R. Wimmer, T. Maile, BIM for energy analysis, in: Building
Information Modeling: Technology Foundations and Industry Practice, 2018,
pp. 337–347. ISBN: 9783319928616.
This paper was prepared in the context of project ASHVIN. ASHVIN [26] A. Seyrfar, I. Osman, H. Ataei, BIM and building emergency response management:
has received funding from the European Union’s Horizon 2020 research review of applications, For. Eng. (2022) 613–619, [Link]
and innovation programme under grant agreement No 958161. This 9780784484548.063.
[27] H. Alavi, R. Bortolini, N. Forcada, BIM-based decision support for building
publication reflects only author’s view and that the European Com­ condition assessment, Autom. Constr. 135 (2022) 104117, [Link]
mission is not responsible for any uses that may be made of the infor­ 10.1016/[Link].2021.104117.
mation it contains. The first author acknowledges the funding of the FI- [28] IFC4.3.1.0 Documentation. [Link]
(accessed May 16, 2023).
2021 AGAUR PhD grant. [29] P. Pauwels, D. Shelden, J. Brouwer, D. Sparks, S. Nirvik, T.P. McGinley, Open data
standards and BIM on the cloud, in: Buildings and Semantics, CRC press, 2022,
References pp. 101–136. ISBN: 9781032023120.
[30] W. Solihin, C. Eastman, Y.C. Lee, D.H. Yang, A simplified relational database
Schema for transformation of BIM data into a query-efficient and spatially enabled
[1] ASHVIN – Digitising and Transforming the European Construction Industry. htt
database, Autom. Constr. 84 (2017) 367–383, [Link]
ps://[Link]/ (accessed Jan. 17, 2023).
autcon.2017.10.002.
[2] Home - Cogito. [Link] (accessed May 22, 2023).
[31] S. Das, J. Srinivasan, M. Perry, E.I. Chong, J. Banerjee, A tale of two graphs:
[3] BIMprove H2020 - Build Smarter, Cleaner, Cheaper. - Build Smarter, Cleaner,
property graphs as RDF in Oracle, EDBT (2014, March) 762–773, [Link]
Cheaper. [Link] (accessed May 22, 2023).
10.5441/002/edbt.2014.82.
[4] HOME - BIM2TWIN. [Link] (accessed May 22, 2023).
[32] Neo4j, Neo4j Graph Data Platform | Graph Database Management System.
[5] L. Li, S. Aslam, A. Wileman, S. Perinpanayagam, Digital twin in aerospace industry:
[Link] (accessed Feb. 10, 2023).
a gentle introduction, IEEE Access 10 (2021) 9543–9562, [Link]
[33] R. Angles, H. Thakkar, D. Tomaszuk, Mapping RDF databases to property graph
10.1109/ACCESS.2021.3136458.
databases, IEEE Access 8 (2020) 86091–86110, [Link]
[6] M. Alazab, L.U. Khan, S. Koppu, S.P. Ramu, M. Iyapparaja, P. Boobalan, T. Baker, P.
ACCESS.2020.2993117.
K.R. Maddikunta, T.R. Gadekallu, A. Aljuhani, Digital twins for healthcare 4.0-
[34] J. Barrassa, A. Cowley, Neosemantics (n10s): Neo4j RDF & Semantics toolkit -
recent advances, architecture, and open challenges, in: IEEE Consumer Electronics
Neo4j Labs. [Link] accessed Feb. 10, 2023.
Magazine, 2022, [Link]
[35] R. Stuger, V.R. Benjamins, D. Fensel, Knowledge engineering: principles and
[7] I. Onaji, D. Tiwari, P. Soulatiantork, B. Song, A. Tiwari, Digital twin in
methods, Data Knowl. Eng. 25 (2) (1998) 161–197, [Link]
manufacturing: conceptual framework and case studies, Int. J. Comput. Integr.
S0169-023X(97)00056-6.
Manuf. 35 (8) (2022) 831–858, [Link]
[36] OWL, OWL - Semantic Web Standards. [Link] (accessed Feb.
0951192X.2022.2027014.
10, 2023).
[8] M. Pregnolato, S. Gunner, E. Voyagaki, R. De Risi, N. Carhart, G. Gavriel, P. Tully,
[37] A. Hogan, E. Blomqvist, M. Cochez, C. d’Amato, G.D. Melo, C. Gutierrez, J.E. Labra
T. Tryfonas, J. Macdonald, C. Taylor, Towards civil engineering 4.0: concept,
Gayo, S. Kirrane, S. Neumaier, A. Polleres, R. Navigli, A.N. Ngonga, S.M. Rashid,
workflow and application of digital twins for existing infrastructure, Autom.
A. Rula, L. Schmelzeisen, J. Sequeda, S. Staab, A. Zimmermann, Knowledge graphs,
Constr. 141 (2022) 104421, [Link]
ACM Comput Surveys (CSUR) 54 (4) (2021) 1–37, [Link]
[9] E. VanDerHorn, S. Mahadevan, Digital twin: generalization, characterization and
arXiv.2003.02320.
implementation, Decis. Support. Syst. 145 (2021) 113524, [Link]
[38] J. Barrasa, A.E. Hodler, J. Webber, Knowledge Graphs. Data in Context for
10.1016/[Link].2021.113524.
Responsive Businesses, O’Reilly Media, Inc, 2021. ISBN: 9781098104856.
[10] J.M.D. Delgado, L. Oyedele, Digital twins for the built environment: learning from
[39] DBpedia Association. [Link] (accessed Feb. 10, 2023).
conceptual and process models in manufacturing, Adv. Eng. Inform. 49 (2021)
[40] Wikidata. [Link] (accessed Feb. 10,
101332, [Link]
2023).
[11] Q. Lu, A.K. Parlikad, P. Woodall, G. Don Ranasinghe, X. Xie, Z. Liang,
[41] BabelNet. [Link] (accessed Feb. 10, 2023).
E. Konstantinou, J. Heaton, J. Schooling, Developing a digital twin at building and
[42] J. Hoffart, F.M. Suchanek, K. Berberich, G. Weikum, YAGO2: a spatially and
City levels: case study of West Cambridge campus, J. Manag. Eng. 36 (3) (2020),
temporally enhanced Knowledge Base from Wikipedia, Artif. Intell. 194 (2013)
05020004, [Link]
28–61, [Link]
[12] C. Boje, A. Guerriero, S. Kubicki, Y. Rezgui, Towards a semantic construction
[43] J. Akroyd, Z. Harper, D. Soutar, F. Farazi, A. Bhave, S. Mosbach, M. Kraft,
digital twin: directions for future research, Autom. Constr. 114 (2020) 103179,
Universal digital twin: land use, Data-Centric Eng 3 (2022), [Link]
[Link]
10.1017/dce.2021.21.
[13] Council, G, K. Lamb, Gemini Papers: Summary, Apollo - University of Cambridge
[44] J. Akroyd, S. Mosbach, A. Bhave, M. Kraft, Universal digital twin-a dynamic
Repository, 2022, [Link]
knowledge graph, Data-Centric Eng 2 (2021), [Link]
[14] R. Chacón, J.R. Casas, C. Ramonell, H. Posada, I. Stipanovic, S. Skaric,
dce.2021.10.
Requirements and challenges for infusion of SHM systems within digital twins
[45] Cambridge CARES. [Link] (accessed July
platforms, Struct. Infrastruct. Eng. (2023), [Link]
22, 2023).
15732479.2023.2225486.
[46] A. Chadzynsky, S. Li, A. Grisiute, F. Farazi, C. Lindberg, S. Mosbach, P. Herthogs,
[15] M. Kosicki, M. Tsiliakos, K. ElAshry, M. Tsigkari, Big data and cloud computing for
M. Kraft, Semantic 3D city agents—an intelligent automation for dynamic
the built environment, in: Industry 4.0 for the Built Environment: Methodologies,

20
C. Ramonell et al. Automation in Construction 156 (2023) 105109

geospatial knowledge graphs, Energy and AI 8 (2022) 100137, [Link] [59] A. Wagner, L.K. Moeller, C. Leifgen, C. Eller, Building Product Ontology. https
10.1016/[Link].2022.100137. ://[Link]/ontologies/bpo/, Nov. 04, 2019.
[47] A. Chadzynski, N. Krdzavac, F. Farazi, M.Q. Lim, S. Li, A. Grisiute, P. Herthogs, [60] M.H. Ramussen, M. Lefrançois, M. Bonduel, Ontology for Property Management.
A. von Richthofen, S. Cairns, M. Kraft, Semantic 3D city database — an enabler for [Link] 2018, November 21.
a dynamic geospatial knowledge graph, Energy and AI 6 (2021) 100106, https:// [61] A. Wagner, M. Bonduel, P. Pauwels, OMG: Ontology for Managing Geometry. https
[Link]/10.1016/[Link].2021.100106. ://[Link]/ontologies/omg/, 2019, November 12.
[48] National Digital Twin Programme, Centre for Digital Built Britain completed its [62] A. Wagner, M. Bonduel, P. Pauwels, R. Uwe, Relating geometry descriptions to its
five-year mission and closed its doors at the end of September 2022. [Link] derivatives on the web, in: 2019 European Conference on Computing in
[Link]/what-we-did/national-digital-twin-programme (accessed May 16, Construction, European Council on Computing in Construction (EC3), 2019,
2023). pp. 304–313, [Link]
[49] S. Hayes, C. Dent, B. Mawdsley, R. Judson, T. Collingwood, CReDo: overview [63] N. Sahlab, S. Kamm, T. Müller, N. Jazdi, M. Weyrich, Knowledge graphs as
report, Apollo - University of Cambridge Repository, 2022, [Link] enhancers of intelligent digital twins, in: 2021 4th IEEE International Conference
10.17863/CAM.82908. on Industrial Cyber-Physical Systems (ICPS), IEEE, 2021, May, pp. 19–24, https://
[50] J. Akroyd, CReDo Methodology Papers: Implementation, Apollo - University of [Link]/10.1109/ICPS49255.2021.9468219.
Cambridge Repository, 2022, [Link] [64] Docker. [Link] (accessed July 22, 2023).
[51] P. Pauwels, A. Costin, M.H. Rasmussen, Knowledge graphs and linked data for the [65] Docker Hub. [Link] (accessed July 22, 2023).
built environment, in: Industry 4.0 for the Built Environment: Methodologies, [66] Neo4j Graph Database & Analytics | Graph Database Management System.
Technologies and Skills, Springer international publishing, 2021, pp. 157–183. [Link] (accessed July 22, 2023).
ISBN: 9783030824303. [67] MongoDB. [Link] (accessed July 22, 2023).
[52] P. Pauwels, W. Terkaj, EXPRESS to OWL for construction industry: towards a [68] Messaging that Just Works — RabbitMQ. [Link] (accessed
recommendable and usable IfcOWL ontology, Autom. Constr. 63 (2016) 100–133, May 16, 2023).
[Link] [69] IfcOpenShell - The Open Source IFC Toolkit and Geometry Engine. https:
[53] D. Mavrokapnidis, K. Katsigarakis, P. Pauwels, E. Petrova, I. Korolija, D. Rovas, //[Link]/ (accessed Feb. 12, 2023).
A linked-data paradigm for the integration of static and dynamic building data in [70] neosemantics (n10s): Neo4j RDF & Semantics toolkit - Neo4j Labs. [Link]
digital twins, in: Proceedings of the 8th ACM International Conference on Systems com/labs/neosemantics/ (accessed July 22, 2023).
for Energy-Efficient Buildings, Cities, and Transportation, 2021, pp. 369–372. [71] Neo4j Python Driver 5.8 — Neo4j Python Driver 5.8. [Link]
ISBN: 9781450391146. cs/api/python-driver/current/ (accessed May 15, 2023).
[54] M.H. Rasmussen, M. Lefrançois, G.F. Schneider, P. Pauwels, BOT: the building [72] J. Zhu, P. Wu, X. Lei, IFC-graph for facilitating building information access and
topology ontology of the W3C linked building data group, Semantic Web 12 (1) query, Autom. Constr. 148 (2023) 104778, [Link]
(2021) 143–161, [Link] autcon.2023.104778.
[55] P. Pauwels, Building Element Ontology. [Link] [73] Pydantic. [Link] (accessed May 19, 2023).
nt/[Link], 2020 accessed Feb. 12, 2023. [74] Cypher. [Link] (accessed May 19, 2023).
[56] P. Pauwels, Distribution Element Ontology. [Link] [75] NAP 2–4-2.0 PRUEBAS DE CARGA. [Link]
ionelement/[Link], 2019 accessed Feb. 12, 2023. [Link]/v0/AB0851B0FE894FBAC1258668003D4617/$FILE/NAP%
[57] A.-H. Hamdan, M. Bonduel, R.J. Scherer, An Ontological Model for the 202-4-2.0_Pruebas%20de%[Link]?OpenElement (accessed July 22, 2023).
Representation of Damage to Constructions, Accessed: Feb. 12, 2023. Available: htt [76] A. Keränen, C. Bormann. Sensor Measurement Lists (SenML) Fields for Indicating
p://[Link]/1999/02/22-rdf-syntax-ns. Data Value Content-Format RFC 9193 2023, 2020 doi:10.17487/rfc9193.
[58] A.-H. Hamdan, R.J. Scherer, Integration of BIM-related Bridge Information in an
Ontological Knowledgebase, Accessed: Feb. 12, 2023. [Online]. Available: htt
ps://[Link]/Alhakam/bridgeOntology.

21