Sage Journals: Discover world-class research

Abstract

The advancement of sensor technology has led to an explosive increase in sensors. It causes semantic heterogeneity problems, and much research has focused on sensor ontology building to solve the problems. However, there are still remaining several issues, and one of the most critical issues is about a method for progressive and dynamic concepts management and reuse of sensor ontology. This paper proposes an ontology generation system based on ISO/IEC 11179–MDR (metadata registry). The proposed system is referred to as the Canonical Sensor Ontology Builder (CaSOB) and can create ontologies by reusing the common concepts registered in a canonical sensor ontology concept registry, an MDR. This paper defines a mapping model and processes to create ontology with the concepts registered in an MDR. Our proposal provides many advantages such as high standardization, consistent concept usage, and easy semantic exchange. Therefore, CaSOB facilitates the high quality sensor ontology creation and reduces the costs of sensor ontology integration and system development.

1. Introduction

With the advancement of sensor technology, the number of sensors and application domains have been tremendously increased. It leads to a huge amount of sensor data as well as many kinds of sensor types in sensor network worlds. However, those increments cause various kinds of heterogeneity problems such as heterogeneity between data types, formats, and units of measure. Although we should be able to interpret and use all sensor information from any sensors in any sensor networks, those heterogeneity issues make it difficult to use seamlessly and transparently sensor data from all sensor networks.

Many studies have been done to resolve those issues and this section describes only the OGC (Open Geospatial Consortium) effort, one of the representative approaches. OGC established SWE (Sensor Web Enablement) to store, discover, access, and use all types of sensor information on the web [1]. Thus, the various sensor information defined according to SWE enables representing syntactic model consistently. Also, for representing semantics in the syntactic model, SSW (Semantic Sensor Web) appeared with extending the Semantic Web concept [2]. SSW represents the semantic sensor information such as space, time, and theme as a web ontology.

Many sensor ontologies have been developed to represent the sensor information in various domains [3–6]. The sensor ontologies are used as schemas of sensor data in a specific domain. Therefore, some sensor network systems which use the same sensor ontology in a specific domain guarantee syntactic model, semantic data interchange, and interoperability.

However, if we need to establish a new sensor network for a new domain or having different purposes, it is impossible to directly adopt the existing sensor ontology and we need to modify the existing ontology or add a new ontology. The modification and addition of ontologies cause another heterogeneity problem at conceptual (ontology schema) level [7, 8]. In other words, when we build a new ontology or reuse existing ontologies for adoption in other domains or for other purposes, we would customize the existing sensor ontologies [9]. It causes another semantic inconsistency between sensor ontologies.

This paper presents a method for sensor ontology management and reuse based ISO/IEC 11179, Metadata Registry (MDR) 3rd Edition, for resolving the semantic heterogeneity issue aforementioned. MDR is an international standard which has been revised for ontology management and published in 2013. A metadata registry based on MDR can manage metadata and the relations among them [10–15]. Ontologies also are registered and managed in the metadata registry. An MDR instance manages common concepts from the registered ontologies, and thus it ensures that ontologies are defined well and reusable by diverse systems. Reusing common concepts for building ontology enhances the ontology quality and semantic interoperability between sensor networks. MDR provides only the structure of registration and the administration of an ontology, but it does not support the ontology creation facility for reusing common concepts. Therefore, this paper proposes a new framework for ontology management and building based on MDR, and the proposed framework is named CaSOB (Canonical Sensor Ontology Builder). In addition, this paper considers a triple statement as an ontology. The reason is that various ontology languages such as OWL and RDF are formed by the triple and most of the ontology stores and reasoning engines are based on the triple.

This paper is organized as follows. In Section 2, we introduce previous researches into solutions to the semantic heterogeneity problem of sensor ontologies. In Section 3, we explain the CaSOB framework, a mapping model, and ontology building processes. Our implementation is described in Section 4, while Section 5 presents the evaluation. Finally, we conclude this paper and discuss future work in Section 6.

2. Semantic Heterogeneity Problem of Sensor Ontologies

Much research on ontologies has been directed at increasing interoperability and solving the semantic heterogeneity problem among various systems. An ontology matching technique was proposed for semantic interchange among peers in Open Network Systems [16]. Castano et al. [17] describe an algorithm that matched ontologies using a linguistic and contextual matching model for Open Network Systems. Pirro et al. [18] propose a similarity checking method based on WordNet for building semantic links in a peer-to-peer network. Bakillah and Mostafavi [19] also propose an ontology matching method based on lexical relations and mapping rules for improving the interoperability of distributed geospatial web services.

Ontology matching methods ensure that ontology concepts connect together and correspond semantically after ontologies are generated. These methods can match numerous ontologies automatically and semiautomatically, but they can experience problems in terms of high cost and inaccuracy. Therefore, research on ontology sharing and reuse is required, because these techniques can solve the semantic heterogeneity problem by creating ontologies based on common concepts. Matuszek et al. [20] propose a system for defining and reusing the common concepts, while Biebow and Szulman [21] proposed ontology building methods based on terminology from a linguistic perspective.

In the Semantic Sensor Web, various sensor ontologies have been developed such as CSIRO [22], MMI [23], and ISTAR [24]. Each of the ontologies is suitable for representing information of sensors and devices and exchanging the information between relevant services only in the same sensor network environment. However, the ontology cannot be available for the environment where we would develop a new sensor network system for other application domains or with other purposes.

