China *Corresponding author(

doi:10.21311/001.39.7.08 An Improved Ontology Learning Algorithm from Relational Schema Lu Yiqing 1, 2, * 1 Beijing Key Laboratory of Multimedia and Intelligent Software Technology College of Metropolitan Transportation Beijing University of Technology, Beijing, 100124, China 2 School of Information Management, Beijing Information Science and Technology University, Beijing, 100192, China *Corresponding author(e-mail: luyiqing@126.com) Abstract Currently, semantic integration became an attractive area in several disciplines, such as information integration, databases and ontologies. As many useful data are stored in the existing database management system of enterprises, the ontology learning method could be used to convert relational database to ontology. Therefore, one of the main challenges in the research of data integration and sharing based on semantics is to construct the mapping between relational databases and anthologies. Moreover, the use of manual work in the mapping of web contents to ontologies is impractical because it contains billions of pages and the most of these contents are generated from relational databases. In this paper, improved mapping rules are proposed in this paper to convert relational database schema to ontology. The corresponding algorithm is put forward and the affection of algorithm is analyzed. This approach is effective for building ontology and important for mining semantic information from huge web resources. Key words: Ontology, Knowledge Reasoning, Knowledge Sharing, Relational Schema. 1. INTRODUCTION Ontology was considered as a useful mechanism of describing knowledge. However, Manual ontology construction by domain expert is costly and inefficient. So ontology learning from existing knowledge sources (such as text, dictionary, database schema, etc.) becomes hot. Related research includes Ontology Generation, Ontology Enrichment, Ontology Mining and Ontology Extraction (Shvaiko and Euzenat, 2013). The information in existing management system of enterprises is very critical to management. These management systems can independently complete some work, like service management, decision making, and knowledge extracting for intelligent reasoning. Traditional information resources are mostly based on relational database, which stored most of enterprise data and contains numerous history data (Küpers, 2015; Lin etc., 2013). Database of information system is based on related concept module. There're some issues existing methods of converting from relational module to ontology (Hazber, 2016). Ontology construction based on relational data model refers to the ontology construction having in the relational schema of data source. For instance, Tzacheva present a method to embed ontology knowledge into a relational database through triggers and improve query time by forward computing inferences (Tzacheva, 2013). Kharlamov etc. show how Semantic Technologies implemented in their system optique to simplify complex diagnostics by providing an abstraction layer---ontology---that integrates heterogeneous data (Kharlamov etc., 2016). Saha etc. present ATHENA, an ontology-driven system for natural language querying of complex relational databases (Saha etc., 2016) There have been some researchers put forward their own solutions by learning the ontology from relational database. There mainly exist the following several means. The means that first define a kind of relational database ontology (OWL-RDBO), and then convert the metadata and structural constraint of each database into database ontology, which belonged to application ontology and made no proper consideration to the extraction of semantic information of domain concept and its hierarchical relation. 2) First translate relational data schema to an intermediate model, and then translate into ontology model from intermediate model. 3) Illustrating more semantic information to receive theoretically by making relational analysis to primary key, data and attribute, and completing the transition to logic through making use of certain of mapping rule. However, the realization of its judgment based on the inclusion and dependence relationship was difficult and it would not be beneficial to practical project application. 4) Connotative semantic information can be extracted through making relational analysis to primary key, data and attribute, as well as applying particular mapping rule, so the ontology can be obtained. The level of 63

detail in considering the relational database information, the mapping rule been taken, as well as the ontology specification language were different due to different applications that the ontology obtained through this method confronted. The follow problems would be resulted in if applied these methods directly in learning ontology based on relational database: only a rough, lightweight ontology can be obtained owning to the casual consideration of the corresponding relation between relational data schema information and ontology concept; the mapping rule be concluded still stayed on theoretical level being short of practical operability resulted from taking into account of the inclusion and dependence relationship between attributes as well as the relation between data tuples. The ontology being achieved was lack of generality and application prospect. In summary, the present research included the following characteristics and shortages: Only lightweight ontology can be generated by casually analyzing the corresponding relations between relational database schema and ontology, which led to the structure of the obtained ontology being very smooth. 2) Restrictiveness, symmetry, transitive properties, etc. can not be discovered. 3) Neglect the restraint of obtaining more semantics. 4) The existing relational data model did not take into consideration of the associated conceptual model of one to one. 5) The current studies generally held that the primary key of one table was also the foreign key for quoting another table in relational database schema, so it can be mapped as an axiom stating the relation between the two classes of subclass super-class. While, the two tables with reference relation in reality usually reflected the connection of one to n and m to n in conceptual model, and can not be converted to ontology. In this paper, the analysis of conversion from relational module to ontology will not only cover the relational module itself, but also consider concept module between relational module and real world. Based on such analysis, we could make an improved conversion algorithm and map relational schema to ontology. This paper is organized as follows. In section 2, the formalized definition of relational schema and ontology are given. In section 3, the mapping rules of ontology learning from relational schema are presented. The algorithm automatic conversion from relational schema to ontology is described in section 4. Finally, our work of this paper is summarized in the last section. 2. FORMALIZED DEFINITIONS OF RELATIONAL SCHEMA AND ONTOLOGY The key to obtain ontology concept and its relation from relational data schema was to set up the mapping rule from relational database schema to ontology. The formal definition of relational schema and ontology was shown as follows, as well as the conceptual model reflecting the practical significance of the data. Relational schema The main content of relational database schema consisted of relational data structure and integrity constraint declaration. The basic table structure gave definitions to the structure of relation table, attribute of column, as well as the data type and its length, etc.; integrity constraint defined the constraint of data imposed by semantics, including the global restriction on relation layer, the table constraint on tuple layer, as well as the column constraint on attribute layer, the above two part of information was stored in the data dictionary of database as tuple data (Yiqing etc., 2012). Definition 1 presented a formal definition of relational database schema based on the research issue of ontology. Definition 1(formal definition of relational database schema) S= (T, A, D, DOM, PK, FK, U, N). In which, T represented a finite set of the table. The table consisted of the set of Entity Table Name ET and that of Relationship Table Name RT, furthermore, ET and RT cannot cross (ET was with single primary key, RT possessed composite primary key). As for table T i, the set of all tuples on it can be showed as tupler(t i ); A referred to a finite set of column name, a j (T i ) was the column name of column j in T i ; D stood for the name set of a Data Type, and each of the data type name was the type-name predefined by DBMS, such as integer; DOM represented the mapping of the specific column a j (T i ) to its data range(data type), namely, a nonblank column set A(T i ) existed for each table name T i T, and each column a(t i ) A(T i ) had a relational predefined data type datatype(a(t i )) D as its data range; PK was primary key constraint: T had one and only one primary key pkey(t) solely determined each line of instance data in T, moreover, it can be pkey(t) A(T) (be called single primary key that just entity table can have and only have), or be pkey(t) A(T)(be called composite primary key that only association table can have and only have); FK presented foreign key constraint: T may have foreign key fkey(t,r) of 0~n (n l) that quoting R single primary key of other tables, which should satisfy: fkey(t,r) A(T), dom(fkey(t,r)) dom(pkey(r)) {null}, pkey(r) A(R), In which, dom (*) meant the range of * ; 64

