Building a Knowledge Base of Bridge Maintenance Using Knowledge Graph

. To efectively manage the heterogeneous and discrete knowledge of the bridge maintenance domain, this study adopts knowledge graph technology to build a knowledge base of bridge maintenance, called the bridge maintenance knowledge graph (BMKG). Te BMKG uses an ontology as the knowledge organization and representation framework and a graph database as the knowledge storage tool. To facilitate the construction of the BMKG, a hybrid method combining a top-down approach and a bottom-up approach is proposed. Firstly, a bridge maintenance domain ontology (BMDO) is coded with Prot´eg´e and represented in Web Ontology Language. Secondly, rule reasoning and ontology reasoning are implemented on the BMDO in Prot´eg´e in order to automatically complete missing relations or attribute values. Tirdly, ontology reasoning is adopted to perform consistency check on the BMDO. Lastly, the BMDO model is stored in the Neo4j graph database through data format conversion, thus completing the construction of the BMKG. Te BMKG is applied in a typical scenario of bridge maintenance to demonstrate its application value. Results show that the proposed hybrid method can create a knowledge graph that can realize the transformation from discrete data into interconnected knowledge. Knowledge graph ofers a novel idea to create a knowledge base in the bridge maintenance domain.


Introduction
Accessing holistic knowledge is essential for bridge engineers to make a comprehensive maintenance decision [1]. However, the form of bridge maintenance knowledge is various, such as books, standards, manuals, and guides. Te knowledge about bridge maintenance has the following characteristics: multisource, wide range, complex relation, fragmented distribution, unstructured representation, and decentralized storage. To assist engineers in making a comprehensive decision through integrating various bridge maintenance knowledge, many bridge management systems [2][3][4][5] have been developed in diferent countries or regions. A relational database (RDB) is often used to store bridge maintenance knowledge in these systems [6]. For example, the National Bridge Inventory database, a database of more than 600 thousand bridges on public highways in America, contains design information, the operational conditions, and the structural condition of the diferent bridge components [7]. Caprani and Maria [8] created a global long-span bridge database of 751 long-span bridges. Pan et al. [9] constructed a database to store the knowledge relevant to management and maintenance of railway bridges. Tese systems or knowledge bases are developed independently and deployed separately. As a result, a heterogeneous semantics problem exists among these knowledge bases due to the design diferences of RDB [10], which can cause bridge maintenance knowledge to be hard to share and reuse. It is difcult for bridge engineers to integrate the scattered knowledge required to make bridge maintenance decisions in the absence of efective tools. Terefore, it is necessary to adopt an efective tool to manage the heterogeneous and discrete knowledge of bridge maintenance domain.
In recent years, knowledge graph (KG) has become to be one of the most efcient and efective knowledge integration methods [11]. In the construction domain, KG is considered to be the most advanced knowledge management technology nowadays [12]. KGs can essentially be termed as ontological semantic networks based on graphics [13], and its edges and paths can capture complex relations between the entities of a domain [14]. Terefore, KG has the potential to represent the intricate knowledge of bridge maintenance. KG is comprised of a schema layer and a data layer [12]. Te schema layer mainly consists of concepts and conceptual relationships, which are built through ontologies. Te ontology is generally regarded as the conceptualization of terms and their relationships of a domain and contains concepts, instances, relations, etc [15]. Te data layer primarily refers to interconnected entities that are instances of the concepts defned in the schema layer [16]. At present, related researches are focus on KG and ontology, respectively.
Researches on KG in the construction domain have already been carried out. Wang et al. [17] constructed a building fre KG to achieve the intelligent review of fre drawings. Rasmussen et al. [18] adopted a construction project KGs to manage interrelated information. Fang et al. [19] applied KG to identifying hazards on construction sites. However, due to the complexity of KG, there are only a few research results relevant to KG in the bridge engineering domain [10]. For example, Ma et al. [20] thought of KG as a future vision for a standardized database of fatigue cracks on steel box girders. Yang et al. [10] viewed KG as the core of the intelligent bridge management and maintenance framework based on big data knowledge engineering. Tiwary et al. [21] proposed a KG framework for monitoring and analysis of bridges. Luo et al. [22] constructed a Chinese bridge inspection knowledge graph. Te construction method they proposed is directly related to bridge component, which are specifc entities of the KG they constructed. Tus, this construction method does not have generality. In summary, in bridge engineering, research on KG is still in the initial stage, where KG is only regard as a vision or a part of a framework and the construction method of KG is inadequate.
Actually, more research is devoted to the application of ontology in many aspects of the bridge engineering at present. Hui et al. [23] built a steel bridge ontology model that was applied to the bridge construction stage to evaluate the multiattribute information in the factory manufacturing of bridge precast components. Ren et al. [1] developed a bridge maintenance ontology (BrMontology), which covers bridge structure, bridge damages and their causes, solutions, big events. In the BrMontology, a bridge is only roughly decomposed into bridge elements, and the classifcation of bridge damages is also overbroad. Liu and El-Gohary [24] proposed a bridge ontology (BridgeOnto) based on bridge maintenance manuals in American. Te Bridge-Onto involves bridge elements, bridge defciencies, defciency causes, and maintenance actions. In the BridgeOnto, the types of bridge elements and bridge defciencies are meticulously divided. Regarding bridge health monitoring (BHM) in the maintenance stage, Li et al. [25] designed a bridge structure health monitoring ontology to integrate heterogeneous sensor data for BHM systems. Te fnegrained ontology model contains bridge structures, sensors, and sensory data. Yang et al. [26] established a structure ontology model of a continuous rigid frame bridge, and associated the structure ontology with a bridge inspection ontology and a bridge health monitoring ontology, thus achieving integrative management of inspection data and monitoring data. In the bridge rehabilitation stage, Wu et al. [27] developed a concrete bridge rehabilitation project management ontology, which covers rehabilitation tasks and constraints. However, these ontologies are mostly specifc to a particular stage of bridge maintenance or limited to a particular bridge. And they do not cover maintenance expenses (a critical factor in bridge maintenance decisionmaking) and quality inspection and evaluation for maintenance engineering. Consequently, these existing ontologies are insufcient to support the construction of a complete KG for bridge maintenance.
Tis study aims to build a knowledge base of bridge maintenance using knowledge graph, called the bridge maintenance knowledge graph (BMKG), to manage the heterogeneous and discrete knowledge of bridge maintenance domain. To achieve the purpose, a hybrid method combining a top-down approach and a bottom-up approach is proposed. Rule reasoning and ontology reasoning are introduced into the hybrid method to accelerate the construction of the BMKG. Te BMKG adopts an ontology as the knowledge organization and representation framework and a graph database as the knowledge storage method. A bridge maintenance domain ontology (BMDO) is developed to support the construction of the BMKG, as well as knowledge sharing and reuse. Te Neo4j graph database is adopted as a storage tool of the BMKG. Nodes and edges of the Neo4j can be used to connect scattered knowledge of bridge maintenance to a knowledge network.
Te remaining contents of the paper are organized as follows. Related concepts and method of knowledge graph construction are introduced in Section 2. Section 3 details processes of establishing the BMKG are presented. Section 4 illustrates an application case of the BMKG. Diferences between the Neo4j graph database and an RDB in the construction of a knowledge base are discussed in Section 5. Finally, the conclusions are drawn in Section 6.