Compton et al. [25] introduces various sensor ontologies from researches and projects in various domains and compares the corresponding domain, purposes, and features of each of the ontologies. Especially, Compton et al. evaluates the expressive power of the sensor ontologies from the perspectives of sensor device information, physical properties, observation quality, and domain concepts.

The CSIRO sensor ontology [26] is designed for a generic domain and is intended to be used in data integration, search, classification, and workflows. The CSIRO sensor ontology provides the high expressive power in sensor, physicalness, and observation perspectives. However, the CSIRO ontology does not provide concepts like sampled medium and time.

MMI (Marine Metadata Interoperability) [27] aims to increase interoperability for oceanographic devices, sensor, and sampler. The MMI device ontology has been developed for devices and sensors in ocean environment, but irrespective concepts such as sensor hierarchy, history, location, power supply, a field of view, unit of measure, and time have not been defined for oceanographic devices, sensors, and samplers.

The ISTAR ontology [28] has the purpose for task assignment and has been developed as part of a system to automatically select sensors for tasks based on their fitness for the task description. However, ISTAR has only concepts about sensors and physical features for the task assignment and does not consider concepts about observation and domain.

As a result, the previous approaches related to the sensor ontology do not provide a canonical sensor ontology concept management and building facility, and thus an additional heterogeneity issue continuously arises. It causes many other problems and is a barrier for seamless sensor semantics interpretation, progressive and systematic semantics management, common concept reusability, and so on. For addressing those problems, this paper proposes a new sensor ontology management and building framework based on MDR. The goal of the framework proposed in this paper is to enable the canonical management and reuse of the existing well-defined ontology.

3. The CaSOB Framework

Figure 1 shows the CaSOB framework. CaSOB contains four processes (Section 3.2) and it creates an ontology using a mapping model from MDR (Section 3.1). Various concepts are registered in a metadata registry for sharing and reusing as common concepts. Therefore the mapping model is defined using components in regions related by common concepts and data representations, including concepts region and data description region, from several areas of MDR. As a result, ontology is built as an ontology according to ontology schema model, so this paper considers only the schema level of ontology and it excludes the instance level.

Figure 1

The CaSOB framework.

3.1. Mapping Model

3.1.1. Preliminary Definition

MDR supports the registration and administration of common concepts. And it specifies a metamodel for the registration and administration of common concepts as an MDR specification. There are seven main regions. These regions are classified as regions that register and administer concepts, regions that name and define concepts, regions that represent the relations among concepts and components, and regions that specifically describe data. In this paper, we formally define the MDR model for two regions, that is, the concepts region and data description region.

Definition 1 (MDR concepts model).

The MDR concepts model is a six-tuple

\begin{matrix} MD R_{C} = (C S, C, R, R R, L E, l i n k), \end{matrix}

(1)

where one has the following.

(i)

$C S$ is a set of concept systems. A concept system represents a domain of concepts such as an application domain or knowledge domain.

(ii)

C is a set of concepts. A concept is a unit of knowledge created by a unique combination of characteristics. Some tuples of the MDR concepts model and the MDR data description model inherit C as a basic unit.

(iii)

R is a set of relations. A relation is a concept that represents the association among concepts.

(iv)

$R R$ is a set of relation roles. A relation role is a role of a concept associated with a specific relation.

(v)

$L E$ is a set of link ends. A link end is a pair of a concept and a relation role as one side of $l i n k$ , and LE is expressed by $〈 c and r r 〉$ where $c \in C and r r \in R R$ .

(vi)

$l i n k : R \to L E \times L E$ represents the linkage of two link ends, which are associated with a relation. In this paper, one focuses generation of a triple statement as ontology, so a binary relation is only considered.

The MDR concepts model defines all the concepts and relations administered in MDR. As an example, Figure 2 shows that the MDR concepts model contains $l i n k_{“ class-subsumption ”}$ (<“Sensor, “superclassOf”>, <“System”, “subclassOf”>), where ${“ Sensor”, “ System”} \in C$ , $“ class-subsumption ” \in R$ , and ${“ superclassOf”, “ subclassOf”} \in R R$ .

Figure 2

An example of the MDR concepts model.

Definition 2 (MDR data description model).

The MDR data description model is an eight-tuple

\begin{matrix} {MDR}_{D} = (C D, V M, V D, O C, P r, D E C, D E, D i m), \end{matrix}

(2)

where one has the following.

(i)

$C D$ is a set of conceptual domains. A conceptual domain is a domain wherein data element concepts could have a shared conceptual level. A conceptual domain is also used to represent a set of value meanings ( $V M$ ).

(ii)

$V M$ is a set of value meanings. A value meaning is a general meaning of actual values.

(iii)

$V D$ is a set of value domains. A value domain is a domain in the actual data level, which represents the actual values such as a data type.

(iv)

$O C$ is a set of object classes. An object class is a general concept that can capture many instances.

(v)

$P r$ is a set of properties. A property is an attribute of objects or concepts.

(vi)

$D E C$ is a set of data element concepts. A data element concept is a pair of a concept and a data element. And $D E C$ is expressed by $〈 o c, p r 〉$ where $o c \in O C and p r \in P r$ .

(vii)

$D E \subseteq D E C \times V D$ is a set of data elements. The data element is the basic unit of data for MDR.

(viii)

$D i m$ is a set of dimensionalities. A dimensionality is an aggregation of the units of measures, which is related to a conceptual domain, for example, length, height, or weight.

An ontology contains components that depend on the language and the description method. In this paper, we focused on building ontologies to improve interoperability among various applications or systems, so we concentrated on building ontology in schema level, rather than instance or individual level.