U represented that whether a specific column to its value can take the mapping of unique constraint, and the taken value can be unique or un_unique; as to the column a i A(t i ), if the value of a i was unique, then unique(a i )=True, otherwise, unique(a i )=False; N stood that whether a specific column to its value can take the mapping of null value constraint; if the value of a i was not null, then notnull(a i )=True, otherwise, notnull(a i )=False. 2) OWL ontology Most elements of OWL ontology were related with class, property, instance of class, as well as the relation between these instances, among which, the basic conception in domain was presented as various classes having different hierarchical relation; properties can help us predict the general facts about class member and the concrete facts about individual. Besides, it was divided into two kinds: data-type property and object property; data-type attribute showed the relation between instance of class and RDF character or XML Schema data type; object properties referred to the relation between the instances of the two classes. One instance of class was one specific member of the corresponding concept. Furthermore, a powerful mechanism was provided by property characteristic to strengthen the reasoning to one property in order to illustrate the property elaborately. And property restriction can make a further restriction to the range of property in a definite context, such as cardinality constraints, etc. Formally, an ontology indicated by OWL simply included an optional ontology identifier, a group of optional annotation, as well as a group of axiom. Annotation was use for recording information of the identity of the author of ontology, the input and quote of other ontology; the main content of ontology was provided by axiom including axiom, property axiom, as well as individual axiom (namely the instance). The paper did not consider the annotation contents without relation to relation model temporarily for the convenience of discussion. The formal definition of a simplified OWL ontology was shown as follows. Definition 2 (formal definition of ontology) O=(C, A C, DT, A R, I, X); In them, C was the set of a class identifier, and it included two predefined class identifiers of owl:thing and owl:nothing except that defined by users; A C was a set of data-type property identifier; DT was the set of data-type identifier (the identifiers of each data type was that of the predefined XML schema used in OWL ontology); A R was the set of an object property identifier; I was the set of an individual identifier; X was an axiom set; What needed to point out were: the complete syntax format of all identifiers was a URI reference, which was consisted of an absolute URI or prefix expressing namespace, and a fragment identifier (the paper omitted the part of namespace for easy). Each axiom can be realized by a number of constructors acted on identifier or description. Description can be class identifier directly or be constructed with identifier through anonymous class constructor restriction. 3. IMPROVED MAPPING RULES FROM RELATIONAL MODEL TO ONTOLOGY For existing various problems analyzed in section2, this paper put forward an improved mapping rules from relational model to ontology, which is described in the following. Compared to existing methods, the solution described in this paper have contains more domain knowledge and easy to implement. Table in relational database schema was mapped to equivalent class symbol in OWL ontology. For a table t T, it was mapped to OWL ontology symbol () t C, and the related class axiom is <owl:class rdf:id= () t. 2) Property ai of table s non-fk column was mapped to ontology datatype s property. For a property named a i, ai attr() t, ai fkey() t, it was mapped to datatype symbol in OWL ontology, ( a ) c i A 3) Data type of table s non-fk column was mapped to ontology datatype. The data type d i D in database schema was mapped to data type symbol ( di ) DT in OWL ontology. 4) Value range constraint of table s non-fk column was mapped to property axiom of data type in OWL ontology. The relationship of data types between database and OWL ontology was described in table 1. 5) Foreign key in database was mapped to property symbol in OWL ontology. In database, ai FK, where ai referring to t 2, ai was mapped to Object property symbol in OWL ontology. 6) The foreign key which has dependency relationship between tables was mapped to the related property axiom of object symbol in OWL ontology. 65