Knowledge Graph Construction: Related
Concepts and Method 2.1. Related Concepts. Te term "ontology" fnds its roots in philosophy and refers to the essence of existence, reality, becoming, and the fundamental classifcations of being and their interconnections. In this study, ontology is the conceptualization of the terminology and relationships within a given domain [15]. It is commonly used as a knowledge representation method [28]. Te BMDO is a bridge maintenance domain ontology, which is used to represent information relevant to bridge maintenance. A KG primarily depicts the relationships among realworld entities, arranged in a graph structure [29]. Depending on the area covered, KGs can be classifed into two categories: domain KGs (e.g., geoscience knowledge graph [30] and the BMKG in this study) and general KGs (e.g., Freebase [31]). Domain KGs contain domain-specifc data with diferent attributes and data patterns. In contrast, general KGs emphasize the breadth of knowledge, covering multiple domains, and integrating more entities. However, their knowledge is not as exhaustive and precise as that of domain KGs.
Tere are similar components between an ontology model and a KG. Figure 1 presents the relationship between an ontology model and a KG. And their corresponding relationships are listed in Table 1.
Although an ontology model and a KG have similar components and even can be converted to one another, there are still diferences between them. First, ontology is concerned primarily with the defnition of concepts and relations of a domain, rather than the creation of many instances. On the contrary, KG is more focused on creating many instances [32]. Second, ontologies are usually stored in OWL (i.e., Web ontology language) fles [33], which is difcult to support efcient data access [34]. For a KG, a graph database is often adopted to storage knowledge. For the fle-based storage, the efciency of data access is lower [34]. Consequently, an ontology model is not widely used in the industry. For the graph database-based storage, the effciency of data access is higher. And a graph database can efciently support software development (e.g., the BMKG can be integrated into a bridge management system). As a result, a graph database gets more recognition in the industry [35].
A graph database is a database designed to store and query data represented in the form of a graph. It uses nodes and edges, instead of tables (common components of a relational database) to represent data. A graph database can be regard as a data storage tool of a KG. For example, the Neo4j graph database is a data storage tool of the BMKG in this study. We can regard a knowledge base which uses a graph database to store knowledge as a KG.
A knowledge base is a dataset with formal semantics that contains diverse types of knowledge such as rules, axioms, defnitions, and statements [36]. Figure 2 shows the relationship between a knowledge base, a KG, and the BMKG. Te kinds of knowledge bases are varied. A KG does not usually contain rules and is only one kind of knowledge base. Tere are many KGs in various felds, such as TCM (i.e., traditional Chinese medicine) knowledge graph [37] and geographic KG [38]. Te BMKG focuses on bridge maintenance domain and is one of KGs.