Definition 3 (ontology schema model).

The ontology schema model is a six-tuple

\begin{matrix} O n t o = (C l, P, R e l, D T, r e l a t i o n, p r o p), \end{matrix}

(3)

where one has the following.

(i)

$C l$ is a set of classes. A class is a concept that groups items sharing the same characteristics. Common characteristics are described logically.

(ii)

P is a set of properties. A property indicates the characteristics of a class. In the ontology schema model, a property is described by connecting a class to a data type.

(iii)

$R e l$ is a set of relations in an ontology domain. A relation in an ontology domain describes the characteristics existing among classes. A relation is described by connecting one class to another class.

(iv)

$D T$ is a set of data types. A data type is a type of value given to a class property.

(v)

$r e l a t i o n$ : $R e l \to C l \times C l$ is a triple statement expressed by $(c l_{1}, r e l, c l_{2})$ , where ${c l_{1}, c l_{2}}$ $\in$ $C l$ and $r e l \in R e l$ , such as an object property of OWL.

(vi)

$p r o p$ : $P \to C l \times D T$ is a triple statement expressed by $(c l, p, d t)$ , where $c l \in C l, p \in P$ , and $d t \in D T$ , such as a data type property of OWL.

3.1.2. CaSOB Mapping Model

The CaSOB mapping model defines the mapping rules based on the MDR models for the ontology schema model, as shown in the preliminary definition provided in Section 3.1.1. Data mapped by the CaSOB mapping model is used to build an ontology.

Definition 4 (mapping model).

The mapping model is a two-tuple

\begin{matrix} M M = (R u l e_{C}, R u l e_{D}), \end{matrix}

(4)

where one has the following.

(i)

$R u l e_{C}$ is a set of rules connecting the MDR concepts model with the ontology schema model. $R u l e_{C}$ has three rules as follows:

(a)

$C \to C l$ ,

(b)

$R R \to R e l$ ,

(c)

$l i n k \to r e l a t i o n$ ; that is, $l i n k_{r} (〈 c_{1}, r r_{1} 〉, 〈 c_{2}, r r_{2} 〉) \to r e l a t i o n_{r r 2} (c l_{1}, c l_{2})$ or $r e l a t i o n_{r r 1} (c l_{2}, c l_{1})$ , where $r \to r e l, c_{1} \to c l_{1}$ , and $c_{2} \to c l_{2}$ with $r \in R$ , ${c_{1}, c_{2}} \in C$ , ${r r_{1}, r r_{2}} \in R R, r e l \in R e l$ , and ${c l_{1}, c l_{2}} \in C l$ .

(ii)

$R u l e_{D}$ is a set of rules connecting the MDR data description model and the ontology schema model. $R u l e_{D}$ has eight rules as follows:

(a)

$C D \to C l$ ,

(b)

$V M \to C l$ ,

(c)

$D i m \to C l$ ,

(d)

$O C \to C l$ ,

(e)

$P r \to P$ ,

(f)

$V D \to D T$ ,

(g)

$D E C \to C l \times P$ ,

(h)

$D E \to p r o p$ ; that is, ( $〈 o c, c h 〉, v d) \to p r o p_{p} (c l, d t)$ , where $o c \to c l, p r \to p$ , and $v d \to d t$ with $d e \in D E$ , $o c \in O C$ , $p r \in P r, v d \in V D$ , $p \in P$ , $c l \in C l$ , and $d t \in D T$ .

For $R u l e_{C}$ , C is specialized in $C D$ , $D E$ , $O C$ , and so forth, in an MDR data description region, so C is mapped to $C l$ . Due to the fact that R is an undirected relation and $R R$ has direction, $R R$ is mapped to $R e l$ . And link has the same tuple $L E$ and relation also has the same tuple $C l$ ; hence, there are two types of results when $l i n k$ is mapped into $r e l a t i o n$ , which depends on $R R$ . This is because the ontology schema model expresses the ontology as a triple statement with a direction such as (subject, predicate, object). However, the $l i n k$ is able to map two $r e l a t i o n s$ by $R R$ . Thus, a user needs to select a subject and an object when CaSOB uses rule (c) in $R u l e_{C}$ .

For example, Figure 3 shows two expected mapping results, (1) and (2), where $l i n k$ has two $L E s$ , that is, ${< “ Sensor”, “ superclassOf” >, < “ System”, “ subclassof” >}$ $\in L E$ , whereas the mapping model cannot automatically determine which $L E$ becomes a subject or an object in $r e l a t i o n$ of the ontology schema model. Thus, a user needs to select the subject and object of $r e l a t i o n$ . Because the subclass is typically more used than superclass in ontology language, the user could select (1) as the mapping result, expressed by $r e l a t i o n_{s u b c l a s s O f}$ (“Sensor”, “System”).

Figure 3

The expected mapping results with $R u l e_{C}$ .

The MDR data description model specifically describes the meaning of metadata and provides an explanation of the concepts defined in the MDR concepts model. The six tuples of the MDR data description model, that is, $C D, D E C, O C, P r, V M$ , and $D i m$ , are inherited by C in the MDR concepts model. C is expressed differently depending on the property of the inherited tuples. Thus, each tuple is mapped to $C l, P$ , or $D T$ , while most of the ontologies mapped by Rule _D are triple statements such as ( $C l, P$ , and $D T$ ). $C D, O C, V M$ , and $D i m$ are only mapped to $C l$ in the six tuples, because they are entities which are connected by other classes. $V D$ is mapped to $D T$ although $V D$ does not mean data type. However, $V D$ contains a data type inside and $D E$ contains $V D$ , not a data type directly. Also if $V D$ is mapped to $D T$ , we can define some special data types like 2-alpha country code. $P r$ is mapped to P, because $P r$ indicates an attribute of classes. $D E C$ contains $O C$ and $P r$ , so $D E C$ is mapped to $C l$ and P both. Similarly $D E$ contains $D E C$ and $V D$ , so $D E$ could be mapped to ( $C l, P, D T$ ) statement.