In database, ai FK, where ai referring to t 2, ai, the mapping was as below. ( a ( ) R i t A, Object Property ( ( a i ) domain( ) range( )). 7) Unique constraint, NULL constraint and primary key constraint in relational database were mapped to property constraint in OWL ontology. If a column aj () t in table has unique value, i.e. unique ( aj () t )=true, the mapping will be InverseFunctionalproperty. If a column aj () t in table can t be NULL value, i.e. not null ( aj () t )=true, the mapping will be restriction( aj () t ) min Cardinality(l)). If a column aj () t is the primary key of this table, i.e. a j ) pkey ), since primary key has two constraints, it can t be NULL and it should be unique. In a result, the mapping will be InverseFunctionalProperty and mincardinality=1. Table 1. Correspondence of data types between database and OWL ontology Data type in database Data type in OWL ontology decimal/dec xsd:decimal Number integer/int xsd:integer float xsd:float double precision xsd:double Char char xsd:string varchar xsd:string datetime xsd:datetime Data and time date xsd:date time xsd:time Boolean boolean xsd:boolean 8) Element group in relational database was mapped to instance symbol and it s axiom in OWL object. 9) Multiple tables which describe a same instance were mapped to a single ontology class. This rule reflects 1:n relationship between two ontology objects. 10) If a table has no other property except foreign key, it was mapped to two object property symbols and related inverse property axiom. This rule reflects m: n relationship between two ontology objects. 1 If a table has other property except foreign key, it was mapped to the equivalent class, and the foreign key and related constraint were mapped to object property and related property axiom. This rule also reflects m: n relationship between two ontology objects. However, the table will be generally converted to instance table, actually this conversion comply with rule 1-rule7. Based on above rules, most of relational tables can be converted to ontology. Related algorithm was described in section 4. As for special table with completed semantic, the process solution can be determined by domain expert. 4. SPECIFIC METHOD OF CONVERTING RELATIONAL DATABASE TO ONTOLOGY The database mode information can be obtained from data dictionary directly or from inverse engineering of Power Designer. The schema information saved in data dictionary reflect the final status of current database, and can be directly obtained by using middle layer API, like ODBC API and JDBC API, which can interface different RDBMS. This pick-up algorithm was illustrated elaborately as follows: First step: judge whether each of the table was entity-type table one by one. If the present table T was entity-type table, then create a OWL ontology class identifier and class axiom, in which, the identifier of OWL ontology class was the same as table name T name ; class axiom stated that there exist an OWL ontology class T name, such as <owl:class rdf:id= T name > Second step: examine the state of primary and foreign keys of all of the tables one by one. If the number of primary key was one, namely, it was entity-type table, then operation should be conducted; if the primary key was the composite primary key with the number of two, these two primary keys separately quoted the foreign keys of the other two entity tables of T k and T j, and there was no other properties except foreign key, then 2) operation should be executed; if the primary key was the composite primary key with the number of two, and had other properties except foreign key, then operation should be carried out. If it did not belong to the above 66