Construction Method.
Tere are usually two approaches to building KGs: bottom-up and top-down [30]. Te bottom-up approach starts with the construction of a data layer and subsequent defnition of a schema layer, and its reverse process is the top-down approach [30]. Te former is suitable for building a general knowledge graph, and the latter is extensively used in the construction of domain knowledge graphs [39]. A hybrid approach that combines the two is adopted to construct the BMKG in this study. In this method, at frst, the bridge maintenance domain ontology (BMDO) is created as the schema layer of the BMKG. And then specifc instances are extracted. As knowledge extraction progresses, the BMDO may be updated when there are challenges in accurately expressing these instances using its current concepts. A suggested workfow of the hybrid approach is illustrated in Figure 3. Te proposed hybrid method is entirely unrelated to specifc concepts and entities of the BMKG. Hence, the proposed method has better generality than the existing construction method [22] of KGs in bridge domain.
Te defnition of a schema layer (steps 1 to 6) draws on the method for ontology construction, and the detailed implementation process is out of scope and can be found in an existing research work [34]. After the defnition, the process of data gathering and knowledge acquisition can take place under the guidance of classes, datatype properties, and object properties. Since bridge maintenance activities are usually performed based on relevant standards, the data sources of the BMKG mainly contain various forms of standards, guides, and manuals. Knowledge acquisition is the process of extracting entities, attributes, and relations. Tis process can be implemented by automatic [40] or manual extraction methods. Tis study, as a preliminary exploration, will adopt the manual extraction method to acquire the domain knowledge of bridge maintenance. In the next step, ontology modeling is to formalize domain knowledge with the OWL language. After that, rule reasoning and ontology reasoning are introduced for knowledge graph completion, and consistency check is required for ensuring the quality of an ontology model. In the fnal step (step 14), the OWL ontology fle will be converted and stored in the Neo4j, thereby completing the construction of the BMKG.

