GOMS: Large‐scale ontology management system using graph databases

ETRI JournalVolume 44, Issue 5 p. 780-793 ORIGINAL ARTICLEFree Access GOMS: Large-scale ontology management system using graph databases Chun-Hee Lee, Corresponding Author Chun-Hee Lee ch.lee@etri.re.kr orcid.org/0000-0002-2668-8929 Intelligence Information Research Division, Electronics and Telecommunications Research Institute, Daejeon, Republic of Korea Correspondence Chun-Hee Lee, Intelligence Information Research Division, Electronics and Telecommunications Research Institute, Daejeon, Republic of Korea. Email: ch.lee@etri.re.krSearch for more papers by this authorDong-oh Kang, Dong-oh Kang Intelligence Information Research Division, Electronics and Telecommunications Research Institute, Daejeon, Republic of KoreaSearch for more papers by this author Chun-Hee Lee, Corresponding Author Chun-Hee Lee ch.lee@etri.re.kr orcid.org/0000-0002-2668-8929 Intelligence Information Research Division, Electronics and Telecommunications Research Institute, Daejeon, Republic of Korea Correspondence Chun-Hee Lee, Intelligence Information Research Division, Electronics and Telecommunications Research Institute, Daejeon, Republic of Korea. Email: ch.lee@etri.re.krSearch for more papers by this authorDong-oh Kang, Dong-oh Kang Intelligence Information Research Division, Electronics and Telecommunications Research Institute, Daejeon, Republic of KoreaSearch for more papers by this author First published: 08 December 2021 https://doi.org/10.4218/etrij.2021-0261 Funding information: Electronics and Telecommunications Research Institute(ETRI) grant funded by the Korean government, Grant/Award Number: 21ZS1100 AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinked InRedditWechat Abstract Large-scale ontology management is one of the main issues when using ontology data practically. Although many approaches have been proposed in relational database management systems (RDBMSs) or object-oriented DBMSs (OODBMSs) to develop large-scale ontology management systems, they have several limitations because ontology data structures are intrinsically different from traditional data structures in RDBMSs or OODBMSs. In addition, users have difficulty using ontology data because many terminologies (ontology nodes) in large-scale ontology data match with a given string keyword. Therefore, in this study, we propose a (graph database-based ontology management system (GOMS) to efficiently manage large-scale ontology data. GOMS uses a graph DBMS and provides new query templates to help users find key concepts or instances. Furthermore, to run queries with multiple joins and path conditions efficiently, we propose GOMS encoding as a filtering tool and develop hash-based join processing algorithms in the graph DBMS. Finally, we experimentally show that GOMS can process various types of queries efficiently. 1 INTRODUCTION An ontology is an explicit representation of things and their relationships [1]. We can represent knowledge by ontologies and infer new information from schemas and facts represented by ontologies. Ontology construction is one of the most important parts of ontology research, but it is difficult to construct a large-scale ontology due to the construction cost and complexity of ontologies. Fortunately, several large-scale ontologies such as YAGO, DBPedia, and Freebase [2-4] have been constructed because of the explosive growth of the worldwide web and the emergence of the web collaborated by any web users such as wiki. However, even though large-scale and general-purpose ontologies are now available, it is difficult to manage and infer them due to their large size. For instance, reasoning engines cannot work well for large-scale ontologies. Furthermore, because ontology data structures differ from traditional data structures, using and adapting mature database management systems (DBMSs) is difficult. To solve these problems, we propose a graph database-based ontology management system called GOMS. GOMS uses a graph DBMS to manage large-scale ontology data because ontology data structures show similarities to graph data structures. To support various reasoning capabilities of ontologies on graph DBMSs, GOMS precomputes some of the reasoning capabilities and evaluates the other part using the powerful function of graph DBMSs. As one of the main characteristics, GOMS supports user-friendly query templates for finding key nodes. In general, users who want to use ontology data as a knowledge base are unfamiliar with ontology terminologies (that is, uniform resource identifiers [URIs]) because the names of terminologies have long words as a URI to avoid homonyms. To explore or extract some information from ontology data, users might need to specify some terminologies in a cypher query. GOMS provides query templates for finding terminologies using main node matching and common ancestor/descendant node matching in a directed acyclic graph (DAG). 11 Ancestor or descendant relationships in a DAG can be defined by topological order. In addition, because the processing cost of finding common ancestor/descendant nodes in a large DAG is high, GOMS uses a hash-based join and an encoding method. Our study has four major contributions. The first two parts are conceptual contributions with limited technical depth, whereas the last two parts are developed with greater technical depth. Utilization of graph databases: We use graph databases to manage large-scale ontology data. Graph DBMSs can process path-related operations and node traversals efficiently. Furthermore, to support various reasoning capabilities, we precompute some parts of reasoning capabilities and evaluate the other part using path-related operations of graph DBMSs during query processing. Support of user-friendly query templates: We provide query templates for users to find key concepts or instances in a large-scale ontology. Query templates for main node matching are to find main concepts/instances from a given string keyword provided by users, and query templates for common node matching are to find common superclasses and subclasses (that is, generic concepts or detailed concepts) from multiple terminologies. Encoding method for node filtering: We propose a node encoding method to filter out nodes effectively with only two numbers. Furthermore, we derive a theorem and lemma to apply node filtering. Query Processing algorithms to process query templates for common node matching: We propose algorithms to process query templates for common node matching. To evaluate query templates efficiently, we use a hash-based join and our encoding method. The rest of this study is organized as follows. In Section 2, we will discuss the related work. In Section 3, we will describe the architecture of GOMS, and in Section 4, we will explain the basic storage design and query templates of GOMS. Encoding and query processing algorithms will be explained in Section 5. Finally, we will present experimental results in Section 6 and conclude our study in Section 7. 2 RELATED WORK Ontologies have been widely used in many areas to represent data semantics [5-8]. The semantic web [6], which is the next generation web, can be constructed using an ontology representation language such as web ontology language (OWL). By representing the web by the ontology language, a machine can understand the web and provide more abundant information than the current web. Question answering systems [7] also use ontologies to answer user questions. To answer user questions correctly, systems must understand the semantics of these questions and retrieve and infer the relevant information from ontologies. Furthermore, recently, visual question answering systems [8, 9] have been studied extensively. Given a visual image and text question, such systems attempt to find answers using the visual image's information. To provide more accurate answers, some systems use ontology data. Ontologies can also be used in the biology field. To understand biological interactions deeply in terms of genetic biology, the gen ontology [5] has been built. To manage and infer ontologies, many systems have been developed. We can classify those systems into two categories, reasoning-oriented systems and scalability-oriented systems. Reasoning-oriented systems focus on reasoning capabilities. Implicit information can be inferred using them. However, in many cases, they are inappropriate for managing large-scale ontology data. Scalability-oriented systems attempt to store and query large-scale ontology data with small reasoning capabilities or without reasoning. They provide a store to effectively save ontology data and a query engine to efficiently process a given query such as SPARQL. Many reasoners, such as Pellet, FaCT++, and Jena inference engine [10-12], can be considered as reasoning-oriented systems. Jena, one of the best known ontology framework, provides a platform to use both sides, reasoning-oriented part and scalability-oriented part. In the aspect of reasoning-oriented systems, Jena provides built-in ontology reasoners such as OWL and RDFS. Moreover, Jena provides a store to save large-scale ontology data, called triple store in the aspect of scalability-oriented systems. In Jena Triple Store, ontology data can be queried using SPARQL. KAON2 (the next version of KAON) [13] supports the manipulation of ontology data such as OWL-DL and F-logic as a reasoning-oriented system. Although KAON2 supports SPARQL partially, it does not support graph patterns of SPARQL. Scalability-oriented systems primarily use a DBMS to solve data scalability. In this study, we focus on scalability-oriented systems. OntoDB [14-16] as a scalability-oriented system provides a platform to manage large-scale ontology data based on PostgreSQL. For effective table design, OntoDB uses the "table-per-class" schema. Each class relates to one table. Furthermore, OntoDB provides OntoQL as a query language. ONTOMS (ONTOlogy Manageement System) and ONTOMS2 [17, 18] have been proposed as a scalability-oriented system to store and query large-scale OWL [19] data on relational DBMSs (RDBMSs). ONTOMS stores OWL data into RDBMSs and provides reasoning capabilities such as inverseOf, symmetric, and transitive properties, whereas ONTOMS2 supports incremental update, as a new version of ONTOMS. In ONTOMS, Park et al. use the class-oriented approach to store ontology data. Each class and related properties consist of one relational table. Furthermore, they provide instance reasoning on RDBMSs with the IST theorem. ALAmri proposes a method for storing OWL data into RDBMSs using five mapping rules [20]. Zhang et al. [21] invent an OWL storage system in an object-oriented DBMS (OODBMS). After storing OWL data into the OODBMS, data can be accessed using regular OODBMS queries. However, ontology data structures are intrinsically different from relational or object-oriented data. Therefore, scalability-oriented systems using RDBMSs or OODBMSs have many limitations. Recently, graph databases [22-27] have been spotlighted because large amounts of graph data such as social and biological networks have been generated because of technological advancement. Many graph DBMSs such Neo4j, ArangoDB, OrientDB, and RedisGraph have been developed to store and query graph data [22]. Based on graph DBMSs, an approach developed an ontology storage system [28] in the aspect of scalability-oriented systems. A study [28] considered and thoroughly surveyed multiple graph DBMSs. Finally, Neo4j was selected in [28], and the Freebase ontology was stored on Neo4j. However, this approach looks straightforward, and more advanced reasoning techniques are required. Nowadays, knowledge graph embedding has been actively studied [29-31]. Knowledge graph embedding attempts to find low-dimensional vectors for nodes and relationships such that similar nodes have a low distance value and dissimilar nodes have a high distance value in a vector space. In knowledge graph embedding, two nodes are considered similar if they have similar graph structures. Some knowledge graph embedding techniques attempt to integrate text information with knowledge graph embedding. In that case, node embedding values can have text semantics as well as graph semantics. These might provide us with another type of semantics compared with semantics in ontologies. Therefore, if we integrate ontology management systems with knowledge graph embedding, synergy will be created. For example, we can add potential relationships to existing ontologies using link prediction on knowledge graph embedding. Based on improved ontologies, we can infer in the same way as before. Furthermore, if a given query from a user has no results due to the incompleteness of ontology data, we can process the query after extending semantics by connecting similar nodes in terms of knowledge graph embedding. In addition, we will discuss the checking problem of ancestor/descendant relationships in a graph. To help graph DBMSs find paths efficiently, we propose GOMS Encoding as a filtering technique for ancestor/descendant relationships in a DAG in terms of topological order. The checking problem of ancestor/descendant relationships in a DAG is similar to the graph reachability problem [32-39]. Agrawal et al. [32] propose Tree Cover to manage large transitive relationships, and Tree Cover is used for effective transitive closure compression. Note that the transitive closure problem is considered a graph reachability problem. To efficiently check transitive relationships, Agrawal et al. [32] use intervals generated by postorder traversal in a tree structure. To apply these intervals to a DAG, they propose a method for finding an optimal spanning tree, which reduces the number of interval sets. Cohen et al. [33] propose a two-hop cover to solve the graph reachability problem. Each node has Lin and Lout labels, and the graph reachability for any node u and v can be checked by Lin and Lout of u and v. In addition, Wang et al. [37] propose dual labeling to answer graph reachability queries in a constant time, but they assume that a graph is sparse, and the number of non-tree nodes is significantly less than the number of the total nodes. Jin et al. [35] invent Path-Tree Cover to check graph reachability efficiently. They decompose a graph into path sets and then construct a path graph whose node is a path. Although the above approaches are powerful to check if two nodes are reachable, they are inappropriate as a filtering tool in a graph DBMS because their index size is large or their query processing methods are complicated to apply on a graph DBMS. The aim of our encoding method is to help a graph DBMS find common ancestor/descendant nodes more efficiently. 3 ARCHITECTURE In this section, we will describe the architecture of GOMS. As shown in Figure 1, GOMS consists of two parts, store manager and query manager. Store manager stores ontology data into a graph DBMS. We use Neo4j as a graph DBMS because it is well known and one of the most commonly used graph DBMSs. To store ontology data, the data transformation module of store manager transforms ontology data into nodes and relationships. Furthermore, during the transformation, the encoding management module of GOMS computes GOMS Encoding numbers of each class node. We propose an encoding method to help a graph DBMS process queries with complex path conditions more efficiently. After that, to support the reasoning capabilities of ontology data, the data augmentation module of GOMS augments additional relationships. Finally, we load the transformed data into the graph DBMS. Based on the stored ontology data, GOMS supports two categories of queries as follows: Cypher queries with reasoning: These are any cypher queries that we can perform on ontology data. Because ontology data are stored in a graph form, we can perform various queries to explore the data using a cypher query language. In GOMS, the reasoning process is performed by precomputation and query processing. Therefore, we need to translate cypher queries written by a user. Node matching queries: Because finding key nodes is one of the basic steps to use knowledge, we provide various query templates to find main or common nodes. Furthermore, we provide efficient query processing algorithms for finding common nodes. The query translation module of GOMS translates cypher queries with reasoning to obtain results with reasoning, and the query execution module of GOMS executes the translated cypher query on the graph DBMS. In addition, for node matching queries, the query optimization module of GOMS optimizes queries so that they can be processed quickly. FIGURE 1Open in figure viewerPowerPoint Architecture of GOMS 4 STORAGE AND BASIC QUERY PROCESSING METHODS FOR LARGE-SCALE ONTOLOGY MANAGEMENT Ontology data can be easily represented by graph data. However, ontology data have more semantics than graph data. For example, see the example of Figure A1. Gray nodes are instances, and white nodes are class nodes. In Figure A1, usaSportCar_instance1 is the USASportsCar type. Furthermore, usaSportCar_instance1 is the SportsCar type, and the Car type because USASportsCar is the subclass of SportsCar and Car. However, we cannot directly infer these facts using a simple graph representation. Therefore, we provide a system to manage large-scale ontology data using a graph DBMS. There are many reasoning capabilities, but we support class subsumption and inverseOf/symmetric/transitive properties, which are one of the most important reasoning capabilities. In the current version, we do not support property subsumption. We focus on how to manage large-scale ontology data on a graph DBMS and support user-friendly query templates. First, we describe a method for storing ontology data into a graph DBMS. We use Neo4j [40] as a graph DBMS, which is one of the most commonly used graph DBMSs, and cypher query 22 The basic grammar of a cypher query is MATCH patterns WHERE conditions RETURN outputs. In patterns, a node is denoted by (V:N) and a relationship by [V:N], where V is a variable and N is a node or relationship type. V and N can be omitted. Furthermore, ()-[]-() is an undirected edge and ()-[]->() is a directed edge. as a graph query language. Ontology data typically consist of class hierarchies (taxonomies or schemas) and instances. Both class hierarchies and instances are completely represented by the graph representation, as shown in Figure A1. Each node is stored in the form of the node type of a graph DBMS with the node name, and each edge is stored in the form of the Relationship type with the property name. There are two types of ontology nodes, class nodes and instance nodes. We store class nodes with the label CLASS and instance nodes with the label INSTANCE. Class hierarchies describe the structures of classes in a tree form or a DAG form, and they have transitive properties. USASportsCar is the subClass of SportsCar as well as Car even though USASportsCar does not have a direct subclass relationship with Car. This is called class subsumption. However, a simple graph representation cannot provide class subsumption. Fortunately, for class subsumption, we can use the * operation in cypher queries. (a:TYPE1)-[:Property*]-(b:TYPE2) in the cypher query means node a with TYPE1 is connected to node b with TYPE2 through one or multiple hops with the Property relationship. Therefore, in the previous example, GOMS runs the query <match (:CLASS{name:"USASportsCar"})-[:subClassOf*]->(n:CLASS) return n> instead of <match (:CLASS{name:"USASportsCar"})-[:subClassOf]->(n:CLASS) return n>. In addition, to support transitive, inverseOf, and symmetric properties, GOMS manages them as follows: Transitive property: In the same way as class subsumption, GOMS can use the * (star) operation in a cypher query. If P is a transitive property, GOMS uses [:P*] instead of [:P] to represent the transitive path. For efficient reasoning, GOMS can precompute all transitive closures. However, because it needs a lot of space and graph DBMSs support efficient path retrieval, GOMS does not precompute transitive closures. We will experimentally compare the precomputation approach with the non-precomputation approach in Section 6. InverseOf property: If P1 is an inverseOf property of P2, P1(a,b) infers P2(b,a). While the transitive property is evaluated during query processing in GOMS, the inverseOf is precomputed. This is because the precomputation of the inverseOf property leads to only one additional edge for each instance with the inverseOf property, and it is difficult to express the inverseOf relationship with a simple cypher query form. If P1 is the inverseOf property of P2 and there exists (a)-[:P1]->(b), GOMS adds the relationship P2 such that (b)-[:P2]->(a). However, if there already exists (b)-[:P2]->(a), GOMS does not add it. Symmetric Property: If P is a symmetric property, P(a,b) infers P(b,a). Because the precomputation of the symmetric property leads to only one additional edge for each instance with the symmetric property, GOMS precomputes the function of the symmetric property. If P is a symmetric property and there exists (a)-[:P]->(b), GOMS adds the relationship P such that (b)-[:P]->(a). However, if there already exists (b)-[:P]->(a), GOMS does not add it. By constructing ontology data on the graph DBMS, we can also use multiple cypher query functions such as node/path pattern matching, conditions, sorting, and aggregation. However, to support the reasoning, we need to translate cypher queries. Because inverseOf and symmetric properties are precomputed, we do not concern them when we run a cypher query. However, when we run a cypher query, which includes transitive properties, we have to translate the original query. If some property is transitive, we change the pattern [:P] to [:P*]. We do not support transitivity in any type of cypher query. For example, we do not consider the transitivity in (a)- -(b) of the cypher query pattern. In many cases, when constructing cypher queries for ontology reasoning and retrieval, we have to know the complete names of terminologies (that is, URIs), which users might be unfamiliar with. To help users find key terminologies effectively, we propose user-friendly query templates to find main or common nodes (Node Matching Queries). We consider two types of user-friendly query templates, main node matching and common node matching. GOMS supports both main node matching and common node matching. Main node matching is to find key concepts (that is, class nodes in class hierarchies) or instances by a given string keyword from a user. In general, several concepts or instances contain a given string keyword. For example, suppose that a user might want to find some node (concept or instance) related to fashion. However, there exist hundreds of nodes whose name contains fashion in the YAGO ontology data [4]. In that case, it is difficult for the user to find or choose the node among those nodes. Therefore, we need to provide query templates to find main nodes according to some measures. For main node matching, we provide four query templates, as shown in the upper part of Figure 2. FIGURE 2Open in figure viewerPowerPoint Query templates to main node matching and common node matching In the first and second query templates, we consider a node with a high degree as a key concept or a key instance. We use the aggregation operation count() to count neighbor nodes. Note that (a) - - (b) means a is a neighbor node in the cypher query. For each node containing a string keyword (where toLower(n1.name) contains "input_keyword"), the first and second query templates compute its degree and order each node according to the degree. The first query template returns class nodes with their degree in descending order, whereas the second query template returns instance nodes with their degree in descending order. For example, if we use the keyword fashion, we can obtain the following results in the YAGO data. We show only the top three results. QueryTemplate1: wikicat_People_in_fashion (degree: 147), wikicat_Fashion_designers (degree: 70), wikicat_Fashion_events (degre:34) QueryTemplate2: Fashion_Institute_of_Technology (degree: 27), Neiman_Marcus_Fashion_Award (degree 15), Dog_Fashion_Disco (degree: 14) We can find main nodes according to the number of subconcepts (or subclasses) using QueryTemplate3. To find subconcepts, we specify the pattern (n1:CLASS)<-[:rdfs_subClassOf*]-(n2:CLASS). 33 For convenience, as a property type name, we use rdfs_subClassOf and rdf_type instead of rdfs:subClassOf and rdf:type, respectively, because ":" is a reserved wild character. In addition, we can consider a node with a high number of instances as one of the main concepts. It can be processed using QueryTemplate4. The pattern (n1:CLASS)<-[:rdfs_subClassOf*0..] -(:CLASS)<-[:TYPE]-(n2:INSTANCE) is specified in QueryTemplate4. QueryTemplate4 evaluates the number of instances by considering class hierarchies. Note that the reason why we use rdfs_subClassOf*0.. is that n1 can be directly connected to an instance without the rdfs_subclassOf relationship. The results of QueryTempate3 and QueryTemplate4 with the keyword fashion in the YAGO ontology are as follows: QueryTemplate3: wikicat_People_in_fashion (number: 791), wikicat_Fashion_designers (number: 118), wikicat_Fashion_events (number: 35) QueryTemplate4: wikicat_People_in_fashion (number: 15880), wikicat_Fashion_designers (number:3015), wikicat_American_fashion_designers (number: 648) We can notice that wikicat_People_in_fashion, wikicat_Fashion_designers are common in multiple queries. Therefore, we can begin searching ontology data in detail with those nodes. After finding several main concepts, users might want to find more detailed or generic concepts. Common node matching is to find common descendant/ancestor nodes given multiple concepts. QueryTemplate5 and QueryTemplate6 provide templates to find more detailed and generic concepts from multiple terminologies, respectively. QueryTemplate5 is to find common descendant nodes in the class hierarchy given several terminologies, term1, term2, …, termk. Note that a class hierarchy in a large-scale ontology such as YAGO is a DAG. In addition, QueryTemplate6 is to find common ancestor nodes from many given concepts. However, queryTemplate5 and queryTemplate6 are not performed quickly on Neo4j because they seem to have complicated patterns, and the query optimizer of Neo4j did not work well on them (see Experiments in Section 6). Therefore, in the next section, we will propose query processing algorithms to process these queries efficiently. 5 ADVANCED QUERY PROCESSING USING HASH JOIN AND ENCODING A graph DBMS can process multiple patterns efficiently. However, according to our experiments, queries with multiple joins and path conditions, such as common node matching, were not performed efficiently. To solve this problem, we propose query processing algorithms using a hash join method and an encoding method. Using these algorithms, we can process QueryTemplate5 and QueryTemplate6 efficiently. Before explaining our encoding method, we introduce the region numbering [41, 42], which has been widely used in the XML research area because our encoding method is based on the region numbering. In Figure 3, we can assign two numbers by traversing the tree in depth-first order. Note that when we use region numbering or our encoding method, we change the edge direction to the opposite. After that, we can easily identify if two nodes have an ancestor/descendant relationship, including a parent–child relationship, using those numbers. See Theorem 1 in Appendix A. For example, the Car node with <3, 10> is the ancestor node of the GermanSportsCar node with <7, 8> because [7, 8] ⊂ [3, 10]. However, the Car node with <3, 10> is not the ancestor node of the Person node with <1, 2> because [1, 2] ⊄ [3, 10]. Although we can easily check if two nodes are in an ancestor–descendant relationship using the region numbering technique, it can be applied to only tree structures. It cannot be applied to graph structures. Class hierarchies in large-scale ontology data show DAGs. Therefore, we cannot apply the region numbering to ontology data. Instead of complete ancestor–descendant relationship checking, we use an encoding method as a node filtering tool to help a graph DBMS find patterns more efficiently. We propose an encoding algorithm called GOMS encoding in Figure 4. FIGURE 3Open in figure viewerPowerPoint Region numbering example FIGURE 4Open in figure viewerPowerPoint Graph database-based ontology management system (GOMS) encoding algorithm We assume that the input of the GOMS encoding algorithm is a DAG. To assign encoding numbers to nodes, we initialize the nodes of the given input DAG and call GOMS_Encoding with the root node (see main function in Figure 4). However, some DAGs might not have a root node. In that case, we introduce a virtual root node by connecting top-level nodes with the virtual root node, as shown in Figure 5. GOMS_Encoding(Node node) function is a recursive function for traversing a DAG in depth-first order. When GOMS_Encodi