classic situation, then it belonged to composite semantic structure table, and it would need domain expert to confirm the specific processing scheme by interacting. Decide whether each of the column in table T i was foreign key one by one. a. If this column (with column name of A) was foreign key, and quoted T j, then establish an object properties identifier and property axiom, in which, object properties identifier was has_ present column name (such as has A), property axiom stated that the definition domain of this object properties was table T i corresponding OWL class, range was T j corresponding OWL class; furthermore, if this column was also primary key, then a class axiom should be established, which was used to describe that T i corresponding OWL class was the subclass of T j corresponding OWL class; b. If this column was non-foreign key, then establish a data type properties identifier and property axiom, in which, object properties identifier was has_present column name, property axiom indicated that the definition domain of this object properties was the corresponding OWL class of table T i, range was the data type that the present column corresponded; furthermore, if this column was primary key or was with constraint, then the corresponding constraint should be established in ontology; 2) If this table T i was relation-type table, which was obtained through the conversion of the relation m to n between two entities, then establish two object properties identifiers and two property axioms, moreover, the two object properties were reciprocal, in which, object properties identifiers were separately has_t iname and inv_has_t iname, the definition domain and range of the two property axioms were respectively class (T k ) and class (T j ). Property axiom showed that the definition domain of has_t iname was table T k corresponding OWL class, range was table T j corresponding OWL class, the definition domain of inv_has_t iname was table T j corresponding OWL class, range was table T k corresponding OWL class, has_t iname and inv_has_t iname were reciprocal. Third step: estimate whether each of the entity table had foreign key one by one. If this entity table had no foreign key, then map each tuple set as an instance of the corresponding OWL ontology class of this table (namely an OWL ontology individual), and identify this table as converted; If this entity table had foreign key, then make a further judgment on whether the tuple set of the table quoted by foreign key was already mapped as OWL individual. If the quoted table was already mapped, then map each of the tuple set as an instance of the table corresponding ontology class, and identify this table as converted; If the quoted table was not mapped, then it needed to map the tuple set of the quoted table first, and followed by that of the table. Here, the process of mapping each of tuple set as an instance of the corresponding OWL ontology class of the table was just the generating process of an OWL ontology individual axiom, the concrete was: map the corresponding tuple set value of non-foreign key column of each tuple set as the value of the corresponding data type property of ontology individual, so as to describe the relationship between the two individuals. Among them, individual identifier was the OWL class name that this individual belonged to_ the corresponding tuple set value of primary key of the tuple set, if this table had m columns, then the individual axiom generated by each tuple set was m. 5. ALGORITHM EFFECT ANALYSES Here, the process of mapping each of tuple set as an instance of the corresponding OWL ontology class of the table was just the generating process of an OWL ontology individual axiom, the concrete was: map the corresponding tuple set value of non-foreign key column of each tuple set as the value of the corresponding data type property of ontology individual, so as to describe the relationship between the two individuals. Among them, individual identifier was the OWL class name that this individual belonged to_ the corresponding tuple set value of primary key of the tuple set, if this table has m columns, then the individual axiom generated by each tuple set was m. The time performance of this algorithm can make the following theoretical analysis. It can be held that the basic operation of this algorithm was the establishment of axiom owning to that the creation of all the identifiers can be directly conducted in axiom creation. Given that the scale of a relational database was N = NT+NA+Ni, in which, NT was the number of the table, NA was the total number of column, Ni was the number of all tuple set. Make an analysis of this algorithm: when under the extreme condition that the entity tables were filled with database, then the maximum time of establishing class axiom was NT at the first step; the second step was divided into entity-type table and relation-type table. As for entity-type table, the maximum creation time of part axiom was 4NA, and less than NT time of that of relation-type table; the individual axiom creation time of the third step was less than NT NA. Therefore, the total operation time of this algorithm under the worst condition was T=NT+4NA+NT+NA Ni < N2, so the time complexity of the algorithm was lower than O(N2). In this paper, an example of an enterprise sales management system database is studied, using the learning algorithm to get the OWL ontology from database. When evaluating the semantic coverage of the algorithm, using evaluation method proposed by Cimiano etc. (Cimiano etc., 2004). Define a concept of the semantic coverage for all of its parent class and subclass subset, that is: 67