Design of the BMDO.
Te BMDO includes a bridge structure ontology, a bridge defect ontology, and a bridge maintenance ontology. Each ontology model generally consists of fve components: class, instance, relation, axiom, and function [15]. Te BMDO can also be defned as a fve tuple: where BMDO refers to the bridge maintenance domain ontology. C denotes concepts (also called classes) in the bridge maintenance domain, and technical terms relevant to Advances in Civil Engineering bridge maintenance (e.g., bridge, defect, and maintenance action) can usually be abstracted to the concepts. I represents instances (also called individuals), which are specifc objects of concepts. For example, Jiuzhou Channel Bridge (a bridge of Hong Kong-Zhuhai-Macao Bridge) is an instance of the "Bridge" concept. R stands for relations, including the relationship between concepts and instances, the relationship among instances, and properties of instances. For example, "has individual" is a relation linking the "Bridge" concept to the "Jiuzhou Channel Bridge" individual. When OWL ontology is used to formalize knowledge, a relationship among instances and a property of instances are also called object property and datatype property, respectively. F denotes functions, which are special relations. Rules can often be used to defne custom functions. A represents axioms (including constraints on various relations), which are used to describe accepted theoretical knowledge of the bridge maintenance domain. For example, the "Jiuzhou Channel Bridge" individual can have the "length" datatype property, whose value must be numerical.
We followed construction steps of a schema layer to defne the classes, datatype properties, and object properties of the BMDO and manually extracted instances of the BMDO from Chinese standards related to bridge maintenance. Te detailed design of the BMDO can be described as follows.  Ontology reasoning Step 1: Determine the domain and scope of an ontology Step 2: Consider reusing existing ontologies Step 3: Enumerate important terms in the ontology Step 4: Define classes (also called concepts) and a class hierarchy Step 5: Define datatype properties Step 6: Define object properties Step 9: Attribute extraction Step 10: Relation extraction Step 8: Entity extraction Step 12: Knowledge graph completion

Bridge Structure Ontology.
Bridge structure is divided into fve levels: bridge, evaluation unit, bridge portion, bridge component, and bridge element [41]. Tese terms were modeled as concepts of the bridge structure ontology. Diferent from existing ontology models [25,26], in the bridge structure ontology, specifc portions, and components were modeled as corresponding instances in order to integrate the domain knowledge relevant to these instances. For example, the weights of portions and components [41] can be modeled into the bridge structure ontology in the form of datatype property. Moreover, other instances related to these instances can also be linked, thus forming a broader knowledge network. Additionally, to enhance the refnement of bridge maintenance strategies, "BridgeSubcomponent" and "BridgeSubelement" were added to the existing fve levels of the bridge structure ontology. At the same time, considering the demand for bridge asset management, "AncillaryFacility" was added to the bridge structure ontology as an instance of the "BridgePortion" concept. Te bridge structure ontology is shown in Figure 4. Te "BridgePortion" concept includes four instances: "Superstructure," "Substructure," "BridgeDeckSystem," and "AncillaryFacility." Te "AncillaryFacility" instance consists of the "MaintenanceAccess," "Damper," and other components [42]. Te "MainGirder" component was further subdivided into diferent subcomponents based on the material types, such as "PrestressedConcreteGirder," "Steel-concreteCompositeGirder," and "SteelBoxGirder." If the volume of an element is large, the element will be categorized into several subelements to describe the location of defects more accurately. For example, in Figure 4, the "BoxGir-der_BottomPlate" can be regard as a subelement of the "SteelBoxGirder_1" element. Figure 4 also illustrates the axiomatic constraints of the ontology model. For example, the value of the "Sidewalk" component's weight must be xsd: foat, such as 0.10.