Figure 4 shows a mapping example for $R u l e_{D}$ . The MDR data description model expresses $D E$ as “System hasSerialNumber” with a “String” data type, where $“ System ” \in O C$ , $“ hasSerialNumber ” \in P r$ , <“System”, “hasSerialNumber”> $\in D E C$ , and $“ String ” \in V D$ . As a result, the ontology schema model constructs a (“System”, “hasSerialNumber”, “String”) statement, where $“ System ” \in C l$ , “hasSerialNumber” $\in$ P, and $“ String ” \in D T$ .

Figure 4

A mapping example using $R u l e_{D}$ .

3.2. Ontology Building Process

3.2.1. Concept System Selection

The first process for building ontology is to decide a domain of an ontology. If domains are different from each other, ontology meanings and relations are different, even if they have the same terminology. A concept system includes the domain and scope of the data. Thus, CaSOB determines the domain of an ontology by selecting a concept system from $C S$ .

In the first process shown in Figure 5, the concept system “CSIRO Sensor Ontology” in $C S$ is selected if a user wants to build an ontology in a sensor domain defined by CSIRO.

Figure 5

An example of the ontology building process.

3.2.2. Candidate Selection

In the candidate selection process, candidates are selected to build an ontology. Tuples of the MDR concepts model, such as $C, R$ , and $l i n k$ , may be selected as candidates. The candidates are the same as the set of terms used when ontologies are created.

C and link are selected from $C S$ as candidate C and candidate $l i n k$ , respectively. $l i n k$ contains $C, R, R R$ , and $L E$ so both candidate C and candidate $l i n k$ can be selected from one $l i n k$ . The selected $l i n k$ becomes candidate $l i n k$ . C included in $l i n k$ is automatically selected as candidate C.

The concept system “CSIRO Sensor Ontology” is selected during the first step of Figure 5. The next step is to select the terms contained at the domain. Candidates are selected such as “Sensor,” “SensorGrounding,” and “supports.”

3.2.3. Class and Relation Definition

In the third process, $C l$ and $R e l$ of the ontology schema model are defined by the candidates. A set of candidate concepts is defined for $C l$ , while a set of candidate links is defined for $R e l$ .

However, CaSOB does not know the difference of $R R$ for C , such as the “Subject” and “Object” in an actual system. It is difficult to automatically determine roles simply by using candidate $l i n k$ . Thus, a user has to determine the subject and object of $r e l a t i o n$ in the ontology schema model.

In the third step shown in Figure 5, $C l$ and $R e l$ are defined using the selected terms. ${“ Sensor”, “ SensorGrounding”} \subset C l$ are defined, while $“ supports ” \in R e l$ is defined between “Sensor” as a subject and “SensorGrounding” as an object. In this process, it is possible to define concepts and relation over the domains. To define $C l$ and $R e l$ in other domains, we need to come back to the first process; choose “MMI Ontology,” and select candidates for selecting terms defined in “MMI Ontology” domain. Then, Figure 5 shows ${“ System”} \subset C l$ is also defined, and $“ subclassOf ” \in R e l$ is defined between “Sensor” as a subject and “System” as an object.

3.2.4. Detailed Class Definition

In the final process, P and $D T$ are defined to decide properties of classes, and additionally $C l$ and $R e l$ are defined by the mapping model.

Because $“ System ” \in C l$ was defined in the previous step, it is given that “hasSerialNumber” $\in P$ with $“ String ” \in D T$ and $“ isConsumable ” \in P$ using $“ Boolean ” \in D T$ in the final step of Figure 5.

4. Implementation

This section describes a metadata registry and CaSOB implementation. To make easy connection and mapping model, we need to implement a metadata registry based on MDR specification. The metadata registry is implemented by MySQL database, which is a RDBMS (relational database management system). For testing, we need to store datasets in the metadata registry, so we select several sensor ontologies as the dataset. Then we assume that the selected ontologies contained common concepts, so the datasets stored in the metadata registry also contain common concepts. CaSOB is developed in C# for a user interface, database connection, and the ontology building processes.

4.1. A Metadata Registry Implementation

The metadata registry is implemented so the MDR metamodel could collect data directly as required, to import the administered metadata and create an ontology. Thus, we initially develop the metadata registry by implementing the metamodel of MDR. Section 4.1 presents the MDR-based system structured by RDBMS.

Each component in the metamodel is defined as RDBMS table, while properties of each component are defined as table attributes. Moreover, associations between components are defined using foreign key referential integrity.

Figure 6 shows the table and foreign key references of the concepts region in MDR. The “Concept” table includes the attributes “concept” and “source.” “concept” is an attribute where the name held by the concept of MDR is expressed using strings. “source” is an attribute that expresses a concept system including concepts using foreign key references. Moreover, the “Link” table has a “relation” attribute for the “Relation” table. The “Link_End” table has the attributes “end” and “role” for the “link” attribute, where “end” means the concept, “role” means the relation role, and “link” means the link. Thus, one link has at least two link ends.