SC( c, O, O ) : c C C c c c c i r e j r e i cr j j cr i The taxonomic overlap between two anthologies may record asto, the calculating formulas is: 1 SCc, O1, O2 SCc, O2, O1 TO( O1, O2) : max C cc 2 root SC c, O, O SC c, O, O 1 cc2 1 2 2 1 The ontology manually created by experts in the field is denoted as O e, the ontology obtained by the proposed algorithm in this paper is denoted as O m, the ontology obtained by Stojanovic etc. is denoted as O s, and the ontology obtained by Trinh etc. is denoted as O t. Calculating TO ( O, O ) =67.58%, TO ( O, O ) =62.15%, m e s e TO( Ot, O e) =59.63% (Stojanovic etc., 2002; Trinh etc., 2006). It shows that the algorithm in this paper is better than contrast algorithms in semantic coverage when generating ontology. It can be found that the contrast algorithms are not well considered the semantic information, such as the concept and the hierarchical relationship in the field, and can only get the lightweight ontology. 6. CONCLUSIONS The improved algorithm of ontology learning proposed in this paper can help enterprises to easily extract semantic information from an existing relational database. The next step of research can focus on the ontology knowledge synergy and knowledge service. Acknowledgements This work was supported by the National Natural Science Foundation of China under Grant (No. 61272513), Beijing outstanding talented person project for young people (Project No. 2014000020124G107) and Beijing Postdoctoral Research Foundation (Project No. 2015ZZ-39). REFERENCES Cimiano, P., Hotho, A., Stumme, G., & Tane, J. (2004) Conceptual knowledge processing with formal concept analysis and ontologies, International Conference on Formal Concept Analysis, pp.189-207. Hazber, M. A., Li, R., Gu, X., & Xu, G. (2016) Integration Mapping Rules: Transforming Relational Database to Semantic Web Ontology, Applied Mathematics & Information Sciences, 10(3), pp. 1-21. Kharlamov, E., Brandt, S., Jimenez-Ruiz, E., Kotidis, Y., Lamparter, S., Mailis, T.,... & Zheleznyakov, D. (2016) Ontology-Based Integration of Streaming and Static Relational Data with Optique, Proceedings of the 2016 International Conference on Management of Data, pp.2109-2112. Küpers, W. M. (2015) Phenomenology of the Embodied Organization. Palgrave Macmillan: UK. Lin, L., Xu, Z., & Ding, Y. (2013) OWL ontology extraction from relational databases via database reverse engineering, Journal of Software, 8(1, pp.2749-2760. Saha, D., Floratou, A., Sankaranarayanan, K., Minhas, U. F., Mittal, A. R., & Özcan, F. (2016) ATHENA: an ontology-driven system for natural language querying over relational data stores, Proceedings of the VLDB Endowment,9(12), pp.1209-1220. Shvaiko, P., & Euzenat, J. (2013) Ontology matching: state of the art and future challenges, IEEE Transactions on knowledge and data engineering, 25(, pp.158-176. Stojanovic, L., Stojanovic, N., & Volz, R. (2002) Migrating data-intensive web sites into the semantic web, Proceedings of the 2002 ACM symposium on Applied computing, pp. 1100-1107. Trinh, Q., Barker, K., & Alhajj, R. (2006) RDB2ONT: A Tool for Generating OWL Ontologies From Relational Database Systems, Proceedings of the Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services, pp. 170-178. Tzacheva, A. A., Toland, T. S., Poole, P. H., & Barnes, D. J. (2013) Ontology Database System and Triggers, Proceedings of International Symposium on Intelligent Data Analysis, pp.416-426. Yiqing, L., Lu, L., & Chen, L. (2012) Automatic learning ontology from relational schema, Robotics and Applications, 2012 IEEE Symposium on, pp.592-595. 68