Abstract
An ontology is a model language that supports the functions to integrate conceptually distributed domain knowledge and infer relationships among the concepts. Ontologies are developed based on the target domain knowledge. As a result, methodologies to automatically generate an ontology from metadata that characterize the domain knowledge are becoming important. However, existing methodologies to automatically generate an ontology using metadata are required to generate the domain metadata in a predetermined template, and it is difficult to manage data that are increased on the ontology itself when the domain OWL (Ontology Web Language) individuals are continuously increased. The database schema has a feature of domain knowledge and provides structural functions to efficiently process the knowledge-based data. In this paper, we propose a methodology to automatically generate ontologies and manage the OWL individual through an interaction of the database and the ontology. We describe the automatic ontology generation process with example schema and demonstrate the effectiveness of the automatically generated ontology by comparing it with existing ontologies using the ontology quality score.
1. Introduction
An ontology is a model language that can build models, which support the conceptual integration of the distributed domain data and the inference of relationships among the concepts as a result of activities such as concept analysis and domain modeling using the standard methodology [1]. In particular, the importance of ontology is recognized in areas such as knowledge engineering, context awareness, knowledge integration, and knowledge management and modeling.
When an existing ontology cannot be reused, it needs to be newly developed. The process of developing an ontology involves creating attributes and constraints, creating a model, and applying it to domain data [2]. This process is like designing the requirements of a software architecture. As with software development, ontology development needs to discuss domain concepts, relationships, and constraints with domain experts [3–6].
Since this process consumes a lot of manpower, methods to automatically define an ontology model by defining a domain in the form of the metadata that can characterize the domain and apply rules to the metadata are currently studied. Yahia et al.’s work automatically generates ontologies based on XML data sources [7]. The following studies, including Dey et al., conceptually classify fuzzy data and describe how to generate an ontology and the rules to generate an ontology [8–10]. The Clonto Framework automatically generates an ontology through a suffix tree clustering algorithm in a document that describes the domain information [11].
Methodologies to automatically generate an ontology through metadata must preprocess the metadata for generating an ontology through a domain into a template for applying an ontology-generating rule [12]. The generated ontology model does not focus on how to manage when many individuals occur. Individual inputs into the generated ontology model can be stored in a table in one of the databases in a triple form that consists of an object and a subject. Using this approach, it is possible to provide efficient management and query functions for individuals of the corresponding schema [13, 14]. Individual is the basic component of an ontology. The role of individuals in an ontology is to classify objects according to their class, which is the concept of a domain [15]. Individuals in OWL correspond to constants in first-order logic and instances in the Resource Description Framework.
In this paper, we propose a methodology to automatically generate an ontology model based on the database metadata and convert it into a database tuple when many individuals occur in the generated ontology. This methodology reads an OWL-DL-level ontology based on the schema information, which is the metadata of the relational database, and converts the individual of the ontology into a relational database.
A relational database is one of the common methods to structurally store data in a domain [16]. As a result, the schema of the database storing the domain data has characteristics of the corresponding domain. In addition, a database table is a conceptual model that can contain similar data in the domain. As a result, the methodology to generate an ontology from a built database has the advantage that the generated ontology can better express the characteristics of each domain region for a wider range of domain regions.
The ontology quality metric was applied to determine whether the automatically generated ontology through the database schema was sufficient for actual domain applications. A good ontology is impossible to evaluate because an ontology has different characteristics depending on the applied domain, but it is possible to determine how suitably the ontology fits into the domain [17]. In this paper, we define a metric of how well an ontology can reflect the domain knowledge, compare the automatically generated ontology according to our process to the other ontologies, and show the effectiveness of the automatic ontology-generating method using the database schema.
The remainder of the paper is organized as follows: Section 2 introduces existing papers on the data construction for automatic ontology generation and individual management. Section 3 describes the automatic ontology generation process. Section 4 describes the process of managing an ontology individual using a database management system. Section 5 shows the process and results of automatic ontology generation using the sample database schema. In Section 6, the ontology quality score is used to verify how the ontology expresses the domain by comparing it with other ontologies. The final section concludes with a discussion of future research.
2. Related Works
2.1. Automatic Ontology Generation Using Metadata
Frameworks such as TANGO [18] and TARTAR [19] automatically generate an ontology from the metadata that contain the structure and characteristics of the domain data. In the framework, the commonly found components in the data are organized in a tabular form, and the table is analyzed to generate the components of the ontology model. In the TANGO application, a table is analyzed, a semiontology is generated based on each table, and a semiontology is connected to generate a kernel ontology to finally generate an ontology. TANGO supports functions such as multiple-source query processing, semantic web creation, and superimposed information generation to use application. TARTAR automatically transforms tabular data such as HTML, PDF, and EXCEL into a formal (structural and semantic) template and provides it to users through an internal engine. At this time, a table attribute ontology of the OWL format linked to each table data is automatically generated.
Long [20] has realized an agent that interprets table data by recognizing tabular data and each table attribute and generating an ontology of the RDF format to realize an agent-based approach methodology for table recognition and interpretation. The study explains how to extract these tables from text files, evaluation of table analysis tasks, and the Table Analysis Framework based on the RDF. Among them, the RDF-Based Blackboard Framework generates an RDF file through the annotation of different printed tables and analyzes the table through the generated RDF.
The following studies on automatic ontology generation based on the relational database define each component of the database and ontology as a notation and generate the ontology based on the database through the rule using the relation of each component [21, 22]. These researchers used the Jena Framework to read and analyze the metadata of a database in a program, which was written in the Java language, and applied the rule to create an ontology model. As a result, they used Jena to implement the ontology model and generated documentation and RDF graphs.
Alalwan et al. [23] explained the overall process and rules to automatically generate an OWL ontology from a database schema to merge the data from each database using ontologies in a distributed database environment. The rules applied to the automatic creation of ontologies in the paper are based on the rules of this study; they are integrated and generalize the conditions of the rules. In a study, the rule for class fragmentation related to a layering of the class generated by referring to a database table is defined in the following formula:where defines class and when the table satisfies the class condition, and is a subclass of . The primary key of one table must be set to a foreign key of another table, and the attribute data type of both tables must be identical. denotes all tuples that belong to one table, and Dom denotes all attribute data types of the table. After the class is created based on the information in the table, the study suggests applying the rule defined in the following formula when a DatatypeProperty is created in the attribute of the table:where defines a class to be a domain for all attributes that are not foreign keys in the table and to create a DatatypeProperty that sets the data type of each attribute as a range. In addition, the OWL is automatically generated through rules that define the properties and class relations of each property to integrate the distributed database.
2.2. Database-Based Large-Scale Ontology Data Management Methodologies
To manage ontology-based data, a methodology of storing the ontology model and individuals through an ontology-based database representation is suggested. OntoDB will refine the classes into triples, represent the existing ontologies in the form of individuals of the triples, and store them in the database to locate the entire model and data of the ontology in the database. OntoDB maps the metaschema of the ontology and the metadata of the database. This is a reverse process of generating an ontology through the metadata, which can guarantee high query performance based on the OBDB [24–26].
Shah and Rabhi [27] created an ontology workflow for intelligent big data analytics. Automatic service composition is used to automate the process and design the ontology and rules to infer the workflow of the data analysis process according to the attributes of the data set and the user requirements. In this case, big data are organized, and a large amount of data are clustered to the ontology model to apply it to the workflow based on the ontology model.
2.3. Metric-Based Ontology Quality Analysis and Scoring
The ontology quality in a thesis is evaluated by comparing the evaluation metrics of two categories and compared with the score of the ontology that covers the developed specific domain. The first category is about how well the generated ontology model can represent the knowledge of the domain. The second category is about how well the ontology model extracts data from the target knowledge base (KB) and applies it to the individual.
The notations and ontology quality metrics of the ontology model in the ontology quality evaluation are based on OntoQA [17], OntoMetric [28], and OntoClean [29]. The summation process and scoring were modified to suit the method of the paper based on the ontology evaluation and ranking research using OQuaRE [30] and Tartir and Arpinar [31]. We redefine the ontology model as a set of five components O: {C, P, SC, R, I} to use metrics for the ontology quality generated by automatic ontology generation using the schema. Each component constructs an ontology model with C (classes), P (properties), SC (subclasses), R (all relations between classes and ), and I (individual).
Two metrics of OntoQA were selected to score the ontology model categories: relationship richness indicates the number of relationships in the ontology and attribute richness defines the average number of attributes in the entire class and indicates the quantity of knowledge that the schema represents. The following formula defines the relationship richness as an ontology configuration notation:
As a result of the formula, a percentage is calculated that shows how much relation each class has with other classes, excluding subclass relations in the entire ontology. When the calculated value approaches zero, the ontology becomes a vertical ontology with small relationships among classes, and a closer value to 1 corresponds to a more relevant ontology. The following formula defines the attribute richness:
As a result of the formula, the average number of attributes per class is calculated. A higher value better corresponds to the ontology model that expresses the attribute of domain knowledge. Two metrics of OntoQA were selected to score the knowledge base category. The class richness is related to the degree to which individuals are distributed in a class. The average population compares the number of classes with the number of individuals and evaluates whether there are sufficiently many individuals for the class. The following formula defines the class richness:
The result of the formula is the percentage of classes that an individual has in the entire class. When the calculated value approaches zero, the corresponding ontology can be considered an ontology that cannot extract data from the knowledge base. The following formula defines the average population:
As a result of the formula, the average number of individuals per class is calculated. If the average number of individuals per class is not sufficient, the ontology model can be considered to have failed to extract all knowledge of the domain knowledge. OntoQA also analyzes the characteristics and quality of ontology through various metrics. Based on the analysis results, it shows how the ontology can represent the domain knowledge and how one can use the ontology accordingly.
3. Automatic Ontology Generation from Relational Database Schema
This section describes how to automatically generate an OWL ontology by importing a relational database schema. In detail, we describe the entire process of automatic creation of OWL ontology, required components of schema for the automatic generation, and applied rules to the ontology generation process using elements. The following process is performed to automatically generate the OWL ontology: (i) read and analyze the schema information of the database and convert it into the base information for the ontology generation. (ii) Create a class of ontologies based on the table information of the database. (iii) Based on the attribute information of the table, DatatypeProperty of the ontology class and ObjectProperty, which represents the relation among the classes, are created. Finally, the tuple in the database and the individual data of the OWL ontology are mapped using the generated ontology model. Figure 1 shows the automatic creation of an ontology using a database schema.
There are two reasons for mapping the tuple and OWL individual in the database. First, the mapping enables the ontology to use the tuple information for the actual integration and reasoning functions. The tuple data as owl:Namedindividual of the class created based on the table can be used to construct rules through the description logic and inference function of the ontology. Second, the mapping manages the newly created individual in the ontology in the database management system. In this case, the ontology is replaced by the tuple in the table by referring to the referenced table information when the ontology is automatically generated. This replacement enables one to use the existing relational database as an ontology and an ontology-based database instead of creating and using an ontology-based database. The methodology of converting a tuple into an individual is included in the automatic ontology generation process and described in this section. The opposite is explained in detail in Section 4. This process automatically generates an ontology based on schema information by entering schema data from the database. The OWL-DL XML file is generated as a result of the process. This XML file contains information about the ontology model and the syntax for the individual.
Section 3.1 describes the notations of the relational database and basic configuration methodology that must be established to convert the database to an ontology. The configuration information of the database schema depends on the domain knowledge where the database is built and the intent of the designer who builds the database. As a result, we set the minimum database schema configuration constraints that can automatically generate an ontology using the database schema according to the process of the thesis. The notations in the database represent the components of the database and schema information that is read from the database in the actual automatic ontology generation application. Section 3.2 describes the rules applied when classes are created from the database tables. Section 3.3 explains the rules applied when we generate ontology properties from the attributes in a table. Finally, Section 3.4 explains the conversion of the database tuple into an individual in the generated OWL ontology model. The notations and some rules in this paper are adapted to the stepwise generation of the OWL ontology based on our previous studies [32] and the ontology database generation studies [23] for database integration.
3.1. Notations and Basic Constraints of the Database
To define the rules in the ontology automatic generation process, we defined each database component with the following notations.
is represented by the table name x, which is a set of attributes in the database:
In other words, table x, which is a set of attributes, can be expressed by the following formula:
PK() is represented by the primary key attribute in table .
FK() is represented by the foreign key in table and reference in table .
The four notations from the beginning are used to define the rules that create the basic ontology components. is a more detailed representation of each component and used in the table to evaluate the rule to determine the details in the ontology component.
The database schema that can be applied to automatically generate the OWL ontology using the method in the paper must satisfy at least the following condition to consistently apply the automatic generation process by constraining the schema design method: the schema constraint in the automatic ontology generation process requires that the schema should be satisfied at least to automatically generate the ontology. The constraints are as follows:(i)The subtables that inherit the characteristics of the parent with one-to-many relationships share the primary key with the parent.(ii)A fragmented table with a one-to-one relationship has the primary key of the subtable of the parent table as a foreign key.(iii)The schema of the database must satisfy the third normal form.
The first constraint classifies the general relationship between two tables of whether each table can be merged into one class during the ontology class creation. The second constraint determines the basic hierarchical structure of the ontology classes. The final constraint maintains the consistency of the relationship extraction among the tables. The database for the automatic ontology creation must be a relational database, and the database schema is represented by SQL-DDL. The ontology that is generated as an object is OWL-DL level and expressed in the XML file with a functional syntax.
3.2. Rules to Generate Ontology Classes from Database Tables
The first step of the automatic ontology generation is to create an ontology class based on the table information in the database. The information in the table is an annotation that indicates the name of the table, the dependency of the table with the foreign key and the primary key, and the purpose and characteristics of the table. An ontology class is generated from table that does not apply to the rule to be basically described. However, if the target table corresponds to the following two rules that determine that the conceptual separation of domain knowledge occurs at the schema design level, the merging or layering of the class is performed in the process of creating the class based on the table. The first rule is involved in the merger of classes. The following formula defines the class-merging rule:
If the primary key of table is a foreign key of and the primary key of is a functional dependency of , that is, if the primary key of determines the entire , then can be considered one table of . Because the primary key of is a functional subordinate to the primary key of , it implies that generally determines its content in because all attributes of belong to . In this case, has a one-to-one relationship with .
The class hierarchy rule is involved in establishing a hierarchical structure between two classes. If two tables share the same key, one table becomes a lower-level table in the other table. In this case, the lower-layer table includes the attributes of the upper table, but the attributes of the upper table do not determine the attributes of the lower-layer table. The determination of a hierarchy in both tables depends on which key is referenced as a foreign key. The table that references a foreign key becomes a lower-level table. The subclasses created by applying this rule are the upper class and owl:subClassof relation. The following formula defines the class hierarchy rule:
The table evaluation rule determines the table to which the transformed tuple belongs in the mapping procedure of the tuple and individual. When two tables are created as one table that satisfies the merging rule, the annotation of the class is the sum of the comments in the two tables. At the end of this step, the generated classes are inserted into the OWL ontology model based on the information of the tables. The OWL model at this stage includes classes with a basic hierarchy, and the property information is generated for these classes in the next step.
3.3. Rules to Generate Ontology Properties from the Database Attributes
In this step, ontology properties are created based on the attribute information of each table. OWL properties fall into two categories: DatatypeProperty, which is an attribute for the actual data that enter the individual, and ObjectProperty, which contains information about the constraints in the OWL and the relationships among the classes. owl:DatatypeProperty is created based on the attribute where the data value is stored in the table. Here, owl:DatatypeProperty has xsd:datatype as a range, where the class to which the attribute belongs is converted as a domain.
When a class is created based on two tables that do not correspond to the merging or layering rules in the previous step, the two generated classes will have an owl:ObjectProperty relation. The name owl:ObjectProperty is created with the “has a” prefix attached to the name of the foreign key attribute. The resulting owl:inverseProperty is automatically determined by the “is” prefix. The following formula defines an ObjectProperty generation rule based on a foreign key:
When the above rule is applied to create an ObjectProperty between two classes, the restriction on the ontology is determined according to the relationship cardinality of the two tables. The restriction is represented by the cardinality of how many classes a class can apply to an ObjectProperty of that type. Rule (12) defines the ontology restriction according to the table relationship:
The attribute evaluation rule is involved in determining the owl:functionalProperty restriction when the conditions of the attributes of the table are not null and unique, or autoincrease. Table 1 lists the conditions that an attribute can have and the corresponding property constraints.
At the end of this step, an OWL ontology model is created, which contains the classes and properties of the class. Each property of a class contains a DatatypeProperty that represents the attributes of the table and an ObjectProperty that represents the relationship of the foreign key among the tables.
3.4. Mapping Procedure for the OWL Individual and Tuples
In this step, the tuple of each table stored in the database is mapped to the ontology individual based on the generated OWL ontology model. The mapping matches each tuple to the individual and asserts the corresponding Namedindividual to the table to which the tuple belongs. The name of the individual that is mapped to each tuple is the index attribute value of the corresponding table. It is the attribute value of the corresponding tuple of properties to the generated individual. Figure 2 shows the mapping process of database tuples and individuals to the automatically generated ontology model.
An attribute value of an ObjectProperty other than a DatatypeProperty becomes an ObjectProperty value that is related to an individual of another class in an individual. In this procedure, we refer to the tuple of both tables. The mapping process is not performed for all tuples, but the user can select a tuple of the desired category and map to an individual. Thus, it is possible to select the data category and determine the relevance of each data and the conceptual meaning of the data set through the reasoning function in the ontology model of the data.
4. Database Schema-Based Large-Scale Ontology Individual Management
This section describes how to convert an individual into a mapped tuple and store it in a database management system to efficiently manage a large ontology individual in the OWL. The last step in the automatic creation of an ontology in Section 3 is to map the individuals in the generated ontology model and the tuples stored in the database and assert each individual into classes based on the table. The tuple transformation of the individual proceeds with the inverse transformation of the described process.
When large-scale ontology individuals continue to grow, the individuals asserted in the class in the OWL model are converted into tuples and stored in the database. In this process, an automatic ontology generation program parses each individual and analyzes the parsed individual using the mapping information in the program. After the individual data are processed, the program converts them into a tuple, inserts the corresponding tuple into the table, and saves it. Figure 3 shows the process of storing an individual in a database.
By storing individuals in the database, one can manage large amounts of data while minimizing the increase in size of the ontology. The stored ontology individual can be reverted to the individual at any time using the mapping information. Using the methodology, we can minimize the cost of system implementation and ontology development by implementing the middleware for the interaction between the relational database and the ontology of a known type without building a database based on a specific ontology.
This process is the inverse process of tuple and individual mapping, which is the final step in the process of automatically generating the OWL ontology from the database schema. A manually created ontology allows the developer to choose the creation of an individual. However, because the process is done automatically, all tuples are converted into individuals. Thus, individuals can be stored in the form of tuples in the database to prevent too many individuals from accumulating in an ontology. As a result, this process extends the ontology management system in conjunction with the database.
One can use both SPARQL and SQL to query the database for interaction with the ontology model. If there are no required data for the query, the program searches for them in the remaining models and generates the necessary data for the query. To convert an individual into a tuple, the criterion to determine the tuple to convert to a table among the tables to which the merging rule is applied is the annotation information to which the table-evaluating rule in the merged class is applied.
5. Implementation
This section shows the process of automatically generating an OWL ontology using the actual database schema and the progress of the methodology through the intermediate output generated during the implementation. The target domain of the target database is for the smart home. Therefore, the schema of the target database contains tables and properties for storing data generated in the smart home. The entire schema consists of 85 tables, each of which contains one or more attributes. Each table has a hierarchical relationship according to the smart home unit through the foreign key. In this paper, we describe the automatic conversion process by selecting one of these tables as an example and outputting the result of the intermediate process of converting the corresponding table and attributes into classes.
An example table to illustrate the ontology autogeneration process contains the data for the smartwatch of the device in the smart home database. The smartwatch table is one of the tables that are managed by the device table and manages multiple smartwatch models and tables that contain detailed information on the smartwatch. The smartwatch table has attributes for managing the data of the entire smartwatch. The example in Figure 4 shows a smart_watch table and the tables managed by the smartwatch table of SQL statements.
The program reads the SQL-DDL, identifies the table and the attributes of the table, and converts the table into a class. Since the smart_watch_detail table satisfies the merging rule with the smart_watch table, a class is created. The name of the generated class will be the smart_watch class that governs the merger. The subattributes of the smart_watch_detail table are created as properties of the smart_watch class with the attributes of the smart_watch table, smart_watch_sportmodel, and smart_watch_classicmodel. Since the smart_watch_sportmodel table satisfies the layering rule, classes that are subclasses of the smart_watch class are created. The name of the created class is identical, and the attributes of each table are created as properties. In the annotation of the generated class, comments of the tables are inputted by the table evaluation rule. Figure 5 shows the OWL functional syntax of the generated classes based on table information.
The properties of the generated classes are generated based on the attribute information in the table. An attribute with a foreign key relationship is involved in the creation of an ObjectProperty by applying a key attribute relation rule. The attributes other than the foreign key are generated as a DatatypeProperty with actual data by applying the attribute evaluation rule and the attribute constraint rule. In the SQL-DDL, the watch_own attribute of the smart_watch table is related to the people_name of the people table. Key attribute relation is as follows: when an object property is created based on the watch_own attribute in the rule, the has_watch property is created by prefixing the attribute name. The inverse object property of this property, which is have_watch, is automatically generated. Figure 6 shows the OWL functional syntax of the properties generated based on the attribute information.
After the property creation is completed, the smart_watch class and properties are created based on the smart_watch table. Then, we map the tuples of the smart_home table to the individual. Mapping is based on the data in each tuple and refers to the data in the people table via the foreign key. Figure 7 shows the mapping results for the top three tuples.
The generated individuals are used as data of an artificial intelligence system such as the smart home environment analysis and correspondence method processing. When too many individuals are created, some unused individuals are inverted into tuples and stored in the database.
6. Validation
In this section, we evaluate the existing ontologies and automatically generated ontologies according to the ontology quality score. Using the score, we prove whether the automatically generated ontology can represent the domain knowledge. The result also demonstrates the effectiveness of instance management through the tuple-individual transformation by comparing the rate of increase in the database size with the OWL file when the ontology individual consistently occurs. The ontology quality scoring is defined according to the automatic ontology generation based on the notations and the OntoQA formula of the elements that constitute the ontology model in the related study. The category of the generated ontology model that represents the knowledge of the domain is evaluated by the sum of the relationship richness and the attribute richness of OntoQA. The score for the ontology model can be calculated with the following formula:
The calculated value shows the degree of the generated ontology with more relations and the index of the average attribute for each class. This value enables us to evaluate whether the automatically generated ontology reflects the relationships and characteristics of the actual domain knowledge. The database schema, which is the base knowledge of the ontology generation by evaluating the ontologies, can be determined to be suitable as the metadata for the ontology generation. Furthermore, the automatically generated ontology is about the efficiency in extracting the base knowledge, and the score for the knowledge base is summed with the class richness and average distribution across all classes of OntoQA. The score for the knowledge base extraction can be calculated using the following formula:
The calculated value indicates how well the generated ontology can extract the value to the knowledge base of interest. Thus, it is possible to confirm whether the automatically generated ontology can extract and use the domain knowledge data. We can verify whether the ontology model can reflect the tuple in all databases when we map the tuple and individual of a database, which is the basis of the automatic ontology generation. To evaluate the quality, we use similar ontologies of the smart home environment to the domain knowledge of the thesis. BOnSAI [33] is a smart building ontology for context awareness and conceptual integration for ambient intelligence. The ThinkHome [15] ontology is a comprehensive ontology of the smart home for the energy efficiency of the future smart home. Table 2 shows the ontology components of 3 ontologies for the smart home, including the automatically generated ontology.
By calculating the quality score of each ontology using formulas (13) and (14), we derived the result of and in the order of Table 2. The automatically generated ontology from the database schema information is lacking in ontology construction compared to the existing ontology, but it is sufficiently available compared with the basic ontology because the knowledge base extraction rate is high based on the database. Figure 8 shows the quality score of each ontology.
To prove the usefulness of the method of transforming individuals into tuples and storing them in a database when an individual is continuously generated in an automatically generated ontology, a new individual is continuously generated in the above automatic generation ontology. We compared the capacity growth rate when individuals were continuously stored in the ontology model and when individuals were converted into tuples and stored in the database. Figure 9 shows the storage capacity growth rate when the number of individuals increases.
When the individuals of a thousand units were continuously generated, the individual was stored in the OWL file and the tuple was stored in the database. As a result, the relational database slowly increased in the capacity growth rate compared to the ontology model when the number of individuals constantly increased. The database could effectively manage individuals in a tuple through data compression and management.
An ontology application based on the automatically generated ontology was created to confirm that the automatically generated ontology was usable and the context awareness using ontology was confirmed. Through the data generated by each smart device, the smart home application controls the power consumption of the IoT devices in the home based on the location measured in the human wearable equipment. Figure 10 shows the change in power consumption according to the user activity time.
When the user was at home, the power consumption of devices such as AI speakers and lamps was high and the power consumption of the devices activated by the users, such as smart flower pot and CCTV, increased. This is a result of the application that recognizes the GPS context awareness from the smartwatch and adjusts the power consumption of each device.
7. Conclusion and Future Work
In this paper, we describe a method to automatically generate OWL-DL using the database schema and store individuals in a database management system when many individuals occur in the generated ontology model in the database, where the ontology is generated. The ontology quality score also defines an indicator of how well the ontology represents the domain and compares it with other ontologies, which proves that the automatically generated ontology from the database schema can be used in the main application. In the proposed ontology model, the ontology can be efficiently managed by using the database schema and each individual can be integrated to reduce the overhead of the storage space.
The process of reading and analyzing the database schema information, automatically generating the ontology model using the analyzed information, and managing the instance through the database on which the ontology is created will be explained through an example. The ontology and the database can interact. In the ontology model, there is difficulty in expanding beyond the basic inclusion relation through the relation between the tables when we apply the automatic ontology generation method. In future studies, to apply the complex inference relation in the OWL, a constraint in the ontology model is considered based on the foreign key relationship between the database tables and the attribute information in a table and the optimization of the storage structure to store individuals to the database.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This research was supported by The Leading Human Resource Training Program of Regional Neo Industry through the National Research Foundation of Korea (NRF) funded by the Ministry of Science, ICT and Future Planning (no. NRF-2016H1D5A1909989). This research was also supported by the MISP (Ministry of Science, ICT and Future Planning), Korea, under the SW Master’s Course of Hiring Contract Program (H0116-16-1015) supervised by the IITP (Institute for Information & Communications Technology Promotion).