Figure 6

Implementation of the concepts region.

In Figure 7, the data description region is implemented as tables and foreign key references. Seven components in the data description region inherit the concept in the concepts region, so the components express the inheritance using each of the attributes of “concept” and “concept source” held in the “Concept” table.

Figure 7

Implementation of the data description region.

4.2. CaSOB Implementation

In Section 4.2, the ontology building process of CaSOB is presented with the implementation screen, which is based on the four processes of ontology creation.

4.2.1. Concept System Selection (Process 1)

If the domain of the ontology to be created has been determined, the system searches and selects the concept system (CS) of the corresponding domain. In Figure 8(a), CS of Process 1 is selected in the upper right corner of the screen as “CSIRO Sensor Ontology” to create the sensor ontology.

Figure 8

Screenshots of CaSOB.

4.2.2. Candidate Selection (Process 2)

The process selects each candidate concept and each candidate link from the concepts (C) and links (link), including the concept system selected in Process 1. Type currently indicates the seven components inheriting the concept.

In Figure 8(a), “support ${Sensor (supportedBy)$ , $SensorGrounding (supports)} ”$ is selected from links. The selected link is added to candidate link and contained concepts “Sensor” and “SensorGrounding” are automatically added to candidate concepts.

4.2.3. Class and Relation Definition (Process 3)

The process defines the classes $(C l)$ and relations $(R e l)$ of the ontology schema model from the selected candidates. A user selects the desired candidate concept to define $C l$ and selects candidate links to set the domain and range of Rel. An R including the candidate link is mapped to a $R e l$ of the ontology. The domain and range are set during the selection of a candidate link with the roles of a subject and an object, respectively. A user selects each candidate to define the $C l$ and $R e l$ of the ontology schema model.

In Figure 8(b), to define $“ System ” \in C$ in other domains, $“ MMI Ontology ” \in C S$ is selected. And “System” is selected as candidate concepts and “class-subsumption ${Sensor (superclassOf), System (subclassOf)}$ ” is selected as candidate links. The marked candidate link expresses “class-subsumption” which has (“Sensor”, “subclassOf”, “System”) statement.

4.2.4. Detailed Definition of Classes (Process 4)

This process defines classes ( $C l$ ) and properties (P) of the classes using the candidate concept and the type of concepts. Additional relations ( $R e l$ ) are also created.

In this process, a user selects the candidate concepts. Each concept has a type and has different mechanism to build ontologies according to the mapping model ( $M M$ ). A user defines $C l, P, D T$ , and additional $R e l$ of the ontology schema model. When a candidate concept is selected, the data that can be selected changes depending on its type so an ontology is created containing the relations among components that were defined in the previous section.

For example, Figure 8(c) shows a screenshot of the detailed definition of Cl in the ontology schema model. The selected candidate concept “System” has data element concept (DEC) type. “hasSerialNumber” $\in P r$ becomes P with $“ String ” \in D T$ for $“ System ” \in C l$ from $“ System, hasSerialNumber, String ” \in D E$ associated with $“ System, hasSerialnumber ” \in D E C$ .

4.2.5. The Created Ontology

Figure 8(d) shows the complete ontology for all processes. The complete ontology is mainly comprised of classes ( $C l$ ), properties (P), and relations ( $R e l$ ). P of each specific $C l$ has a data type ( $D T$ ). Rel has two $C l s$ with the roles of domain and range.

CaSOB provides a general ontology for a target ontology. It means that CaSOB does not provide specific ontology languages such as RDF, OWL, SKOS, and Topic Map. Thus, a user needs to describe the complete ontology using a specific ontology language. Algorithm 1 shows the ontology created in Figure 8(d) as described using OWL.

Algorithm 1: An ontology described using OWL.

$<$ ?xml version=“1.0”? $>$

<Ontology xmlns=“http://www.w3.org/2002/07/owl#”

xml:base=“http://software.korea.ac.kr/SwsysSensorOntology.owl”

xmlns:rdfs=“http://www.w3.org/2000/01/rdf-schema#”

xmlns:xsd=“http://www.w3.org/2001/XMLSchema#”

xmlns:rdf=“http://www.w3.org/1999/02/22-rdf-syntax-ns#”

xmlns:xml=“http://www.w3.org/XML/1998/namespace”

<Prefix name=“xsd”

IRI=“http://www.w3.org/2001/XMLSchema#”/>

<Prefix name=“owl”

IRI=“http://www.w3.org/2002/07/owl#”/>

</Declaration>

</ObjectPropertyDomain>

</ObjectPropertyRange>

</ObjectPropertyDomain>

</ObjectPropertyRange>

</ObjectPropertyDomain>

</ObjectPropertyRange>

</ObjectPropertyDomain>

</ObjectPropertyRange>

</DataPropertyDomain>

</DataPropertyRange>

</DataPropertyDomain>

</DataPropertyRange>

</Ontology>

5. Evaluation

5.1. Qualitative Evaluation

We conducted a comparative evaluation study for ontology creation. This section first describes our qualitative evaluation using various comparative items. This evaluation involved the comparative evaluation of three ontology building approaches which are user-defined approach, ontology reuse approach, and our proposed MDR based approach. Table 1 shows the qualitative evaluation results.

Table 1

Qualitative evaluation of ontology building approaches.

Approach	Standardization level	Ontology quality	Limitation of expression	Creation cost
User-defined	Low	Low	No limitation	High
Ontology reuse	High	Medium	Very strict	Low
MDR based (our proposal)	High	High	Strict	Medium

