## 5 Twinning the IFC-Based 4D Construction Management Information Model into Graph Database  
The IFC-based 4D construction information model of prefabricated buildings is established in Section 4, but the features of the IFC standard require a further operation of this information model. This section is the second part of the framework and twins the IFC-based 4D construction management information model into graph database. One feature of the IFC standard is that the reference relationship between the entities in the IFC-based information model is complicated, leading to the poor readability of the IFC files. Furthermore, the IFC files obtained in the previous step are hard to modify, update, and interoperate timely. Especially in the process of prefabricated building construction, many participants have the requirements to operate and exchange the data through IFC files. Thus, an automatic algorithm to parse and twin IFC files is necessary to reveal the IFC files complicated inner relationships in an intuitive graph and increase data interoperability for further management requests. This part is also the foundation of the following automated construction schedule analysis whose realization depends on the graph-based algorithm. The reasons to use graph database to store and twin the IFC-based information model are as follows. Firstly, the graph database is more suitable than the relational database to store the IFC information model. [PERSON] [50] transformed BIM data into an open relational database to make the BIM data accessible for wide ranges of query capabilities. [PERSON] [51] mapped the IFC schema into a relational database to support performance assessment and maintenance management. However, IFC schema is often large, such as IFC 4 \(\times\) 2 with 816 different entity types and has very complex relationships between entities. Therefore, using a relational database to store IFC requires creating extremely complex data tables and a lot of time-consuming cross-table joins to perform various complex queries. In addition, IFC entities have many attributes, which are sparse in the actual storage of relational databases. Therefore, the relational database is not suitable for the storage of IFC models. Secondly, the graph database is more ideal than other non-relational databases. Other research verified the NoSQL database's advantages in query speed and flexibility. [PERSON] [52] developed an open-source BIM server based on NoSQL database BerkeleyDB, which provides incremental model storage, extraction, and conversion functions. [PERSON] [53] realized IFC's storing for path planning based on MongoDB. [PERSON] et al. [54] developed a Web-based BIM collaboration based on MongoDB, which can query and edit objects in the model online. Except for the advantages of the NoSQL database, the graph database also supports complex entity-relationship networks and rich semantic inference at scale [55]. IFC files and graph database have the same graph format. The reference relationship between entities in the IFC files is analyzed and shown in Figure 8. In this figure, IfcProject has the highest level of construction tasks, which can be decomposed into different IfcTask Summary through hierarchical relationship. The IfcTask Summary can be further decomposed into specific IfcTask through hierarchical relationships. These entities' relationship is similar to the relationship between nodes in a graph database, as illustrated in Figure 9 [56]. This figure shows that a graph database can be seen as a combination of nodes and relationships. The graph database stores data in nodes with attribute values and uses relationships to organize these nodes, which are all consistent with IFC files' characteristics. Therefore, using graph database to store IFC files is more intuitive than other NoSQL databases. In addition, graph database's graph algorithm lays the foundation for analyzing IFC-based information models in the next step.