Bridge Defect Ontology.
During bridge maintenance, bridge engineers need to adopt inspection methods to fnd out defects on bridge elements, identify the causes and hazards of the defects, and then determine evaluating degree of the defects according to the rating scheme for designating the degree of bridge defects [41]. Te relevant knowledge was modeled in the bridge defect ontology, as shown in Figure 5. Bridge defects are regarded as performance measures for assessing bridge condition in China, and each defect has its own rating scheme. In the ontology, the "Eval-uationIndicator" concept is proposed to represent these defects, and the "Defciency" concept represents defects that actually occur on bridge elements. However, we found that the existing classifcation of defects is relatively broad in the process of knowledge acquisition. For the same type of bridge defect, its inspection methods, causes, hazards, and repair methods could potentially be diferent [43]. For example, chalking and faking are two forms of coating deterioration, and their inspection methods are diferent [36]. Considering this situation, we introduced the "subindicator" concept into this ontology. In addition, the existing rating scheme only consists of qualitative descriptions and quantitative descriptions, which is not intuitive [43]. To address the problem, photographs associated with various degrees of bridge defects or subdefects are modeled as legends in this ontology.

Bridge Maintenance Ontology.
Determining maintenance actions is one of the core tasks of bridge maintenance. Te results of bridge inspection and assessment should directly serve the decision-making process. However, the current standard [38] only provides broad maintenance actions on bridges in diferent condition ratings, which causes a disconnection between the evaluating degree of bridge defects and maintenance actions. To solve this problem, in the bridge maintenance ontology (as shown in Figure 6), a semantic relationship "HasMaintenanceAction" between evaluating degrees and maintenance actions was established. Additionally, in order to support the optimal allocation of bridge maintenance funds, maintenance expenses [44] were incorporated into the bridge maintenance ontology. Te ontology also has covered the last stage of a bridge maintenance project (i.e., quality inspection and evaluation for maintenance engineering), including the "BasicRequirement," "AppearanceQuality," and "Measur-ementItem" concepts, which are derived from a current relevant standard [45].

Ontology Modeling.
Knowledge modeling of the BMKG refers to adopting the OWL language to formalize domain knowledge of bridge maintenance using Protégé 5.2.0 Ontology Editor. Figure 7 presents partial content of the BMDO model coded in OWL format. Te OWL vocabularies (i.e., elements prefxed with "owl:" in Figure 7) are used to express the ontology model. For example, the element prefxed with "owl:ObjectProperty" can defne the "HasSubcomponent" relation. And an additional "owl: inverseOf" constraint is imposed on this relation, which means that the "HasSubcomponent" relation is the inverse property of the "IsSubcomponentOf" relation. Te constraint can provide a foundation for relation completion based on ontology reasoning. Figure 8 shows a visual representation of the developed BMDO model in the Protégé platform.

Knowledge Graph Completion.
Although the BMDO has been manually developed, some potential knowledge needs to be excavated, such as the degree of the "Flaking_1" in the bridge defect ontology. Ontology reasoning and rule reasoning can be applied to mining hidden knowledge to automatically complete the missing relations or attribute values. Two following cases were used to show the process of knowledge graph completion.
To complete the missing relations, the Pellet 2.2.0 (a reasoning engine) was used to implement intelligent reasoning on the BMDO in Protégé, and the inference process is shown in Figure 9. In the BMDO, subcomponents of bridge Advances in Civil Engineering railing are unknown before the reasoning (see Figure 9(a)). After the reasoning (see Figure 9(b)), the "Railing" instance has the "HasSubComponent" semantic relationship with the "SteelRailing" and "ConcreteBarrier" instances, and the corresponding explanation related to the inference also is provided in Protégé. Tis indicates that ontology reasoning can automatically expose hidden relationships between instances, and reasoning results are interpretable. After executing the ontology reasoning, the BMDO model containing the inference results can be exported to a new ontology fle, thereby increasing the efciency of ontology construction.
To calculate the degree of the "Flaking_1," a rule reasoning will be implemented. Since the OWL language does not support writing custom rules, we adopted the Semantic Web Rule Language (SWRL) to defne the rating scheme. Table 1 gives the rating scheme for designating the degree of faking and corresponding SWRL rules. According to these rules, the rule reasoning was also automatically executed on the Pellet Reasoner in Protégé. Te inference is shown in Figure 10. After the rule reasoning, the degree of the "faking_1" defciency in the BMDO is 3, and the Protégé platform also provides an explanation for this inference. Tis inference is correct according to the rating scheme in Table 2, which verifes the efectiveness of the rule reasoning.