The first factor for evaluation is standardization level. It means whether the created ontology could be used as a common or general ontology or not. User-defined approach is hard to become a common standard approach because of experts who can create ontologies based on their own knowledge. Hence created ontologies by user-defined approach cannot share their concept. On the other hand, since ontology reuse approach and MDR based approach use ontologies already created, which can contain common concepts, created ontology using these ontology reuse and MDR based approaches can become standardized ontologies. That is why each standardization level of these two approaches becomes high.

The second evaluation factor is ontology quality. Ontology quality means whether created ontologies are well defined and whether the quality of created ontologies is guaranteed. In case of user-defined approach, a created ontology contains personal view point without general or common perspective. Therefore, the created ontology cannot guarantee the quality of ontologies. CSIRO, MMI, and ISTAR ontologies are popular ontologies. These ontologies are one of the results from each big project. These ontologies are verified by a lot of experts whether concepts and relationships of these ontologies are well defined or not. If we create a new ontology reusing these well-defined ontologies, we can guarantees the ontology quality. In MDR based approach, ontologies and common concepts are controlled by MDR organizations that follow a standardized procedure for managing common concepts and reflect a standardized lifecycle for creating ontologies. It means that the MDR-based ontology reuse approach enables high-quality ontology creation.

Limitation of expression means how the expressive power is restricted when ontologies are created. User-defined approach has no limitation to express knowledge based on ontologies because a user selects their own terms and the user can make relationships following user's opinion. Ontology reuse approach just uses existing ontologies. It is not allowed to change existing concepts and terms when concepts or terms are incorrect from target domain. Thus, the expression of ontology is very strict. MDR based approach reuses registered ontologies in the metadata registry. The MDR based approach also permits changing other ontologies when there are no concepts or terms that are required in existing ontologies. Nevertheless, the MDR approach is strict because it is not allowed to define unregistered ontologies.

The final factor of qualitative evaluation is creation cost. Creation cost means convenience of creating ontologies and time for building ontologies. In user-defined approach, experts directly define concepts and terms, and it requires high cost to survey domain knowledge and collect reference documents for verification. Ontology reuse approach uses existing ontologies without change if the existing ontologies coincide with concepts and terms in target domain. Thus, the cost for ontology creation is low. MDR based approach uses ontologies registered in a metadata registry. When ontologies are created, users need to search terms and their relations to apply the search result to new ontologies. Users also need a customization task to create link between domains and ranges. Although this approach requires medium cost which is higher cost than the cost of ontology reuse approach, the cost of MDR approach is lower than user-defined approach.

5.2. Quantitative Evaluation: Simulation Approach

This section describes our quantitative analysis, which clearly shows the advantages of the proposed system, CaSOB. Many systems and studies have addressed interoperability between ontologies. However, most focus on interoperability issue among ontologies, which have already been created with their own ontology schema definition rules. Our approach is implemented in the step before ontology creation, which aims to reuse common concepts and increase interoperability. This paper defines existing approaches as user-defined ontology schema creation methods and we conducted a quantitative evaluation to compare our method with the user-defined schema creation method. The metadata registry also provides no schema creation method because its purpose is to register and share ontologies. In other words, our proposed method, CaSOB, is based on the MDR, but the metadata registry is excluded from the quantitative evaluation.

An appropriate comparative item was determined for the evaluation. The goal of this paper is to minimize the semantic heterogeneity of ontologies via the reuse of common concepts. Therefore, this paper conducted a quantitative evaluation of the semantic heterogeneity rate. We can estimate the approximate ontology integration cost using the semantic heterogeneity rate, so this paper also includes the ontology integration cost as a comparative item.

The evaluation methodology is summarized as follows: (i)

comparative targets: our proposed method, CaSOB, and the user-defined ontology schema creation method,

(ii)

comparative items: the semantic heterogeneity rate, that is, the number of heterogeneous semantics (concepts) shared among the created ontologies; the ontology integration cost, that is, the cost required to integrate a set of created ontologies.

The key symbols and notations are defined as follows: (i)

O: a set of ontologies created with a target method; $O = {o_{1}, o_{2}, o_{3}, \dots, o_{n}}$ ,

(ii)

$o_{i}$ : a created ontology consisting of one or more semantics, that is, a set of concepts such as classes, relations, properties, and data types,

(iii)

C: a set of common concepts registered and used for creating an ontology,

(iv)

$H e C_{i}$ : a set of heterogeneous concepts in the ith ontology among the created ontologies,

(v)

$H o C$ : a set of homogeneous concepts among the created ontologies,

(vi)

$n (O)$ : the number of created ontologies,

(vii)

$n (o_{i})$ : the number of concepts in the ith ontology,

(viii)

$n (C)$ : the number of common concepts used to create an ontology,

(ix)

$n (H e C_{i})$ : the number of heterogeneous concepts in the ith ontology,

(x)

$r (H o C)$ : the average ratio of homogeneous concepts,

(xi)

$r (C)$ : the average ratio of used common concepts,

(xii)

t: semantic interpretation time between two concepts; $0 < t < 1$ ,

(xiii)

$S H N$ : the number of heterogeneous concepts,

(xiv)

$O I C$ : the ontology integration cost.

For the evaluation, we assume that n-people generate an ontology in the same domain. In this case, the homogeneous concept means concepts which are commonly contained by most of the ontologies. For example, the concept such as sensor could be a homogeneous concept even though each of the sensor ontologies is developed by different people. On the other hand, the heterogeneous concept means discordant concepts with each of the ontologies. We assume that the number of heterogeneous concepts is the number of total concepts without an average ratio of homogeneous concepts.

