## 1 Introduction  
### Review of Related Works  
Historic Building Information Modeling (HBIM) has been widely applied for digital documentation of cultural heritage and generally consists of several steps: onsite investigation, modeling, knowledge association, and delivery [1; 2; 3; 4]. With the increasing scale of a project, modeling and knowledge association become time-consuming, which rely on the development of tools or methods to check [5; 6; 7], exchange or transform [8; 9; 10; 11; 6; 12], extract or retrieve [13; 14; 15; 16; 17; 10; 12; 13; 12; 11; 10; 11; 12; 14; 15; 17], and match or map [13; 14; 15; 16; 17; 18; 19; 20].  
Ontology modeling is adopted for semantically indexing and retrieving information. [PERSON] and [PERSON] [16] developed a Java prototype application for generating ontology from the model. [PERSON] et al. [21] and [PERSON] et al. [22] focused on the development of the ontology for integration between GIS and BIM. To improve the efficiency of the query, [PERSON] et al. [13] proposed a method for mapping from ontology to graph database, improving the efficiency of the query. [PERSON] and [PERSON] [14] proposed a solution to retrieve relationship data from the IFC model of large quantities, then expressed in the graph database. [PERSON] et al. [23] developed an algorithm for twinning the model into the graph database, which was designed for IFC-based construction management information. The machine-learning and deep-learning methods were applied to automatically segment the point cloud by semantics [17; 20].  
However, with the development of the investigation, the models need to be updated dynamically, as well as the heterogeneous metadata. Mistakes may occur in practice. Using the integrated repository to exchange information was proven to be effective and flexible in application [24].  
It is worth noting that [PERSON] et al. [25] proposed a method that translated RDF data to IFC data, stored it in XML format, then generated the parametric model from the IFC XML. All the information was stored as an open-source data model. Once changes were applied, the RDF data could be correspondingly modified to fit the changes to the Revit model, simplifying the process.  
[PERSON] et al. [26] suggested the synergy between metamodel and ontology to integrate GIS and BIM. Compared to the metamodeling technique, data in ontologies were linked, rather than merged or transformed. The metamodel could be subdivided into four'metalevels':  
* M3: the meta-object facility or meta-metamodel, e.g., IFC XML;
* M2: the metamodel, e.g., IFC schema, structure;
* M1: the model, e.g., IFC file;
* M0: the real-world object, e.g., cultural heritage assets.  
The Grasshopper is a node-visible, visual programing, and open-source modeling platform in Rhino. It uses algorithm binaries as calculators of different functions. Through algorithm modeling, complex problems can be simplified and then form an automatic workflow to output models and data [27; 28].  
Therefore, in the Grasshopper platform, the algorithm binaries could be regarded as the M3 metalevel, the modularized cluster as the M2 metalevel, and the output geometry baked into Rhino as the M1 metalevel.  
Ontology could be regarded as the M2 metalevel, for it is written in XML format (M3 metalevel) to describe the model instance (M1 metalevel); however, it does not depend on the model instance [9; 29]. The Neo4j was selected as the platform to build the graph database, for its high performance in processing big data. The query speed will not decrease with the increasing scale of data [12; 13; 15; 30; 31; 32].  
In conclusion, it is relatively less complicated to manage data in the M3 or M2 metalevel and then distribute the data to the model in the M1 metalevel. This method needs further research to dynamically generate the IFC model along with its graph database.