Consistency Check.
For checking the quality of the BMDO model, a consistency check at the syntactic and semantic level is required. Te consistency check can be automatically verifed by using the Pellet Reasoner in the Protégé environment, and the corresponding results are depicted in Figure 11. From Figures 11(a) and 11(b), it can be found that the conceptual hierarchy of the BMDO is unchanged before and after the ontology reasoning. Tis result indicates that the BMDO satisfes the requirements of logical axioms at the semantic level. In Figure 11(c), the inference log does not display grammatical errors, which confrms that the BMDO model conforms to the OWL syntax rules at the syntactic level. Tese results confrm that the BMDO passes the consistency check.

Knowledge Storage.
To improve the efciency of knowledge access, the OWL ontology fles will be converted and stored in a graph database. In this paper, Neo4j, a popular graph database management system [47], is chosen as a knowledge storage tool. Instances and their datatype properties, and object properties among instances in an OWL ontology model can be represented by nodes, node properties, and relationships in Neo4j, respectively.

Advances in Civil Engineering
Te OWL ontology fles can be automatically converted and stored into Neo4j using neosemantics plugin. Te bridge maintenance knowledge can be visualized in the form of relational graphs in Neo4j. Figure 12 presents a schematic diagram of the BMKG.

Application Case
Te BMKG integrates the discrete knowledge of bridge maintenance, such as bridge inspection, bridge evaluation, maintenance decision-making, quality inspection, and evaluation for maintenance engineering. A typical application case is adopted to demonstrate the application value of knowledge graph. During bridge inspection, a bridge inspector may be required to give suggestions on repairing defects. Te maintenance actions can be recommended through running Cypher query statements in the Neo4j database. Figure 13 shows the query result of the maintenance actions on the "SteelBoxGirder1" element. From the fgure, it can be seen that a "Flaking_1" defect with a degree of "3" occurs on the "BoxGirder_BottomPlate" subelement of the "Steel-BoxGirder_1" element. When the evaluating degree of a faking is 3, the corresponding maintenance action is "RepairCoating_4." Terefore, according to these logical chains, the maintenance action on the "SteelBoxGirder1" is "RepairCoating_4.". Tis result shows that the proposed BMKG can recommend feasible actions and provide a visual interpretation path.

Discussion
In existing practical applications, the bridge maintenance knowledge is represented and stored using an RDB, and related business logics are written in program codes. Advances in Civil Engineering forming a new knowledge structure. Te contrast between representation results based on the Neo4j graph database and a RDB is demonstrated in Table 3.
As can be seen from Table 3 and Figure 14, when the Neo4j graph database is adopted to represent the knowledge structure, the number of required nodes or relationships is same as that in the knowledge structure. It is easy to design a knowledge graph according to a knowledge structure. When a RDB is applied to representing the same knowledge structure, relationship types between entities should be taken into careful consideration to design tables and foreign keys of a RDB. For example, an extra foreign key or an association table needs to be created to represent a one-to-many relationship (one-direction arrows in Figure 14) or a manyto-many relationship (two-direction arrows in Figure 14), respectively. Tis indicates that it is easier to use a graph database to represent the bridge maintenance knowledge with complex relationships, compared with a RDB.
Furthermore, each node of the Neo4j graph database represents a specifc entity, and each entity can have its own properties. A table of a RDB stores multiple entities of the same type, and the felds of the table are constant. In other words, diferent entities in the same table share the same properties, which can lead to the emergence of data sparsity. As shown in Figure 15, for the "InternalDampness_1" defciency (a defciency that occurs in an anchorage of a cablestayed bridge), most of the felds in the "Defciency" table of a RDB do not have any value.
In terms of knowledge updating, when two new entities are added (as shown in Figure 14), two new nodes and eight new relationships need to be appended to the KG. For the same purpose, the foreign keys of three existing tables (i.e., "Defciency" table, "RatingScheme" table, and "Hazard" table) have to be modifed, and fve new tables require to be appended the RDB. Among these new tables, two foreign keys must also be added to the "BridgeSubcomponent" The proportion of places that that will be tested should be 5%, and its number is not less than 5. one place should be tested every element.