Figure 9 shows the comparative evaluation result for the semantic heterogeneity as $S H N$ . The evaluation determines the variation in the number of heterogeneous concepts depending on the change in the ratio of homogeneous concepts and the ratio of used common concepts.

Figure 9

Comparative evaluation results for the number of semantic heterogeneities.

$S H N_{p r o p o s a l}$ considers the common concepts used to build an ontology. In other words, it is the result of an evaluation using our proposed method. $S H N_{p r e v i o u s}$ is an evaluation result using a user-defined schema creation method.

The number of heterogeneous concepts in $S H N_{p r e v i o u s}$ and $S H N_{p r o p o s a l}$ is calculated as follows:

\begin{matrix} S H N = \sum_{i = 1}^{n (O)} n (H e C_{i}) . \end{matrix}

(5)

Once

S H N_{p r e v i o u s}

is determined, the number of heterogeneous concepts is

\begin{matrix} n (H e C_{i}) = {\begin{cases} n (o_{i}) - (n (o_{i}) \times r (H o C)), & r (H o C) < 1, \\ 0, & otherwise . \end{cases} \end{matrix}

(6)

And when

S H N_{p r o p o s a l}

is determined, the number of heterogeneous concepts is

\begin{matrix} n (H e C_{i}) = {\begin{cases} n (o_{i}) \\ - ((n (o_{i}) \times r (H o C)) \\ + (n (o_{i}) \times r (C))), & r (H o C) + r (c) < 1, \\ 0, & otherwise . \end{cases} \end{matrix}

(7)

Figure 9 shows that in all cases there is a decrease in the number of heterogeneous concepts, which is inversely proportional to the ratio of used common concepts. Thus, the results demonstrate the efficiency of the use of common concepts for heterogeneity problems.

Figure 10 shows the comparative evaluation results for the ontology integration costs. The ontology integration cost is the time taken for the comparison of ontology integration. The magnitude of the comparison decreases with the increasing size of the homogeneous concepts and the common concepts. The ontology integration cost is calculated as follows:

\begin{array}{l} O I C = \sum_{i = 1}^{n (o)} (n (H e C_{i}) \\ \times ((\sum_{j = 1}^{n (o)} n (H e C_{j})) - n (H e C_{i})) \times t . \end{array}

(8)

When

O I C_{p r e v i o u s}

is determined, the number of heterogeneous concepts uses the same equation as the

{S H N}_{p r e v i o u s}

. Similarly, when

O I C_{p r o p o s a l}

is determined, the number of heterogeneous concepts uses the same equation as the

S H N_{p r o p o s a l}

Figure 10

Comparative evaluation results for the ontology integration costs.

Figure 10 shows that in all cases the decrease in the ontology integration cost is inversely proportional to the square of the ratio of the common concepts. Thus, the results show that a greater use of common concepts is efficient for ontology matching and integration.

6. Conclusion

In various domains of sensor network environment, sensor ontologies are developed to represent sensor information consistently and increase interoperability. However, these sensor ontologies are defined with specific purposes, and thus we cannot use the existing sensor ontologies as it is.

This paper proposed MDR based approach to solve the heterogeneity problems. MDR based approach develops ontologies using common concepts and metadata registered in a metadata registry. The approach guarantees a quality of ontologies and solves the heterogeneity problems. We proposed MDR based Ontology Builder (CaSOB) framework, described mapping model between MDR and ontology, and presented ontology building processes. For implementation, we developed the metadata registry with RDBMS and CaSOB system. In qualitative evaluation, we compared the proposed approach with user-defined approach and ontology reuse approach. As a result, the proposed approach shows advantages from ontology quality and creation cost. For quantitative evaluation we compared CaSOB system with user-defined ontology creation method, and CaSOB system efficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching and integration technique perspective.

The proposed approach still has several limitations which should be resolved. First, CaSOB does not handle constraints and objects (individuals) in instance level. Therefore, the proposed system should be extended to address this issue. CaSOB requires a manual processing by ontology designers for selecting proper concepts. It causes high cost, and thus an automatic creation function should be studied.

Footnotes

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Acknowledgments

This research was supported by the Next-Generation Information Computing Development Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Science, ICT & Future Planning (2012M3C4A7033346). And this research was supported by the Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education, Science and Technology (no. 2011-0004911). The cocorresponding authors are Doo-Kwon Baik and Dongwon Jeong.

References

Botts

Percivall

Reed

Davidson

OGC sensor web enablement: overview and high level architecture

OpenGIS White Paper 2007 OGC 07-165

Open Geospatial Consortium

Sheth

Henson

Sahoo

S. S.

Semantic sensor web

IEEE Internet Computing 2008 12 4 78 83

2-s2.0-47649100253

10.1109/MIC.2008.87

Russomanno

D. J.

Kothari

Thomas

Sensor ontologies: from shallow to deep models

Proceedings of the 37th Southeastern Symposium on System Theory (SST '05)

2005

2-s2.0-33744924455

Compton

Barnaghi

Bermudez

Garcia-Castro

Corcho

Cox

Graybeal

Hauswirth

Henson

Herzog

Huang

Janowicz

Kelsey

W. D.

Phuoc

D. L.

Lefort

Leggieri

Neuhaus

Nikolov

Page

Passant

Sheth

Taylora

The SSN ontology of the W3C semantic sensor network incubator group

Journal of Web Semantics 2012 17 25 32

Eastman

Schlenoff

Balakirsky

Hong

A sensor ontology literature review

NISTIR 2013 7908

National Institute of Standards and Technology

W3C Incubator Group

Semantic sensor network XG final report

W3C Incubator Group Report 2011

W3C

Kim

Cha

Cho

Ontology-based methodology for managing heterogeneous wireless sensor networks

International Journal of Distributed Sensor Networks 2013 2013 9

610684

10.1155/2013/610684

Lezcano

Santos

García-Barriocanal

Semantic integration of sensor data and disaster management systems: the emergency archetype approach

International Journal of Distributed Sensor Networks 2013 2013 11

424821

10.1155/2013/424821

Shi

Zhou

Zhang

Sensor ontology building in semantic sensor web

IInternet of Things 2012 277 284

10.

ISO/IEC JTC1/SC32

ISO/IEC 11179 Metadata Registries (MDR) Part 1: Framework 2013 3rd

11.

ISO/IEC JTC1/SC32

ISO/IEC 11179 Metadata Registries (MDR) Part 2: Classification 2005 2nd

12.

ISO/IEC JTC1/SC32

ISO/IEC 11179 Metadata Registries (MDR) Part 3: Registry Metamodel and Basic Attributes 2013 3rd

13.

ISO/IEC JTC1/SC32

ISO/IEC 11179 Metadata Registries (MDR) Part 4: Formulation of Data Definition 2007 2nd

14.

ISO/IEC JTC1/SC32

ISO/IEC 11179 Metadata Registries (MDR) Part 5: Naming and Identification Principles 2013 3rd

15.

ISO/IEC JTC1/SC32

ISO/IEC 11179 Metadata Registries (MDR) Part 6: Registration 2013 3rd

16.

Castano

Ferrara

Montanelli

Ontology-based interoperability services for semantic collaboration in open networked systems

Interoperability of Enterprise Software and Applications 2006 135 146

17.

Castano

Ferrara

Montanelli

Matching ontologies in open networked systems: techniques and applications

Journal on Data Semantics V 2006 25 63

18.

Pirro

Ruffolo

Talia

SECCO: on building semantic links in Peer-to-Peer networks

Journal on Data Semantics XII 2009 1 36

19.

Bakillah

Mostafavi

M. A.

G-Map semantic mapping approach to improve semantic interoperability of distributed geospatial web services

Advances in Conceptual Modeling: Applications and Challenges 2010 12 22

20.

Matuszek

Cabrai

Witbrock

DeOliveira

An introduction to the syntax and content of Cyc

Proceedings of the Spring Symposium on Formalizing and Compiling Background Knowledge and Its Applications to Knowledge Representation and Question Answering

March 2006

44 49

2-s2.0-33747187839

21.

Biebow

Szulman

TERMINAE: a linguistics-based tool for the building of a domain ontology

Knowledge Acquisition, Modeling and Management 1999 49 66

22.

SensorOntology2009

CSIRO sensor ontology

2009, http://www.w3.org/2005/Incubator/ssn/wiki/SensorOntology2009

23.

MMI, Marine Metadata Interoperability

2009, http://marinemetadata.org/community/teams/ontdevices

24.

Defence Science and Technology Laboratory

ISTAR and sensors

https://www.dstl.gov.uk/istarandsensors

25.

Compton

Henson

Lefort

Neuhaus

Sheth

A survey of the semantic specification of sensors

Proceedings of the 2nd International Workshop on Semantic Sensor Networks (SSN '09)

2009

17 32

26.

Neuhaus

Compton

The semantic sensor network ontology: a generic language to describe sensor assets

Proceedings of the AGILE Pre-Conference Workshop Challenges in Geospatial Data Harmonisation

2009

27.

Rueda

Bermudez

Fredericks

The MMI ontology registry and repository: a portal for marine metadata interoperability

Proceedings of the MTS/IEEE Biloxi: Marine Technology for Our Future: Global and Local Challenges (OCEANS '09)

2009

1 6

28.

Preece

Gomez

de Mel

Vasconcelos

Sleeman

Colley

Pear-son

Pham

Porta

Matching sensors to missions using a knowledge-based approach

Defense Transformation and Net-Centric Systems

2008

Proceedings of SPIE

Canonical Sensor Ontology Builder Based on ISO/IEC 11179 for Sensor Network Environments: A Standardized Approach

Abstract

1. Introduction

2. Semantic Heterogeneity Problem of Sensor Ontologies

3. The CaSOB Framework

3.1. Mapping Model

3.1.1. Preliminary Definition

Definition 1 (MDR concepts model).

Definition 2 (MDR data description model).

Definition 3 (ontology schema model).

3.1.2. CaSOB Mapping Model

Definition 4 (mapping model).

3.2. Ontology Building Process

3.2.1. Concept System Selection

3.2.2. Candidate Selection

3.2.3. Class and Relation Definition

3.2.4. Detailed Class Definition

4. Implementation

4.1. A Metadata Registry Implementation

4.2. CaSOB Implementation

4.2.1. Concept System Selection (Process 1)

4.2.2. Candidate Selection (Process 2)

4.2.3. Class and Relation Definition (Process 3)

4.2.4. Detailed Definition of Classes (Process 4)

4.2.5. The Created Ontology

Algorithm 1: An ontology described using OWL.

5. Evaluation

5.1. Qualitative Evaluation

5.2. Quantitative Evaluation: Simulation Approach

6. Conclusion

Footnotes

Conflict of Interests

Acknowledgments

References