Inspection Frequency
The proportion of elements that will be tested should be 20%, and its number is not less than 5. 10 measure points should be tested every 10 m 2 , and 10 measure points must be tested.   Advances in Civil Engineering and the "Subindicator" table, respectively. In software development, adding new nodes and relationships in the Neo4j graph database has nearly no infuence on the existing program codes. However, the corresponding codes need to be modifed when existing tables of an RDB are modifed. Terefore, for bridge maintenance knowledge which needs to be updated frequently, the knowledge representation and storage method based on knowledge graphs can be a more suitable method. In terms of knowledge query, bridge experts can retrieve data from an RDB through a joined query only if they know the whole database schema. For example, to gain the query result in Figure 13, a joined query over at least fve tables is necessary to get feasible actions on a bridge element. However, bridge experts do not have to master the design schema of a KG completely, and they can use a path query without partial middle nodes and relations to retrieve data from a graph database. Te query results can be presented in a graphical format in Neo4j. Te Neo4j graph database reduces the difculty of knowledge acquisition and enables bridge experts to freely explore and analyze data in the BMKG without excessive dependence on database engineers.

HasSubclass
In terms of overall development cost, the overall development cost of a KG is less compared with an RDBbased knowledge base. First, for development time of a knowledge base, rule reasoning and ontology reasoning can autocomplete the missing relations or attribute values during KG construction. Terefore, compared with a traditional RDB-based knowledge base, we may spend less time on developing a KG at least in theory. Second, besides the development time of a knowledge base, it should be pay attention to the development time of a software because a knowledge base is often integrated into a software system (e.g., a bridge management system) to maximize its value. As updating a KG has a lower impact on existing program codes compared with updating an RDB-based knowledge base, we will also spend less time on developing a KG-based software system. Tird, for manpower cost, compared with traditional relational databases, a graph database reduces the difculty of designing and using a database, which will allow a bridge engineer to participate deeply in the construction of the BMKG. Te dependency on database engineers will be lowered accordingly.

Conclusions
Knowledge graph is an advanced knowledge management technology. In this study, a hybrid method for building knowledge graph is proposed to build a knowledge base for bridge maintenance, called the BMKG. Te main conclusions can be summarized as follows: (1) A knowledge graph, which adopts an ontology as the knowledge organization and representation framework and a graph database as the knowledge storage method, can be used to efectively manage the heterogeneous and discrete knowledge of the bridge maintenance domain. Knowledge graph ofers a novel idea for building a knowledge base for bridge maintenance.
(2) Compared with the existing construction method of knowledge graphs in bridge domain, the proposed hybrid method has better generality. Within the method, the rule reasoning and ontology reasoning can be employed for knowledge graph completion and can improve the construction efciency of knowledge graphs, and the consistency check contributes to ensuring quality of knowledge graphs. (3) In the BMKG, the developed BMDO covers comprehensive knowledge of the bridge maintenance domain, and enriches and deepens the concept system of existing ontologies in the bridge domain. Compared with a relational database, the graph database, the BMKG adopted is more suitable to store domain knowledge of bridge maintenance since it can be easy to design and reduce the emergence of data sparsity. (4) During the construction of the BMKG, it is timeconsuming to manually extract bridge maintenance knowledge. Automatic knowledge extraction methods will be taken into consideration in the future to accelerate the construction further.

Data Availability
All data generated or analyzed during this study are included in this published article.

Conflicts of Interest
Te authors declare that they have no conficts of interest.