research article canonical sensor ontology builder based on iso/iec 11179 for sensor...

15
Research Article Canonical Sensor Ontology Builder Based on ISO/IEC 11179 for Sensor Network Environments: A Standardized Approach Sukhoon Lee, 1 Dongwon Jeong, 2 Jangwon Gim, 3 and Doo-Kwon Baik 4 1 Department of Computer and Radio Communications Engineering, Korea University, Anam-dong 1, 5-ga, Seongbuk-gu, Seoul 136-701, Republic of Korea 2 Department of Statistics and Computer Science, Kunsan National University, 558 Daehangno, Gunsan, Jeollabuk-do 573-701, Republic of Korea 3 Department of Computer Intelligence Research, Korea Institute of Science and Technology Information (KISTI), 245 Daehak-ro, Yuseong-gu, Daejeon 305-806, Republic of Korea 4 Graduate School of Convergence IT, Korea University, Anam-dong 1, 5-ga, Seongbuk-gu, Seoul 136-701, Republic of Korea Correspondence should be addressed to Doo-Kwon Baik; [email protected] Received 19 November 2013; Accepted 11 February 2014; Published 30 March 2014 Academic Editor: Hwa-Young Jeong Copyright © 2014 Sukhoon Lee et al. is is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. e 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. is paper proposes an ontology generation system based on ISO/IEC 11179–MDR (metadata registry). e 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. is 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. erefore, 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 hetero- geneity 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]. us, 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 [36]. e sensor ontologies are used as schemas of sensor data in a specific domain. erefore, some sensor network systems which use the same sensor ontology in a specific domain guarantee syn- tactic 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 Hindawi Publishing Corporation International Journal of Distributed Sensor Networks Volume 2014, Article ID 790918, 14 pages http://dx.doi.org/10.1155/2014/790918

Upload: others

Post on 06-Apr-2020

15 views

Category:

Documents


0 download

TRANSCRIPT

Research ArticleCanonical Sensor Ontology Builder Based on ISOIEC 11179 forSensor Network Environments A Standardized Approach

Sukhoon Lee1 Dongwon Jeong2 Jangwon Gim3 and Doo-Kwon Baik4

1 Department of Computer and Radio Communications Engineering Korea University Anam-dong 1 5-gaSeongbuk-gu Seoul 136-701 Republic of Korea

2Department of Statistics and Computer Science Kunsan National University 558 Daehangno GunsanJeollabuk-do 573-701 Republic of Korea

3 Department of Computer Intelligence Research Korea Institute of Science and Technology Information (KISTI)245 Daehak-ro Yuseong-gu Daejeon 305-806 Republic of Korea

4Graduate School of Convergence IT Korea University Anam-dong 1 5-ga Seongbuk-gu Seoul 136-701 Republic of Korea

Correspondence should be addressed to Doo-Kwon Baik baikdkkoreaackr

Received 19 November 2013 Accepted 11 February 2014 Published 30 March 2014

Academic Editor Hwa-Young Jeong

Copyright copy 2014 Sukhoon Lee et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

The advancement of sensor technology has led to an explosive increase in sensors It causes semantic heterogeneity problems andmuch research has focused on sensor ontology building to solve the problems However there are still remaining several issues andone of the most critical issues is about a method for progressive and dynamic concepts management and reuse of sensor ontologyThis paper proposes an ontology generation system based on ISOIEC 11179ndashMDR (metadata registry) The proposed system isreferred to as theCanonical SensorOntologyBuilder (CaSOB) and can create ontologies by reusing the common concepts registeredin a canonical sensor ontology concept registry an MDR This paper defines a mapping model and processes to create ontologywith the concepts registered in an MDR Our proposal provides many advantages such as high standardization consistent conceptusage and easy semantic exchange Therefore CaSOB facilitates the high quality sensor ontology creation and reduces the costs ofsensor ontology integration and system development

1 Introduction

With the advancement of sensor technology the number ofsensors and application domains have been tremendouslyincreased It leads to a huge amount of sensor data as wellas many kinds of sensor types in sensor network worldsHowever those increments cause various kinds of hetero-geneity problems such as heterogeneity between data typesformats and units of measure Although we should be ableto interpret and use all sensor information from any sensorsin any sensor networks those heterogeneity issues make itdifficult to use seamlessly and transparently sensor data fromall sensor networks

Many studies have been done to resolve those issuesand this section describes only the OGC (Open GeospatialConsortium) effort one of the representative approachesOGC established SWE (Sensor Web Enablement) to store

discover access and use all types of sensor information onthe web [1] Thus the various sensor information definedaccording to SWE enables representing syntactic modelconsistently Also for representing semantics in the syntacticmodel SSW (Semantic SensorWeb) appearedwith extendingthe Semantic Web concept [2] SSW represents the semanticsensor information such as space time and theme as a webontology

Many sensor ontologies have been developed to representthe sensor information in various domains [3ndash6] The sensorontologies are used as schemas of sensor data in a specificdomain Therefore some sensor network systems which usethe same sensor ontology in a specific domain guarantee syn-tactic model semantic data interchange and interoperability

However if we need to establish a new sensor network fora new domain or having different purposes it is impossibleto directly adopt the existing sensor ontology and we need

Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2014 Article ID 790918 14 pageshttpdxdoiorg1011552014790918

2 International Journal of Distributed Sensor Networks

to modify the existing ontology or add a new ontologyThe modification and addition of ontologies cause anotherheterogeneity problem at conceptual (ontology schema) level[7 8] In other words when we build a new ontology or reuseexisting ontologies for adoption in other domains or for otherpurposes we would customize the existing sensor ontologies[9] It causes another semantic inconsistency between sensorontologies

This paper presents a method for sensor ontology man-agement and reuse based ISOIEC 11179 Metadata Registry(MDR) 3rd Edition for resolving the semantic heterogeneityissue aforementioned MDR is an international standardwhich has been revised for ontology management and pub-lished in 2013 A metadata registry based on MDR canmanage metadata and the relations among them [10ndash15]Ontologies also are registered and managed in the metadataregistry An MDR instance manages common concepts fromthe registered ontologies and thus it ensures that ontologiesare defined well and reusable by diverse systems Reusingcommon concepts for building ontology enhances the ontol-ogy quality and semantic interoperability between sensornetworks MDR provides only the structure of registrationand the administration of an ontology but it does not supportthe ontology creation facility for reusing common conceptsTherefore this paper proposes a new framework for ontologymanagement and building based on MDR and the proposedframework is named CaSOB (Canonical Sensor OntologyBuilder) In addition this paper considers a triple statementas an ontologyThe reason is that various ontology languagessuch as OWL and RDF are formed by the triple and most ofthe ontology stores and reasoning engines are based on thetriple

This paper is organized as follows In Section 2 weintroduce previous researches into solutions to the semanticheterogeneity problem of sensor ontologies In Section 3 weexplain the CaSOB framework a mapping model and ontol-ogy building processes Our implementation is described inSection 4 while Section 5 presents the evaluation Finally weconclude this paper and discuss future work in Section 6

2 Semantic Heterogeneity Problem ofSensor Ontologies

Much research on ontologies has been directed at increasinginteroperability and solving the semantic heterogeneity prob-lem among various systems An ontologymatching techniquewas proposed for semantic interchange among peers inOpen Network Systems [16] Castano et al [17] describe analgorithm that matched ontologies using a linguistic andcontextual matchingmodel for OpenNetwork Systems Pirroet al [18] propose a similarity checking method based onWordNet for building semantic links in a peer-to-peer net-work Bakillah and Mostafavi [19] also propose an ontologymatching method based on lexical relations and mappingrules for improving the interoperability of distributed geospa-tial web services

Ontology matching methods ensure that ontology con-cepts connect together and correspond semantically after

ontologies are generated These methods can match numer-ous ontologies automatically and semiautomatically butthey can experience problems in terms of high cost andinaccuracy Therefore research on ontology sharing andreuse is required because these techniques can solve thesemantic heterogeneity problem by creating ontologies basedon common concepts Matuszek et al [20] propose a systemfor defining and reusing the common concepts while Biebowand Szulman [21] proposed ontology buildingmethods basedon terminology from a linguistic perspective

In the Semantic Sensor Web various sensor ontologieshave been developed such as CSIRO [22] MMI [23] andISTAR [24] Each of the ontologies is suitable for representinginformation of sensors and devices and exchanging theinformation between relevant services only in the samesensor network environment However the ontology cannotbe available for the environment where we would develop anew sensor network system for other application domains orwith other purposes

Compton et al [25] introduces various sensor ontologiesfrom researches and projects in various domains and com-pares the corresponding domain purposes and features ofeach of the ontologies Especially Compton et al evaluatesthe expressive power of the sensor ontologies from the per-spectives of sensor device information physical propertiesobservation quality and domain concepts

The CSIRO sensor ontology [26] is designed for a genericdomain and is intended to be used in data integration searchclassification and workflows The CSIRO sensor ontologyprovides the high expressive power in sensor physicalnessand observation perspectives However the CSIRO ontologydoes not provide concepts like sampled medium and time

MMI (Marine Metadata Interoperability) [27] aims toincrease interoperability for oceanographic devices sensorand sampler The MMI device ontology has been developedfor devices and sensors in ocean environment but irre-spective concepts such as sensor hierarchy history locationpower supply a field of view unit of measure and time havenot been defined for oceanographic devices sensors andsamplers

The ISTAR ontology [28] has the purpose for taskassignment and has been developed as part of a system toautomatically select sensors for tasks based on their fitnessfor the task description However ISTAR has only conceptsabout sensors and physical features for the task assignmentand does not consider concepts about observation anddomain

As a result the previous approaches related to the sensorontology do not provide a canonical sensor ontology conceptmanagement and building facility and thus an additionalheterogeneity issue continuously arises It causes many otherproblems and is a barrier for seamless sensor semanticsinterpretation progressive and systematic semanticsmanage-ment common concept reusability and so on For addressingthose problems this paper proposes a new sensor ontologymanagement and building framework based on MDR Thegoal of the framework proposed in this paper is to enable thecanonical management and reuse of the existing well-definedontology

International Journal of Distributed Sensor Networks 3

3 The CaSOB Framework

Figure 1 shows the CaSOB framework CaSOB contains fourprocesses (Section 32) and it creates an ontology using amapping model from MDR (Section 31) Various conceptsare registered in ametadata registry for sharing and reusing ascommon concepts Therefore the mapping model is definedusing components in regions related by common conceptsand data representations including concepts region and datadescription region from several areas of MDR As a resultontology is built as an ontology according to ontology schemamodel so this paper considers only the schema level ofontology and it excludes the instance level

31 Mapping Model

311 Preliminary Definition MDR supports the registrationand administration of common concepts And it specifiesa metamodel for the registration and administration ofcommon concepts as an MDR specification There are sevenmain regions These regions are classified as regions that reg-ister and administer concepts regions that name and defineconcepts regions that represent the relations among conceptsand components and regions that specifically describe dataIn this paper we formally define the MDR model for tworegions that is the concepts region and data descriptionregion

Definition 1 (MDR concepts model) The MDR conceptsmodel is a six-tuple

MDR119862

= (119862119878 119862 119877 119877119877 119871119864 119897119894119899119896) (1)

where one has the following(i) 119862119878 is a set of concept systems A concept system rep-

resents a domain of concepts such as an applicationdomain or knowledge domain

(ii) 119862 is a set of concepts A concept is a unit of knowledgecreated by a unique combination of characteristicsSome tuples of the MDR concepts model and theMDR data descriptionmodel inherit119862 as a basic unit

(iii) 119877 is a set of relations A relation is a concept thatrepresents the association among concepts

(iv) 119877119877 is a set of relation roles A relation role is a role ofa concept associated with a specific relation

(v) 119871119864 is a set of link ends A link end is a pair of aconcept and a relation role as one side of 119897119894119899119896 and LEis expressed by ⟨119888 and 119903119903⟩ where 119888 isin 119862 and 119903119903 isin 119877119877

(vi) 119897119894119899119896 119877 rarr 119871119864 times 119871119864 represents the linkage of twolink ends which are associated with a relation In thispaper one focuses generation of a triple statement asontology so a binary relation is only considered

The MDR concepts model defines all the conceptsand relations administered in MDR As an exampleFigure 2 shows that the MDR concepts model contains119897119894119899119896ldquoclass-subsumptionrdquo (ltldquoSensor ldquosuperclassOfrdquogt ltldquoSystemrdquoldquosubclassOfrdquogt) where ldquoSensorrdquo ldquoSystemrdquo isin 119862 ldquoclass-subsumptionrdquo isin119877 and ldquosuperclassOfrdquo ldquosubclassOfrdquoisin119877119877

Definition 2 (MDR data description model) The MDR datadescription model is an eight-tuple

MDR119863= (119862119863119881119872119881119863119874119862 119875119903 119863119864119862119863119864119863119894119898) (2)

where one has the following

(i) 119862119863 is a set of conceptual domains A conceptualdomain is a domain wherein data element conceptscould have a shared conceptual level A conceptualdomain is also used to represent a set of valuemeanings (119881119872)

(ii) 119881119872 is a set of value meanings A value meaning is ageneral meaning of actual values

(iii) 119881119863 is a set of value domains A value domain is adomain in the actual data level which represents theactual values such as a data type

(iv) 119874119862 is a set of object classes An object class is a generalconcept that can capture many instances

(v) 119875119903 is a set of properties A property is an attribute ofobjects or concepts

(vi) 119863119864119862 is a set of data element concepts A data elementconcept is a pair of a concept and a data elementAnd 119863119864119862 is expressed by ⟨119900119888 119901119903⟩ where 119900119888 isin

119874119862 and 119901119903 isin 119875119903(vii) 119863119864 sube 119863119864119862 times 119881119863 is a set of data elements The data

element is the basic unit of data for MDR(viii) 119863119894119898 is a set of dimensionalities A dimensionality

is an aggregation of the units of measures which isrelated to a conceptual domain for example lengthheight or weight

An ontology contains components that depend on thelanguage and the description method In this paper wefocused on building ontologies to improve interoperabilityamong various applications or systems so we concentratedon building ontology in schema level rather than instance orindividual level

Definition 3 (ontology schemamodel) The ontology schemamodel is a six-tuple

119874119899119905119900 = (119862119897 119875 119877119890119897 119863119879 119903119890119897119886119905119894119900119899 119901119903119900119901) (3)

where one has the following

(i) 119862119897 is a set of classes A class is a concept that groupsitems sharing the same characteristics Commoncharacteristics are described logically

(ii) 119875 is a set of properties A property indicates thecharacteristics of a class In the ontology schemamodel a property is described by connecting a classto a data type

(iii) 119877119890119897 is a set of relations in an ontology domainA relation in an ontology domain describes thecharacteristics existing among classes A relation isdescribed by connecting one class to another class

4 International Journal of Distributed Sensor Networks

Metadata registry

Ontology schemaMapping model

Mapping model Mapping model

Ontology building process

3 Class and relation 4 Detailed class definition1 Concept system selection 2 Candidate selectiondefinition

de_name reg_statusKorea01 SubmittedKorea02 Recorded

Korea02

Reg_statusSubmittedRecorded

Reg_statusSubmittedRecordedKorea02

reg_statusSubmittedRecordedKorea02

Korea02 middot middot middotKorea02 middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middotmiddot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middotde_nameKorea01Korea02Korea02 middot middot

de_nameKorea01Korea02Korea02

de_nameKorea01Korea02Korea02

with RuleC with RoleD

Figure 1 The CaSOB framework

Concepts region

Sensor

System

superclassOf

subclassOf

Link Class-subsumption

RR

RR

R

C

C

LE

LE

Figure 2 An example of the MDR concepts model

(iv) 119863119879 is a set of data types A data type is a type of valuegiven to a class property

(v) 119903119890119897119886119905119894119900119899119877119890119897 rarr 119862119897times119862119897 is a triple statement expressedby (119888119897

1 119903119890119897 119888119897

2) where 119888119897

1 1198881198972 isin 119862119897 and 119903119890119897 isin 119877119890119897

such as an object property of OWL

(vi) 119901119903119900119901 119875 rarr 119862119897 times 119863119879 is a triple statement expressedby (119888119897 119901 119889119905) where 119888119897 isin 119862119897 119901 isin 119875 and 119889119905 isin 119863119879 suchas a data type property of OWL

312 CaSOB Mapping Model The CaSOB mapping modeldefines the mapping rules based on the MDR models forthe ontology schema model as shown in the preliminarydefinition provided in Section 311 Data mapped by theCaSOB mapping model is used to build an ontology

Definition 4 (mapping model) The mapping model is a two-tuple

119872119872 = (119877119906119897119890119862 119877119906119897119890

119863) (4)

where one has the following

(i) 119877119906119897119890119862is a set of rules connecting the MDR concepts

model with the ontology schema model 119877119906119897119890119862has

three rules as follows

(a) 119862 rarr 119862119897(b) 119877119877 rarr 119877119890119897(c) 119897119894119899119896 rarr 119903119890119897119886119905119894119900119899 that is 119897119894119899119896

119903(⟨1198881 1199031199031⟩

⟨1198882 1199031199032⟩) rarr 119903119890119897119886119905119894119900119899

1199031199032(1198881198971 1198881198972) or 119903119890119897119886119905119894119900119899

1199031199031

(1198881198972 1198881198971) where 119903 rarr 119903119890119897 119888

1rarr 119888119897

1 and

1198882rarr 1198881198972with 119903 isin 119877 119888

1 1198882 isin 119862 119903119903

1 1199031199032 isin

119877119877 119903119890119897 isin 119877119890119897 and 1198881198971 1198881198972 isin 119862119897

(ii) 119877119906119897119890119863

is a set of rules connecting the MDR datadescription model and the ontology schema model119877119906119897119890119863has eight rules as follows

(a) 119862119863 rarr 119862119897(b) 119881119872 rarr 119862119897(c) 119863119894119898 rarr 119862119897(d) 119874119862 rarr 119862119897(e) 119875119903 rarr 119875(f) 119881119863 rarr 119863119879(g) 119863119864119862 rarr 119862119897 times 119875(h) 119863119864 rarr 119901119903119900119901 that is (⟨119900119888 119888ℎ⟩ V119889) rarr 119901119903119900119901

119901

(119888119897 119889119905) where 119900119888 rarr 119888119897 119901119903 rarr 119901 and V119889 rarr

119889119905 with 119889119890 isin 119863119864 119900119888 isin 119874119862 119901119903 isin 119875119903 V119889 isin 119881119863119901 isin 119875 119888119897 isin 119862119897 and 119889119905 isin 119863119879

For 119877119906119897119890119862 C is specialized in 119862119863 119863119864 119874119862 and so forthin an MDR data description region so 119862 is mapped to 119862119897Due to the fact that 119877 is an undirected relation and 119877119877 hasdirection 119877119877 is mapped to 119877119890119897 And link has the same tuple119871119864 and relation also has the same tuple 119862119897 hence there aretwo types of results when 119897119894119899119896 is mapped into 119903119890119897119886119905119894119900119899 whichdepends on 119877119877 This is because the ontology schema modelexpresses the ontology as a triple statement with a directionsuch as (subject predicate object) However the 119897119894119899119896 is able

International Journal of Distributed Sensor Networks 5

sensor

system

superclassOf

MDR concepts model Ontology schema model

subclassOfsystem

sensor

subclassOf

(2)

system

sensor

superclassOf

(1)

Class-subsumption

Rel

RelRR

RR

R

C

C

Cl

Cl Cl

Cl

Figure 3 The expected mapping results with 119877119906119897119890119862

MDR data description model Ontology schema model

system

string

hasSerialNumberhasSerialNumber

DE

DEC

Pr

VD

system

string

Cl

DT

P

OC

Figure 4 A mapping example using 119877119906119897119890119863

to map two 119903119890119897119886119905119894119900119899119904 by 119877119877 Thus a user needs to select asubject and an object when CaSOB uses rule (c) in 119877119906119897119890

119862

For example Figure 3 shows two expected mappingresults (1) and (2) where 119897119894119899119896 has two 119871119864119904 that islt ldquoSensorrdquo ldquosuperclassOfrdquo gt lt ldquoSystemrdquo ldquosubclassof rdquo gtisin 119871119864 whereas the mapping model cannot automaticallydetermine which 119871119864 becomes a subject or an object in119903119890119897119886119905119894119900119899 of the ontology schema model Thus a user needs toselect the subject and object of 119903119890119897119886119905119894119900119899 Because the subclassis typically more used than superclass in ontology languagethe user could select (1) as the mapping result expressed by119903119890119897119886119905119894119900119899subclassOf (ldquoSensorrdquo ldquoSystemrdquo)

The MDR data description model specifically describesthe meaning of metadata and provides an explanation ofthe concepts defined in the MDR concepts model Thesix tuples of the MDR data description model that is119862119863 119863119864119862 119874119862 119875119903 119881119872 and 119863119894119898 are inherited by 119862 in theMDR concepts model 119862 is expressed differently dependingon the property of the inherited tuples Thus each tupleis mapped to 119862119897 119875 or 119863119879 while most of the ontologiesmapped by RuleD are triple statements such as (119862119897 119875 and119863119879) 119862119863 119874119862 119881119872 and 119863119894119898 are only mapped to 119862119897 in thesix tuples because they are entities which are connected byother classes 119881119863 is mapped to 119863119879 although 119881119863 does notmean data type However 119881119863 contains a data type insideand 119863119864 contains 119881119863 not a data type directly Also if 119881119863 ismapped to 119863119879 we can define some special data types like 2-alpha country code 119875119903 is mapped to 119875 because 119875119903 indicatesan attribute of classes 119863119864119862 contains 119874119862 and 119875119903 so 119863119864119862 is

mapped to 119862119897 and 119875 both Similarly 119863119864 contains 119863119864119862 and119881119863 so119863119864 could be mapped to (119862119897 119875 119863119879) statement

Figure 4 shows a mapping example for 119877119906119897119890119863 The MDR

data description model expresses 119863119864 as ldquoSystem hasSerial-Numberrdquo with a ldquoStringrdquo data type where ldquoSystemrdquo isin 119874119862ldquohasSerialNumberrdquo isin 119875119903 ltldquoSystemrdquo ldquohasSerialNumberrdquogtisin 119863119864119862 and ldquoStringrdquo isin 119881119863 As a result the ontology schemamodel constructs a (ldquoSystemrdquo ldquohasSerialNumberrdquo ldquoStringrdquo)statement where ldquoSystem10158401015840 isin 119862119897 ldquohasSerialNumberrdquo isin P andldquoStringrdquo isin 119863119879

32 Ontology Building Process

321 Concept System Selection The first process for buildingontology is to decide a domain of an ontology If domains aredifferent from each other ontology meanings and relationsare different even if they have the same terminology Aconcept system includes the domain and scope of the dataThus CaSOB determines the domain of an ontology byselecting a concept system from 119862119878

In the first process shown in Figure 5 the concept systemldquoCSIRO Sensor Ontologyrdquo in 119862119878 is selected if a user wants tobuild an ontology in a sensor domain defined by CSIRO

322 Candidate Selection In the candidate selection processcandidates are selected to build an ontology Tuples of theMDR concepts model such as119862 119877 and 119897119894119899119896may be selectedas candidates The candidates are the same as the set of termsused when ontologies are created

119862 and link are selected from 119862119878 as candidate 119862 andcandidate 119897119894119899119896 respectively 119897119894119899119896 contains119862 119877 119877119877 and 119871119864 soboth candidate119862 and candidate 119897119894119899119896 can be selected from one119897119894119899119896 The selected 119897119894119899119896 becomes candidate 119897119894119899119896 119862 included in119897119894119899119896 is automatically selected as candidate 119862

The concept system ldquoCSIRO Sensor Ontologyrdquo is selectedduring the first step of Figure 5 The next step is to select theterms contained at the domain Candidates are selected suchas ldquoSensorrdquo ldquoSensorGroundingrdquo and ldquosupportsrdquo

323 Class and Relation Definition In the third process 119862119897and 119877119890119897 of the ontology schema model are defined by thecandidates A set of candidate concepts is defined for119862119897 whilea set of candidate links is defined for 119877119890119897

However CaSOB does not know the difference of 119877119877 for119862 such as the ldquoSubjectrdquo and ldquoObjectrdquo in an actual system Itis difficult to automatically determine roles simply by usingcandidate 119897119894119899119896 Thus a user has to determine the subject andobject of 119903119890119897119886119905119894119900119899 in the ontology schema model

In the third step shown in Figure 5119862119897 and119877119890119897 are definedusing the selected terms ldquoSensorrdquo ldquoSensorGroundingrdquo sub

119862119897 are defined while ldquosupportsrdquo isin 119877119890119897 is defined betweenldquoSensorrdquo as a subject and ldquoSensorGroundingrdquo as an object Inthis process it is possible to define concepts and relation overthe domains To define 119862119897 and 119877119890119897 in other domains we needto come back to the first process choose ldquoMMI Ontologyrdquoand select candidates for selecting terms defined in ldquoMMIOntologyrdquo domain Then Figure 5 shows ldquoSystemrdquo sub 119862119897

6 International Journal of Distributed Sensor Networks

TermsSensorSensorGroundingOperationModelSupportshasOperationModel

Concept system

CSIRO sensor ontology

MMI ontology

SensorOnto

Sensor

System SensorGrounding

subclassOf Supports

System

String

Boolean

hasSerialNumber

isConsumable

Created ontology schema

Sensor

System

SensorGrounding

Boolean

String

Supports

subclassOf

1 Concept system selection 2 Candidate selection 3 Class and relation definition

4 Detailed class definition

ClassData type

RelationProperty

hasSerialNumber

isConsumable

middot middot middotmiddot middot middot

Figure 5 An example of the ontology building process

is also defined and ldquosubclassOfrdquo isin 119877119890119897 is defined betweenldquoSensorrdquo as a subject and ldquoSystemrdquo as an object

324 Detailed Class Definition In the final process119875 and119863119879are defined to decide properties of classes and additionally119862119897and 119877119890119897 are defined by the mapping model

Because ldquoSystemrdquo isin 119862119897was defined in the previous step itis given that ldquohasSerialNumberrdquo isin 119875 with ldquoStringrdquo isin 119863119879 andldquoisConsumablerdquo isin 119875 using ldquoBooleanrdquo isin 119863119879 in the final stepof Figure 5

4 Implementation

This section describes a metadata registry and CaSOBimplementation To make easy connection and mappingmodel we need to implement a metadata registry based onMDR specification The metadata registry is implementedby MySQL database which is a RDBMS (relational databasemanagement system) For testing we need to store datasets inthe metadata registry so we select several sensor ontologiesas the dataset Then we assume that the selected ontologiescontained common concepts so the datasets stored in themetadata registry also contain common concepts CaSOB isdeveloped inC for a user interface database connection andthe ontology building processes

41 A Metadata Registry Implementation The metadata reg-istry is implemented so the MDR metamodel could collect

Figure 6 Implementation of the concepts region

data directly as required to import the administered meta-data and create an ontology Thus we initially develop themetadata registry by implementing the metamodel of MDRSection 41 presents the MDR-based system structured byRDBMS

Each component in the metamodel is defined as RDBMStable while properties of each component are defined as tableattributes Moreover associations between components aredefined using foreign key referential integrity

Figure 6 shows the table and foreign key references of theconcepts region in MDR The ldquoConceptrdquo table includes theattributes ldquoconceptrdquo and ldquosourcerdquo ldquoconceptrdquo is an attributewhere the name held by the concept of MDR is expressedusing strings ldquosourcerdquo is an attribute that expresses a concept

International Journal of Distributed Sensor Networks 7

Figure 7 Implementation of the data description region

system including concepts using foreign key referencesMoreover the ldquoLinkrdquo table has a ldquorelationrdquo attribute for theldquoRelationrdquo tableThe ldquoLink Endrdquo table has the attributes ldquoendrdquoand ldquorolerdquo for the ldquolinkrdquo attribute where ldquoendrdquo means theconcept ldquorolerdquo means the relation role and ldquolinkrdquo means thelink Thus one link has at least two link ends

In Figure 7 the data description region is implemented astables and foreign key references Seven components in thedata description region inherit the concept in the conceptsregion so the components express the inheritance using eachof the attributes of ldquoconceptrdquo and ldquoconcept sourcerdquo held in theldquoConceptrdquo table

42 CaSOB Implementation In Section 42 the ontologybuilding process of CaSOB is presentedwith the implementa-tion screen which is based on the four processes of ontologycreation

421 Concept System Selection (Process 1) If the domainof the ontology to be created has been determined thesystem searches and selects the concept system (CS) of thecorresponding domain In Figure 8(a) CS of Process 1 isselected in the upper right corner of the screen as ldquoCSIROSensor Ontologyrdquo to create the sensor ontology

422 Candidate Selection (Process 2) The process selectseach candidate concept and each candidate link from theconcepts (C) and links (link) including the concept systemselected in Process 1 Type currently indicates the sevencomponents inheriting the concept

In Figure 8(a) ldquosupport Sensor (supportedBy) Sensor-Grounding (supports)rdquo is selected from links The selectedlink is added to candidate link and contained concepts

ldquoSensorrdquo and ldquoSensorGroundingrdquo are automatically added tocandidate concepts

423 Class and Relation Definition (Process 3) The processdefines the classes (119862119897) and relations (119877119890119897) of the ontologyschemamodel from the selected candidates A user selects thedesired candidate concept to define 119862119897 and selects candidatelinks to set the domain and range of Rel An 119877 including thecandidate link ismapped to a119877119890119897 of the ontologyThe domainand range are set during the selection of a candidate linkwith the roles of a subject and an object respectively A userselects each candidate to define the119862119897 and119877119890119897 of the ontologyschema model

In Figure 8(b) to define ldquoSystemrdquo isin 119862 in other do-mains ldquoMMI Ontologyrdquo isin 119862119878 is selected And ldquoSystemrdquois selected as candidate concepts and ldquoclass-subsumptionSensor (superclassOf) System (subclassOf)rdquo is selected ascandidate links The marked candidate link expresses ldquoclass-subsumptionrdquo which has (ldquoSensorrdquo ldquosubclassOfrdquo ldquoSystemrdquo)statement

424 Detailed Definition of Classes (Process 4) This processdefines classes (119862119897) and properties (119875) of the classes usingthe candidate concept and the type of concepts Additionalrelations (119877119890119897) are also created

In this process a user selects the candidate concepts Eachconcept has a type and has different mechanism to buildontologies according to the mapping model (119872119872) A userdefines119862119897 119875 119863119879 and additional 119877119890119897 of the ontology schemamodel When a candidate concept is selected the data thatcan be selected changes depending on its type so an ontologyis created containing the relations among components thatwere defined in the previous section

For example Figure 8(c) shows a screenshot of thedetailed definition of Cl in the ontology schema model Theselected candidate concept ldquoSystemrdquohas data element concept(DEC) type ldquohasSerialNumberrdquo isin 119875119903 becomes 119875 withldquoStringrdquo isin 119863119879 for ldquoSystemrdquo isin 119862119897 from ldquoSystem hasSerial-Number Stringrdquo isin 119863119864 associated with ldquoSystem hasSerial-numberrdquo isin 119863119864119862

425 The Created Ontology Figure 8(d) shows the completeontology for all processes The complete ontology is mainlycomprised of classes (119862119897) properties (119875) and relations (119877119890119897)P of each specific 119862119897 has a data type (119863119879) Rel has two 119862119897119904

with the roles of domain and rangeCaSOB provides a general ontology for a target ontology

It means that CaSOB does not provide specific ontologylanguages such as RDF OWL SKOS and Topic Map Thus auser needs to describe the complete ontology using a specificontology language Algorithm 1 shows the ontology createdin Figure 8(d) as described using OWL

5 Evaluation

51 Qualitative Evaluation We conducted a comparativeevaluation study for ontology creation This section first

8 International Journal of Distributed Sensor Networks

(a) (b)

(c) (d)

Figure 8 Screenshots of CaSOB

describes our qualitative evaluation using various com-parative items This evaluation involved the comparativeevaluation of three ontology building approaches which areuser-defined approach ontology reuse approach and ourproposedMDR based approach Table 1 shows the qualitativeevaluation results

The first factor for evaluation is standardization levelIt means whether the created ontology could be used as acommon or general ontology or not User-defined approachis hard to become a common standard approach because ofexperts who can create ontologies based on their own knowl-edge Hence created ontologies by user-defined approachcannot share their concept On the other hand since ontologyreuse approach and MDR based approach use ontologiesalready created which can contain common concepts cre-ated ontology using these ontology reuse and MDR basedapproaches can become standardized ontologies That is whyeach standardization level of these two approaches becomeshigh

The second evaluation factor is ontology quality Ontol-ogy quality means whether created ontologies are welldefined and whether the quality of created ontologies isguaranteed In case of user-defined approach a createdontology contains personal view point without general orcommon perspectiveTherefore the created ontology cannotguarantee the quality of ontologies CSIROMMI and ISTARontologies are popular ontologiesThese ontologies are one of

the results from each big projectThese ontologies are verifiedby a lot of experts whether concepts and relationships of theseontologies are well defined or not If we create a new ontologyreusing these well-defined ontologies we can guaranteesthe ontology quality In MDR based approach ontologiesand common concepts are controlled by MDR organizationsthat follow a standardized procedure for managing commonconcepts and reflect a standardized lifecycle for creatingontologies It means that the MDR-based ontology reuseapproach enables high-quality ontology creation

Limitation of expression means how the expressivepower is restricted when ontologies are created User-definedapproach has no limitation to express knowledge basedon ontologies because a user selects their own terms andthe user can make relationships following userrsquos opinionOntology reuse approach just uses existing ontologies It isnot allowed to change existing concepts and terms whenconcepts or terms are incorrect from target domainThus theexpression of ontology is very strict MDR based approachreuses registered ontologies in the metadata registry TheMDR based approach also permits changing other ontologieswhen there are no concepts or terms that are required inexisting ontologies Nevertheless the MDR approach is strictbecause it is not allowed to define unregistered ontologies

The final factor of qualitative evaluation is creation costCreation cost means convenience of creating ontologiesand time for building ontologies In user-defined approach

International Journal of Distributed Sensor Networks 9

ltxml version=ldquo10rdquogtltOntology xmlns=ldquohttpwwww3org200207owlrdquoxmlbase=ldquohttpsoftwarekoreaackrSwsysSensorOntologyowlrdquoxmlnsrdfs=ldquohttpwwww3org200001rdf-schemardquoxmlnsxsd=ldquohttpwwww3org2001XMLSchemardquoxmlnsrdf=ldquohttpwwww3org19990222-rdf-syntax-nsrdquoxmlnsxml=ldquohttpwwww3orgXML1998namespacerdquo

ltPrefix name=ldquoxsdrdquoIRI=ldquohttpwwww3org2001XMLSchemardquogt

ltPrefix name=ldquoowlrdquoIRI=ldquohttpwwww3org200207owlrdquogtltPrefix name=ldquordf rdquo IRI=ldquohttpwwww3org19990222-rdf-syntax-nsrdquogtltPrefix name=ldquordfsrdquo IRI=ldquohttpwwww3org200001rdf-schemardquogtltDeclarationgt

ltClass IRI=ldquoPhysicalQualityrdquogtltClass IRI=ldquoSensorrdquogtltClass IRI=ldquoSensorGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogtltClass IRI=ldquoSystemrdquogtltObjectProperty IRI=ldquosubclassOfrdquogtltObjectProperty IRI=ldquomeasurerdquogtltObjectProperty IRI=ldquomodelGroundingrdquogtltObjectProperty IRI=ldquosupportsrdquogtltDataProperty IRI=ldquoisConsumablerdquogtltDataProperty IRI=ldquohasSerialNumberrdquogt

ltDeclarationgtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSystemrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingtltObjectProperty IRI=ldquomeasurerdquogt

ltClass IRI=ldquoSensorrdquogtltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomeasurerdquogtltClass IRI=ldquoPhysicalQualityrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquoisConsumablerdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingt

Algorithm 1 Continued

10 International Journal of Distributed Sensor Networks

ltDataPropertyRangegtltDataProperty IRI=ldquoisConsumablerdquogtltDatatype abbreviatedIRI=ldquoxsdbooleanrdquogt

ltDataPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingtltDataPropertyRangegt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltDatatype abbreviatedIRI=ldquoxsdstringrdquogt

ltDataPropertyRangegtltOntologygt

Algorithm 1 An ontology described using OWL

Table 1 Qualitative evaluation of ontology building approaches

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

experts directly define concepts and terms and it requireshigh cost to survey domain knowledge and collect referencedocuments for verification Ontology reuse approach usesexisting ontologies without change if the existing ontologiescoincide with concepts and terms in target domainThus thecost for ontology creation is low MDR based approach usesontologies registered in ametadata registryWhen ontologiesare created users need to search terms and their relationsto apply the search result to new ontologies Users also needa customization task to create link between domains andranges Although this approach requires medium cost whichis higher cost than the cost of ontology reuse approachthe cost of MDR approach is lower than user-definedapproach

52 Quantitative Evaluation Simulation Approach This sec-tion describes our quantitative analysis which clearly showsthe advantages of the proposed system CaSOB Many sys-tems and studies have addressed interoperability betweenontologies However most focus on interoperability issueamong ontologies which have already been created withtheir own ontology schema definition rules Our approach isimplemented in the step before ontology creation which aimsto reuse common concepts and increase interoperabilityThispaper defines existing approaches as user-defined ontologyschema creation methods and we conducted a quantitativeevaluation to compare our method with the user-definedschema creationmethodThemetadata registry also providesno schema creation method because its purpose is to registerand share ontologies In other words our proposed method

CaSOB is based on the MDR but the metadata registry isexcluded from the quantitative evaluation

An appropriate comparative item was determined forthe evaluation The goal of this paper is to minimize thesemantic heterogeneity of ontologies via the reuse of commonconceptsTherefore this paper conducted a quantitative eval-uation of the semantic heterogeneity rate We can estimatethe approximate ontology integration cost using the semanticheterogeneity rate so this paper also includes the ontologyintegration cost as a comparative item

The evaluation methodology is summarized as follows

(i) comparative targets our proposed method CaSOBand the user-defined ontology schema creationmethod

(ii) comparative items the semantic heterogeneity ratethat is the number of heterogeneous semantics(concepts) shared among the created ontologies theontology integration cost that is the cost required tointegrate a set of created ontologies

The key symbols and notations are defined as follows

(i) 119874 a set of ontologies created with a target method119874 = 1199001 1199002 1199003 119900119899

(ii) 119900119894 a created ontology consisting of one or moresemantics that is a set of concepts such as classesrelations properties and data types

(iii) 119862 a set of common concepts registered and used forcreating an ontology

International Journal of Distributed Sensor Networks 11N

umbe

r of h

eter

ogen

eous

conc

epts

Case-1 the proposal is the almost worst case Case-2 the proposal is the average case

Case-3 the proposal is the almost best case

0100020003000400050006000700080009000

10000

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000N

umbe

r of h

eter

ogen

eous

conc

epts

0100020003000400050006000700080009000

10000Case-4 the proposal is from the almost best to the average⟩⟩⟩⟩

⟩⟩ ⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 9 Comparative evaluation results for the number of semantic heterogeneities

(iv) 119867119890119862119894 a set of heterogeneous concepts in the 119894th

ontology among the created ontologies(v) 119867119900119862 a set of homogeneous concepts among the

created ontologies(vi) 119899(119874) the number of created ontologies(vii) 119899(119900

119894) the number of concepts in the 119894th ontology

(viii) 119899(119862) the number of common concepts used to createan ontology

(ix) 119899(119867119890119862119894) the number of heterogeneous concepts inthe 119894th ontology

(x) 119903(119867119900119862) the average ratio of homogeneous concepts(xi) 119903(119862) the average ratio of used common concepts(xii) 119905 semantic interpretation time between two concepts

0 lt 119905 lt 1(xiii) 119878119867119873 the number of heterogeneous concepts(xiv) 119874119868119862 the ontology integration cost

For the evaluation we assume that 119899-people generate anontology in the same domain In this case the homogeneousconcept means concepts which are commonly contained bymost of the ontologies For example the concept such assensor could be a homogeneous concept even though eachof the sensor ontologies is developed by different people Onthe other hand the heterogeneous concept means discordantconcepts with each of the ontologies We assume that thenumber of heterogeneous concepts is the number of totalconcepts without an average ratio of homogeneous concepts

Figure 9 shows the comparative evaluation result for thesemantic heterogeneity as 119878119867119873 The evaluation determinesthe variation in the number of heterogeneous conceptsdepending on the change in the ratio of homogeneousconcepts and the ratio of used common concepts

119878119867119873119901119903119900119901119900119904119886119897

considers the common concepts used tobuild an ontology In other words it is the result of an evalua-tion using our proposedmethod 119878119867119873

119901119903119890V119894119900119906119904 is an evaluationresult using a user-defined schema creation method

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

2 International Journal of Distributed Sensor Networks

to modify the existing ontology or add a new ontologyThe modification and addition of ontologies cause anotherheterogeneity problem at conceptual (ontology schema) level[7 8] In other words when we build a new ontology or reuseexisting ontologies for adoption in other domains or for otherpurposes we would customize the existing sensor ontologies[9] It causes another semantic inconsistency between sensorontologies

This paper presents a method for sensor ontology man-agement and reuse based ISOIEC 11179 Metadata Registry(MDR) 3rd Edition for resolving the semantic heterogeneityissue aforementioned MDR is an international standardwhich has been revised for ontology management and pub-lished in 2013 A metadata registry based on MDR canmanage metadata and the relations among them [10ndash15]Ontologies also are registered and managed in the metadataregistry An MDR instance manages common concepts fromthe registered ontologies and thus it ensures that ontologiesare defined well and reusable by diverse systems Reusingcommon concepts for building ontology enhances the ontol-ogy quality and semantic interoperability between sensornetworks MDR provides only the structure of registrationand the administration of an ontology but it does not supportthe ontology creation facility for reusing common conceptsTherefore this paper proposes a new framework for ontologymanagement and building based on MDR and the proposedframework is named CaSOB (Canonical Sensor OntologyBuilder) In addition this paper considers a triple statementas an ontologyThe reason is that various ontology languagessuch as OWL and RDF are formed by the triple and most ofthe ontology stores and reasoning engines are based on thetriple

This paper is organized as follows In Section 2 weintroduce previous researches into solutions to the semanticheterogeneity problem of sensor ontologies In Section 3 weexplain the CaSOB framework a mapping model and ontol-ogy building processes Our implementation is described inSection 4 while Section 5 presents the evaluation Finally weconclude this paper and discuss future work in Section 6

2 Semantic Heterogeneity Problem ofSensor Ontologies

Much research on ontologies has been directed at increasinginteroperability and solving the semantic heterogeneity prob-lem among various systems An ontologymatching techniquewas proposed for semantic interchange among peers inOpen Network Systems [16] Castano et al [17] describe analgorithm that matched ontologies using a linguistic andcontextual matchingmodel for OpenNetwork Systems Pirroet al [18] propose a similarity checking method based onWordNet for building semantic links in a peer-to-peer net-work Bakillah and Mostafavi [19] also propose an ontologymatching method based on lexical relations and mappingrules for improving the interoperability of distributed geospa-tial web services

Ontology matching methods ensure that ontology con-cepts connect together and correspond semantically after

ontologies are generated These methods can match numer-ous ontologies automatically and semiautomatically butthey can experience problems in terms of high cost andinaccuracy Therefore research on ontology sharing andreuse is required because these techniques can solve thesemantic heterogeneity problem by creating ontologies basedon common concepts Matuszek et al [20] propose a systemfor defining and reusing the common concepts while Biebowand Szulman [21] proposed ontology buildingmethods basedon terminology from a linguistic perspective

In the Semantic Sensor Web various sensor ontologieshave been developed such as CSIRO [22] MMI [23] andISTAR [24] Each of the ontologies is suitable for representinginformation of sensors and devices and exchanging theinformation between relevant services only in the samesensor network environment However the ontology cannotbe available for the environment where we would develop anew sensor network system for other application domains orwith other purposes

Compton et al [25] introduces various sensor ontologiesfrom researches and projects in various domains and com-pares the corresponding domain purposes and features ofeach of the ontologies Especially Compton et al evaluatesthe expressive power of the sensor ontologies from the per-spectives of sensor device information physical propertiesobservation quality and domain concepts

The CSIRO sensor ontology [26] is designed for a genericdomain and is intended to be used in data integration searchclassification and workflows The CSIRO sensor ontologyprovides the high expressive power in sensor physicalnessand observation perspectives However the CSIRO ontologydoes not provide concepts like sampled medium and time

MMI (Marine Metadata Interoperability) [27] aims toincrease interoperability for oceanographic devices sensorand sampler The MMI device ontology has been developedfor devices and sensors in ocean environment but irre-spective concepts such as sensor hierarchy history locationpower supply a field of view unit of measure and time havenot been defined for oceanographic devices sensors andsamplers

The ISTAR ontology [28] has the purpose for taskassignment and has been developed as part of a system toautomatically select sensors for tasks based on their fitnessfor the task description However ISTAR has only conceptsabout sensors and physical features for the task assignmentand does not consider concepts about observation anddomain

As a result the previous approaches related to the sensorontology do not provide a canonical sensor ontology conceptmanagement and building facility and thus an additionalheterogeneity issue continuously arises It causes many otherproblems and is a barrier for seamless sensor semanticsinterpretation progressive and systematic semanticsmanage-ment common concept reusability and so on For addressingthose problems this paper proposes a new sensor ontologymanagement and building framework based on MDR Thegoal of the framework proposed in this paper is to enable thecanonical management and reuse of the existing well-definedontology

International Journal of Distributed Sensor Networks 3

3 The CaSOB Framework

Figure 1 shows the CaSOB framework CaSOB contains fourprocesses (Section 32) and it creates an ontology using amapping model from MDR (Section 31) Various conceptsare registered in ametadata registry for sharing and reusing ascommon concepts Therefore the mapping model is definedusing components in regions related by common conceptsand data representations including concepts region and datadescription region from several areas of MDR As a resultontology is built as an ontology according to ontology schemamodel so this paper considers only the schema level ofontology and it excludes the instance level

31 Mapping Model

311 Preliminary Definition MDR supports the registrationand administration of common concepts And it specifiesa metamodel for the registration and administration ofcommon concepts as an MDR specification There are sevenmain regions These regions are classified as regions that reg-ister and administer concepts regions that name and defineconcepts regions that represent the relations among conceptsand components and regions that specifically describe dataIn this paper we formally define the MDR model for tworegions that is the concepts region and data descriptionregion

Definition 1 (MDR concepts model) The MDR conceptsmodel is a six-tuple

MDR119862

= (119862119878 119862 119877 119877119877 119871119864 119897119894119899119896) (1)

where one has the following(i) 119862119878 is a set of concept systems A concept system rep-

resents a domain of concepts such as an applicationdomain or knowledge domain

(ii) 119862 is a set of concepts A concept is a unit of knowledgecreated by a unique combination of characteristicsSome tuples of the MDR concepts model and theMDR data descriptionmodel inherit119862 as a basic unit

(iii) 119877 is a set of relations A relation is a concept thatrepresents the association among concepts

(iv) 119877119877 is a set of relation roles A relation role is a role ofa concept associated with a specific relation

(v) 119871119864 is a set of link ends A link end is a pair of aconcept and a relation role as one side of 119897119894119899119896 and LEis expressed by ⟨119888 and 119903119903⟩ where 119888 isin 119862 and 119903119903 isin 119877119877

(vi) 119897119894119899119896 119877 rarr 119871119864 times 119871119864 represents the linkage of twolink ends which are associated with a relation In thispaper one focuses generation of a triple statement asontology so a binary relation is only considered

The MDR concepts model defines all the conceptsand relations administered in MDR As an exampleFigure 2 shows that the MDR concepts model contains119897119894119899119896ldquoclass-subsumptionrdquo (ltldquoSensor ldquosuperclassOfrdquogt ltldquoSystemrdquoldquosubclassOfrdquogt) where ldquoSensorrdquo ldquoSystemrdquo isin 119862 ldquoclass-subsumptionrdquo isin119877 and ldquosuperclassOfrdquo ldquosubclassOfrdquoisin119877119877

Definition 2 (MDR data description model) The MDR datadescription model is an eight-tuple

MDR119863= (119862119863119881119872119881119863119874119862 119875119903 119863119864119862119863119864119863119894119898) (2)

where one has the following

(i) 119862119863 is a set of conceptual domains A conceptualdomain is a domain wherein data element conceptscould have a shared conceptual level A conceptualdomain is also used to represent a set of valuemeanings (119881119872)

(ii) 119881119872 is a set of value meanings A value meaning is ageneral meaning of actual values

(iii) 119881119863 is a set of value domains A value domain is adomain in the actual data level which represents theactual values such as a data type

(iv) 119874119862 is a set of object classes An object class is a generalconcept that can capture many instances

(v) 119875119903 is a set of properties A property is an attribute ofobjects or concepts

(vi) 119863119864119862 is a set of data element concepts A data elementconcept is a pair of a concept and a data elementAnd 119863119864119862 is expressed by ⟨119900119888 119901119903⟩ where 119900119888 isin

119874119862 and 119901119903 isin 119875119903(vii) 119863119864 sube 119863119864119862 times 119881119863 is a set of data elements The data

element is the basic unit of data for MDR(viii) 119863119894119898 is a set of dimensionalities A dimensionality

is an aggregation of the units of measures which isrelated to a conceptual domain for example lengthheight or weight

An ontology contains components that depend on thelanguage and the description method In this paper wefocused on building ontologies to improve interoperabilityamong various applications or systems so we concentratedon building ontology in schema level rather than instance orindividual level

Definition 3 (ontology schemamodel) The ontology schemamodel is a six-tuple

119874119899119905119900 = (119862119897 119875 119877119890119897 119863119879 119903119890119897119886119905119894119900119899 119901119903119900119901) (3)

where one has the following

(i) 119862119897 is a set of classes A class is a concept that groupsitems sharing the same characteristics Commoncharacteristics are described logically

(ii) 119875 is a set of properties A property indicates thecharacteristics of a class In the ontology schemamodel a property is described by connecting a classto a data type

(iii) 119877119890119897 is a set of relations in an ontology domainA relation in an ontology domain describes thecharacteristics existing among classes A relation isdescribed by connecting one class to another class

4 International Journal of Distributed Sensor Networks

Metadata registry

Ontology schemaMapping model

Mapping model Mapping model

Ontology building process

3 Class and relation 4 Detailed class definition1 Concept system selection 2 Candidate selectiondefinition

de_name reg_statusKorea01 SubmittedKorea02 Recorded

Korea02

Reg_statusSubmittedRecorded

Reg_statusSubmittedRecordedKorea02

reg_statusSubmittedRecordedKorea02

Korea02 middot middot middotKorea02 middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middotmiddot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middotde_nameKorea01Korea02Korea02 middot middot

de_nameKorea01Korea02Korea02

de_nameKorea01Korea02Korea02

with RuleC with RoleD

Figure 1 The CaSOB framework

Concepts region

Sensor

System

superclassOf

subclassOf

Link Class-subsumption

RR

RR

R

C

C

LE

LE

Figure 2 An example of the MDR concepts model

(iv) 119863119879 is a set of data types A data type is a type of valuegiven to a class property

(v) 119903119890119897119886119905119894119900119899119877119890119897 rarr 119862119897times119862119897 is a triple statement expressedby (119888119897

1 119903119890119897 119888119897

2) where 119888119897

1 1198881198972 isin 119862119897 and 119903119890119897 isin 119877119890119897

such as an object property of OWL

(vi) 119901119903119900119901 119875 rarr 119862119897 times 119863119879 is a triple statement expressedby (119888119897 119901 119889119905) where 119888119897 isin 119862119897 119901 isin 119875 and 119889119905 isin 119863119879 suchas a data type property of OWL

312 CaSOB Mapping Model The CaSOB mapping modeldefines the mapping rules based on the MDR models forthe ontology schema model as shown in the preliminarydefinition provided in Section 311 Data mapped by theCaSOB mapping model is used to build an ontology

Definition 4 (mapping model) The mapping model is a two-tuple

119872119872 = (119877119906119897119890119862 119877119906119897119890

119863) (4)

where one has the following

(i) 119877119906119897119890119862is a set of rules connecting the MDR concepts

model with the ontology schema model 119877119906119897119890119862has

three rules as follows

(a) 119862 rarr 119862119897(b) 119877119877 rarr 119877119890119897(c) 119897119894119899119896 rarr 119903119890119897119886119905119894119900119899 that is 119897119894119899119896

119903(⟨1198881 1199031199031⟩

⟨1198882 1199031199032⟩) rarr 119903119890119897119886119905119894119900119899

1199031199032(1198881198971 1198881198972) or 119903119890119897119886119905119894119900119899

1199031199031

(1198881198972 1198881198971) where 119903 rarr 119903119890119897 119888

1rarr 119888119897

1 and

1198882rarr 1198881198972with 119903 isin 119877 119888

1 1198882 isin 119862 119903119903

1 1199031199032 isin

119877119877 119903119890119897 isin 119877119890119897 and 1198881198971 1198881198972 isin 119862119897

(ii) 119877119906119897119890119863

is a set of rules connecting the MDR datadescription model and the ontology schema model119877119906119897119890119863has eight rules as follows

(a) 119862119863 rarr 119862119897(b) 119881119872 rarr 119862119897(c) 119863119894119898 rarr 119862119897(d) 119874119862 rarr 119862119897(e) 119875119903 rarr 119875(f) 119881119863 rarr 119863119879(g) 119863119864119862 rarr 119862119897 times 119875(h) 119863119864 rarr 119901119903119900119901 that is (⟨119900119888 119888ℎ⟩ V119889) rarr 119901119903119900119901

119901

(119888119897 119889119905) where 119900119888 rarr 119888119897 119901119903 rarr 119901 and V119889 rarr

119889119905 with 119889119890 isin 119863119864 119900119888 isin 119874119862 119901119903 isin 119875119903 V119889 isin 119881119863119901 isin 119875 119888119897 isin 119862119897 and 119889119905 isin 119863119879

For 119877119906119897119890119862 C is specialized in 119862119863 119863119864 119874119862 and so forthin an MDR data description region so 119862 is mapped to 119862119897Due to the fact that 119877 is an undirected relation and 119877119877 hasdirection 119877119877 is mapped to 119877119890119897 And link has the same tuple119871119864 and relation also has the same tuple 119862119897 hence there aretwo types of results when 119897119894119899119896 is mapped into 119903119890119897119886119905119894119900119899 whichdepends on 119877119877 This is because the ontology schema modelexpresses the ontology as a triple statement with a directionsuch as (subject predicate object) However the 119897119894119899119896 is able

International Journal of Distributed Sensor Networks 5

sensor

system

superclassOf

MDR concepts model Ontology schema model

subclassOfsystem

sensor

subclassOf

(2)

system

sensor

superclassOf

(1)

Class-subsumption

Rel

RelRR

RR

R

C

C

Cl

Cl Cl

Cl

Figure 3 The expected mapping results with 119877119906119897119890119862

MDR data description model Ontology schema model

system

string

hasSerialNumberhasSerialNumber

DE

DEC

Pr

VD

system

string

Cl

DT

P

OC

Figure 4 A mapping example using 119877119906119897119890119863

to map two 119903119890119897119886119905119894119900119899119904 by 119877119877 Thus a user needs to select asubject and an object when CaSOB uses rule (c) in 119877119906119897119890

119862

For example Figure 3 shows two expected mappingresults (1) and (2) where 119897119894119899119896 has two 119871119864119904 that islt ldquoSensorrdquo ldquosuperclassOfrdquo gt lt ldquoSystemrdquo ldquosubclassof rdquo gtisin 119871119864 whereas the mapping model cannot automaticallydetermine which 119871119864 becomes a subject or an object in119903119890119897119886119905119894119900119899 of the ontology schema model Thus a user needs toselect the subject and object of 119903119890119897119886119905119894119900119899 Because the subclassis typically more used than superclass in ontology languagethe user could select (1) as the mapping result expressed by119903119890119897119886119905119894119900119899subclassOf (ldquoSensorrdquo ldquoSystemrdquo)

The MDR data description model specifically describesthe meaning of metadata and provides an explanation ofthe concepts defined in the MDR concepts model Thesix tuples of the MDR data description model that is119862119863 119863119864119862 119874119862 119875119903 119881119872 and 119863119894119898 are inherited by 119862 in theMDR concepts model 119862 is expressed differently dependingon the property of the inherited tuples Thus each tupleis mapped to 119862119897 119875 or 119863119879 while most of the ontologiesmapped by RuleD are triple statements such as (119862119897 119875 and119863119879) 119862119863 119874119862 119881119872 and 119863119894119898 are only mapped to 119862119897 in thesix tuples because they are entities which are connected byother classes 119881119863 is mapped to 119863119879 although 119881119863 does notmean data type However 119881119863 contains a data type insideand 119863119864 contains 119881119863 not a data type directly Also if 119881119863 ismapped to 119863119879 we can define some special data types like 2-alpha country code 119875119903 is mapped to 119875 because 119875119903 indicatesan attribute of classes 119863119864119862 contains 119874119862 and 119875119903 so 119863119864119862 is

mapped to 119862119897 and 119875 both Similarly 119863119864 contains 119863119864119862 and119881119863 so119863119864 could be mapped to (119862119897 119875 119863119879) statement

Figure 4 shows a mapping example for 119877119906119897119890119863 The MDR

data description model expresses 119863119864 as ldquoSystem hasSerial-Numberrdquo with a ldquoStringrdquo data type where ldquoSystemrdquo isin 119874119862ldquohasSerialNumberrdquo isin 119875119903 ltldquoSystemrdquo ldquohasSerialNumberrdquogtisin 119863119864119862 and ldquoStringrdquo isin 119881119863 As a result the ontology schemamodel constructs a (ldquoSystemrdquo ldquohasSerialNumberrdquo ldquoStringrdquo)statement where ldquoSystem10158401015840 isin 119862119897 ldquohasSerialNumberrdquo isin P andldquoStringrdquo isin 119863119879

32 Ontology Building Process

321 Concept System Selection The first process for buildingontology is to decide a domain of an ontology If domains aredifferent from each other ontology meanings and relationsare different even if they have the same terminology Aconcept system includes the domain and scope of the dataThus CaSOB determines the domain of an ontology byselecting a concept system from 119862119878

In the first process shown in Figure 5 the concept systemldquoCSIRO Sensor Ontologyrdquo in 119862119878 is selected if a user wants tobuild an ontology in a sensor domain defined by CSIRO

322 Candidate Selection In the candidate selection processcandidates are selected to build an ontology Tuples of theMDR concepts model such as119862 119877 and 119897119894119899119896may be selectedas candidates The candidates are the same as the set of termsused when ontologies are created

119862 and link are selected from 119862119878 as candidate 119862 andcandidate 119897119894119899119896 respectively 119897119894119899119896 contains119862 119877 119877119877 and 119871119864 soboth candidate119862 and candidate 119897119894119899119896 can be selected from one119897119894119899119896 The selected 119897119894119899119896 becomes candidate 119897119894119899119896 119862 included in119897119894119899119896 is automatically selected as candidate 119862

The concept system ldquoCSIRO Sensor Ontologyrdquo is selectedduring the first step of Figure 5 The next step is to select theterms contained at the domain Candidates are selected suchas ldquoSensorrdquo ldquoSensorGroundingrdquo and ldquosupportsrdquo

323 Class and Relation Definition In the third process 119862119897and 119877119890119897 of the ontology schema model are defined by thecandidates A set of candidate concepts is defined for119862119897 whilea set of candidate links is defined for 119877119890119897

However CaSOB does not know the difference of 119877119877 for119862 such as the ldquoSubjectrdquo and ldquoObjectrdquo in an actual system Itis difficult to automatically determine roles simply by usingcandidate 119897119894119899119896 Thus a user has to determine the subject andobject of 119903119890119897119886119905119894119900119899 in the ontology schema model

In the third step shown in Figure 5119862119897 and119877119890119897 are definedusing the selected terms ldquoSensorrdquo ldquoSensorGroundingrdquo sub

119862119897 are defined while ldquosupportsrdquo isin 119877119890119897 is defined betweenldquoSensorrdquo as a subject and ldquoSensorGroundingrdquo as an object Inthis process it is possible to define concepts and relation overthe domains To define 119862119897 and 119877119890119897 in other domains we needto come back to the first process choose ldquoMMI Ontologyrdquoand select candidates for selecting terms defined in ldquoMMIOntologyrdquo domain Then Figure 5 shows ldquoSystemrdquo sub 119862119897

6 International Journal of Distributed Sensor Networks

TermsSensorSensorGroundingOperationModelSupportshasOperationModel

Concept system

CSIRO sensor ontology

MMI ontology

SensorOnto

Sensor

System SensorGrounding

subclassOf Supports

System

String

Boolean

hasSerialNumber

isConsumable

Created ontology schema

Sensor

System

SensorGrounding

Boolean

String

Supports

subclassOf

1 Concept system selection 2 Candidate selection 3 Class and relation definition

4 Detailed class definition

ClassData type

RelationProperty

hasSerialNumber

isConsumable

middot middot middotmiddot middot middot

Figure 5 An example of the ontology building process

is also defined and ldquosubclassOfrdquo isin 119877119890119897 is defined betweenldquoSensorrdquo as a subject and ldquoSystemrdquo as an object

324 Detailed Class Definition In the final process119875 and119863119879are defined to decide properties of classes and additionally119862119897and 119877119890119897 are defined by the mapping model

Because ldquoSystemrdquo isin 119862119897was defined in the previous step itis given that ldquohasSerialNumberrdquo isin 119875 with ldquoStringrdquo isin 119863119879 andldquoisConsumablerdquo isin 119875 using ldquoBooleanrdquo isin 119863119879 in the final stepof Figure 5

4 Implementation

This section describes a metadata registry and CaSOBimplementation To make easy connection and mappingmodel we need to implement a metadata registry based onMDR specification The metadata registry is implementedby MySQL database which is a RDBMS (relational databasemanagement system) For testing we need to store datasets inthe metadata registry so we select several sensor ontologiesas the dataset Then we assume that the selected ontologiescontained common concepts so the datasets stored in themetadata registry also contain common concepts CaSOB isdeveloped inC for a user interface database connection andthe ontology building processes

41 A Metadata Registry Implementation The metadata reg-istry is implemented so the MDR metamodel could collect

Figure 6 Implementation of the concepts region

data directly as required to import the administered meta-data and create an ontology Thus we initially develop themetadata registry by implementing the metamodel of MDRSection 41 presents the MDR-based system structured byRDBMS

Each component in the metamodel is defined as RDBMStable while properties of each component are defined as tableattributes Moreover associations between components aredefined using foreign key referential integrity

Figure 6 shows the table and foreign key references of theconcepts region in MDR The ldquoConceptrdquo table includes theattributes ldquoconceptrdquo and ldquosourcerdquo ldquoconceptrdquo is an attributewhere the name held by the concept of MDR is expressedusing strings ldquosourcerdquo is an attribute that expresses a concept

International Journal of Distributed Sensor Networks 7

Figure 7 Implementation of the data description region

system including concepts using foreign key referencesMoreover the ldquoLinkrdquo table has a ldquorelationrdquo attribute for theldquoRelationrdquo tableThe ldquoLink Endrdquo table has the attributes ldquoendrdquoand ldquorolerdquo for the ldquolinkrdquo attribute where ldquoendrdquo means theconcept ldquorolerdquo means the relation role and ldquolinkrdquo means thelink Thus one link has at least two link ends

In Figure 7 the data description region is implemented astables and foreign key references Seven components in thedata description region inherit the concept in the conceptsregion so the components express the inheritance using eachof the attributes of ldquoconceptrdquo and ldquoconcept sourcerdquo held in theldquoConceptrdquo table

42 CaSOB Implementation In Section 42 the ontologybuilding process of CaSOB is presentedwith the implementa-tion screen which is based on the four processes of ontologycreation

421 Concept System Selection (Process 1) If the domainof the ontology to be created has been determined thesystem searches and selects the concept system (CS) of thecorresponding domain In Figure 8(a) CS of Process 1 isselected in the upper right corner of the screen as ldquoCSIROSensor Ontologyrdquo to create the sensor ontology

422 Candidate Selection (Process 2) The process selectseach candidate concept and each candidate link from theconcepts (C) and links (link) including the concept systemselected in Process 1 Type currently indicates the sevencomponents inheriting the concept

In Figure 8(a) ldquosupport Sensor (supportedBy) Sensor-Grounding (supports)rdquo is selected from links The selectedlink is added to candidate link and contained concepts

ldquoSensorrdquo and ldquoSensorGroundingrdquo are automatically added tocandidate concepts

423 Class and Relation Definition (Process 3) The processdefines the classes (119862119897) and relations (119877119890119897) of the ontologyschemamodel from the selected candidates A user selects thedesired candidate concept to define 119862119897 and selects candidatelinks to set the domain and range of Rel An 119877 including thecandidate link ismapped to a119877119890119897 of the ontologyThe domainand range are set during the selection of a candidate linkwith the roles of a subject and an object respectively A userselects each candidate to define the119862119897 and119877119890119897 of the ontologyschema model

In Figure 8(b) to define ldquoSystemrdquo isin 119862 in other do-mains ldquoMMI Ontologyrdquo isin 119862119878 is selected And ldquoSystemrdquois selected as candidate concepts and ldquoclass-subsumptionSensor (superclassOf) System (subclassOf)rdquo is selected ascandidate links The marked candidate link expresses ldquoclass-subsumptionrdquo which has (ldquoSensorrdquo ldquosubclassOfrdquo ldquoSystemrdquo)statement

424 Detailed Definition of Classes (Process 4) This processdefines classes (119862119897) and properties (119875) of the classes usingthe candidate concept and the type of concepts Additionalrelations (119877119890119897) are also created

In this process a user selects the candidate concepts Eachconcept has a type and has different mechanism to buildontologies according to the mapping model (119872119872) A userdefines119862119897 119875 119863119879 and additional 119877119890119897 of the ontology schemamodel When a candidate concept is selected the data thatcan be selected changes depending on its type so an ontologyis created containing the relations among components thatwere defined in the previous section

For example Figure 8(c) shows a screenshot of thedetailed definition of Cl in the ontology schema model Theselected candidate concept ldquoSystemrdquohas data element concept(DEC) type ldquohasSerialNumberrdquo isin 119875119903 becomes 119875 withldquoStringrdquo isin 119863119879 for ldquoSystemrdquo isin 119862119897 from ldquoSystem hasSerial-Number Stringrdquo isin 119863119864 associated with ldquoSystem hasSerial-numberrdquo isin 119863119864119862

425 The Created Ontology Figure 8(d) shows the completeontology for all processes The complete ontology is mainlycomprised of classes (119862119897) properties (119875) and relations (119877119890119897)P of each specific 119862119897 has a data type (119863119879) Rel has two 119862119897119904

with the roles of domain and rangeCaSOB provides a general ontology for a target ontology

It means that CaSOB does not provide specific ontologylanguages such as RDF OWL SKOS and Topic Map Thus auser needs to describe the complete ontology using a specificontology language Algorithm 1 shows the ontology createdin Figure 8(d) as described using OWL

5 Evaluation

51 Qualitative Evaluation We conducted a comparativeevaluation study for ontology creation This section first

8 International Journal of Distributed Sensor Networks

(a) (b)

(c) (d)

Figure 8 Screenshots of CaSOB

describes our qualitative evaluation using various com-parative items This evaluation involved the comparativeevaluation of three ontology building approaches which areuser-defined approach ontology reuse approach and ourproposedMDR based approach Table 1 shows the qualitativeevaluation results

The first factor for evaluation is standardization levelIt means whether the created ontology could be used as acommon or general ontology or not User-defined approachis hard to become a common standard approach because ofexperts who can create ontologies based on their own knowl-edge Hence created ontologies by user-defined approachcannot share their concept On the other hand since ontologyreuse approach and MDR based approach use ontologiesalready created which can contain common concepts cre-ated ontology using these ontology reuse and MDR basedapproaches can become standardized ontologies That is whyeach standardization level of these two approaches becomeshigh

The second evaluation factor is ontology quality Ontol-ogy quality means whether created ontologies are welldefined and whether the quality of created ontologies isguaranteed In case of user-defined approach a createdontology contains personal view point without general orcommon perspectiveTherefore the created ontology cannotguarantee the quality of ontologies CSIROMMI and ISTARontologies are popular ontologiesThese ontologies are one of

the results from each big projectThese ontologies are verifiedby a lot of experts whether concepts and relationships of theseontologies are well defined or not If we create a new ontologyreusing these well-defined ontologies we can guaranteesthe ontology quality In MDR based approach ontologiesand common concepts are controlled by MDR organizationsthat follow a standardized procedure for managing commonconcepts and reflect a standardized lifecycle for creatingontologies It means that the MDR-based ontology reuseapproach enables high-quality ontology creation

Limitation of expression means how the expressivepower is restricted when ontologies are created User-definedapproach has no limitation to express knowledge basedon ontologies because a user selects their own terms andthe user can make relationships following userrsquos opinionOntology reuse approach just uses existing ontologies It isnot allowed to change existing concepts and terms whenconcepts or terms are incorrect from target domainThus theexpression of ontology is very strict MDR based approachreuses registered ontologies in the metadata registry TheMDR based approach also permits changing other ontologieswhen there are no concepts or terms that are required inexisting ontologies Nevertheless the MDR approach is strictbecause it is not allowed to define unregistered ontologies

The final factor of qualitative evaluation is creation costCreation cost means convenience of creating ontologiesand time for building ontologies In user-defined approach

International Journal of Distributed Sensor Networks 9

ltxml version=ldquo10rdquogtltOntology xmlns=ldquohttpwwww3org200207owlrdquoxmlbase=ldquohttpsoftwarekoreaackrSwsysSensorOntologyowlrdquoxmlnsrdfs=ldquohttpwwww3org200001rdf-schemardquoxmlnsxsd=ldquohttpwwww3org2001XMLSchemardquoxmlnsrdf=ldquohttpwwww3org19990222-rdf-syntax-nsrdquoxmlnsxml=ldquohttpwwww3orgXML1998namespacerdquo

ltPrefix name=ldquoxsdrdquoIRI=ldquohttpwwww3org2001XMLSchemardquogt

ltPrefix name=ldquoowlrdquoIRI=ldquohttpwwww3org200207owlrdquogtltPrefix name=ldquordf rdquo IRI=ldquohttpwwww3org19990222-rdf-syntax-nsrdquogtltPrefix name=ldquordfsrdquo IRI=ldquohttpwwww3org200001rdf-schemardquogtltDeclarationgt

ltClass IRI=ldquoPhysicalQualityrdquogtltClass IRI=ldquoSensorrdquogtltClass IRI=ldquoSensorGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogtltClass IRI=ldquoSystemrdquogtltObjectProperty IRI=ldquosubclassOfrdquogtltObjectProperty IRI=ldquomeasurerdquogtltObjectProperty IRI=ldquomodelGroundingrdquogtltObjectProperty IRI=ldquosupportsrdquogtltDataProperty IRI=ldquoisConsumablerdquogtltDataProperty IRI=ldquohasSerialNumberrdquogt

ltDeclarationgtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSystemrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingtltObjectProperty IRI=ldquomeasurerdquogt

ltClass IRI=ldquoSensorrdquogtltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomeasurerdquogtltClass IRI=ldquoPhysicalQualityrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquoisConsumablerdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingt

Algorithm 1 Continued

10 International Journal of Distributed Sensor Networks

ltDataPropertyRangegtltDataProperty IRI=ldquoisConsumablerdquogtltDatatype abbreviatedIRI=ldquoxsdbooleanrdquogt

ltDataPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingtltDataPropertyRangegt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltDatatype abbreviatedIRI=ldquoxsdstringrdquogt

ltDataPropertyRangegtltOntologygt

Algorithm 1 An ontology described using OWL

Table 1 Qualitative evaluation of ontology building approaches

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

experts directly define concepts and terms and it requireshigh cost to survey domain knowledge and collect referencedocuments for verification Ontology reuse approach usesexisting ontologies without change if the existing ontologiescoincide with concepts and terms in target domainThus thecost for ontology creation is low MDR based approach usesontologies registered in ametadata registryWhen ontologiesare created users need to search terms and their relationsto apply the search result to new ontologies Users also needa customization task to create link between domains andranges Although this approach requires medium cost whichis higher cost than the cost of ontology reuse approachthe cost of MDR approach is lower than user-definedapproach

52 Quantitative Evaluation Simulation Approach This sec-tion describes our quantitative analysis which clearly showsthe advantages of the proposed system CaSOB Many sys-tems and studies have addressed interoperability betweenontologies However most focus on interoperability issueamong ontologies which have already been created withtheir own ontology schema definition rules Our approach isimplemented in the step before ontology creation which aimsto reuse common concepts and increase interoperabilityThispaper defines existing approaches as user-defined ontologyschema creation methods and we conducted a quantitativeevaluation to compare our method with the user-definedschema creationmethodThemetadata registry also providesno schema creation method because its purpose is to registerand share ontologies In other words our proposed method

CaSOB is based on the MDR but the metadata registry isexcluded from the quantitative evaluation

An appropriate comparative item was determined forthe evaluation The goal of this paper is to minimize thesemantic heterogeneity of ontologies via the reuse of commonconceptsTherefore this paper conducted a quantitative eval-uation of the semantic heterogeneity rate We can estimatethe approximate ontology integration cost using the semanticheterogeneity rate so this paper also includes the ontologyintegration cost as a comparative item

The evaluation methodology is summarized as follows

(i) comparative targets our proposed method CaSOBand the user-defined ontology schema creationmethod

(ii) comparative items the semantic heterogeneity ratethat is the number of heterogeneous semantics(concepts) shared among the created ontologies theontology integration cost that is the cost required tointegrate a set of created ontologies

The key symbols and notations are defined as follows

(i) 119874 a set of ontologies created with a target method119874 = 1199001 1199002 1199003 119900119899

(ii) 119900119894 a created ontology consisting of one or moresemantics that is a set of concepts such as classesrelations properties and data types

(iii) 119862 a set of common concepts registered and used forcreating an ontology

International Journal of Distributed Sensor Networks 11N

umbe

r of h

eter

ogen

eous

conc

epts

Case-1 the proposal is the almost worst case Case-2 the proposal is the average case

Case-3 the proposal is the almost best case

0100020003000400050006000700080009000

10000

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000N

umbe

r of h

eter

ogen

eous

conc

epts

0100020003000400050006000700080009000

10000Case-4 the proposal is from the almost best to the average⟩⟩⟩⟩

⟩⟩ ⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 9 Comparative evaluation results for the number of semantic heterogeneities

(iv) 119867119890119862119894 a set of heterogeneous concepts in the 119894th

ontology among the created ontologies(v) 119867119900119862 a set of homogeneous concepts among the

created ontologies(vi) 119899(119874) the number of created ontologies(vii) 119899(119900

119894) the number of concepts in the 119894th ontology

(viii) 119899(119862) the number of common concepts used to createan ontology

(ix) 119899(119867119890119862119894) the number of heterogeneous concepts inthe 119894th ontology

(x) 119903(119867119900119862) the average ratio of homogeneous concepts(xi) 119903(119862) the average ratio of used common concepts(xii) 119905 semantic interpretation time between two concepts

0 lt 119905 lt 1(xiii) 119878119867119873 the number of heterogeneous concepts(xiv) 119874119868119862 the ontology integration cost

For the evaluation we assume that 119899-people generate anontology in the same domain In this case the homogeneousconcept means concepts which are commonly contained bymost of the ontologies For example the concept such assensor could be a homogeneous concept even though eachof the sensor ontologies is developed by different people Onthe other hand the heterogeneous concept means discordantconcepts with each of the ontologies We assume that thenumber of heterogeneous concepts is the number of totalconcepts without an average ratio of homogeneous concepts

Figure 9 shows the comparative evaluation result for thesemantic heterogeneity as 119878119867119873 The evaluation determinesthe variation in the number of heterogeneous conceptsdepending on the change in the ratio of homogeneousconcepts and the ratio of used common concepts

119878119867119873119901119903119900119901119900119904119886119897

considers the common concepts used tobuild an ontology In other words it is the result of an evalua-tion using our proposedmethod 119878119867119873

119901119903119890V119894119900119906119904 is an evaluationresult using a user-defined schema creation method

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

International Journal of Distributed Sensor Networks 3

3 The CaSOB Framework

Figure 1 shows the CaSOB framework CaSOB contains fourprocesses (Section 32) and it creates an ontology using amapping model from MDR (Section 31) Various conceptsare registered in ametadata registry for sharing and reusing ascommon concepts Therefore the mapping model is definedusing components in regions related by common conceptsand data representations including concepts region and datadescription region from several areas of MDR As a resultontology is built as an ontology according to ontology schemamodel so this paper considers only the schema level ofontology and it excludes the instance level

31 Mapping Model

311 Preliminary Definition MDR supports the registrationand administration of common concepts And it specifiesa metamodel for the registration and administration ofcommon concepts as an MDR specification There are sevenmain regions These regions are classified as regions that reg-ister and administer concepts regions that name and defineconcepts regions that represent the relations among conceptsand components and regions that specifically describe dataIn this paper we formally define the MDR model for tworegions that is the concepts region and data descriptionregion

Definition 1 (MDR concepts model) The MDR conceptsmodel is a six-tuple

MDR119862

= (119862119878 119862 119877 119877119877 119871119864 119897119894119899119896) (1)

where one has the following(i) 119862119878 is a set of concept systems A concept system rep-

resents a domain of concepts such as an applicationdomain or knowledge domain

(ii) 119862 is a set of concepts A concept is a unit of knowledgecreated by a unique combination of characteristicsSome tuples of the MDR concepts model and theMDR data descriptionmodel inherit119862 as a basic unit

(iii) 119877 is a set of relations A relation is a concept thatrepresents the association among concepts

(iv) 119877119877 is a set of relation roles A relation role is a role ofa concept associated with a specific relation

(v) 119871119864 is a set of link ends A link end is a pair of aconcept and a relation role as one side of 119897119894119899119896 and LEis expressed by ⟨119888 and 119903119903⟩ where 119888 isin 119862 and 119903119903 isin 119877119877

(vi) 119897119894119899119896 119877 rarr 119871119864 times 119871119864 represents the linkage of twolink ends which are associated with a relation In thispaper one focuses generation of a triple statement asontology so a binary relation is only considered

The MDR concepts model defines all the conceptsand relations administered in MDR As an exampleFigure 2 shows that the MDR concepts model contains119897119894119899119896ldquoclass-subsumptionrdquo (ltldquoSensor ldquosuperclassOfrdquogt ltldquoSystemrdquoldquosubclassOfrdquogt) where ldquoSensorrdquo ldquoSystemrdquo isin 119862 ldquoclass-subsumptionrdquo isin119877 and ldquosuperclassOfrdquo ldquosubclassOfrdquoisin119877119877

Definition 2 (MDR data description model) The MDR datadescription model is an eight-tuple

MDR119863= (119862119863119881119872119881119863119874119862 119875119903 119863119864119862119863119864119863119894119898) (2)

where one has the following

(i) 119862119863 is a set of conceptual domains A conceptualdomain is a domain wherein data element conceptscould have a shared conceptual level A conceptualdomain is also used to represent a set of valuemeanings (119881119872)

(ii) 119881119872 is a set of value meanings A value meaning is ageneral meaning of actual values

(iii) 119881119863 is a set of value domains A value domain is adomain in the actual data level which represents theactual values such as a data type

(iv) 119874119862 is a set of object classes An object class is a generalconcept that can capture many instances

(v) 119875119903 is a set of properties A property is an attribute ofobjects or concepts

(vi) 119863119864119862 is a set of data element concepts A data elementconcept is a pair of a concept and a data elementAnd 119863119864119862 is expressed by ⟨119900119888 119901119903⟩ where 119900119888 isin

119874119862 and 119901119903 isin 119875119903(vii) 119863119864 sube 119863119864119862 times 119881119863 is a set of data elements The data

element is the basic unit of data for MDR(viii) 119863119894119898 is a set of dimensionalities A dimensionality

is an aggregation of the units of measures which isrelated to a conceptual domain for example lengthheight or weight

An ontology contains components that depend on thelanguage and the description method In this paper wefocused on building ontologies to improve interoperabilityamong various applications or systems so we concentratedon building ontology in schema level rather than instance orindividual level

Definition 3 (ontology schemamodel) The ontology schemamodel is a six-tuple

119874119899119905119900 = (119862119897 119875 119877119890119897 119863119879 119903119890119897119886119905119894119900119899 119901119903119900119901) (3)

where one has the following

(i) 119862119897 is a set of classes A class is a concept that groupsitems sharing the same characteristics Commoncharacteristics are described logically

(ii) 119875 is a set of properties A property indicates thecharacteristics of a class In the ontology schemamodel a property is described by connecting a classto a data type

(iii) 119877119890119897 is a set of relations in an ontology domainA relation in an ontology domain describes thecharacteristics existing among classes A relation isdescribed by connecting one class to another class

4 International Journal of Distributed Sensor Networks

Metadata registry

Ontology schemaMapping model

Mapping model Mapping model

Ontology building process

3 Class and relation 4 Detailed class definition1 Concept system selection 2 Candidate selectiondefinition

de_name reg_statusKorea01 SubmittedKorea02 Recorded

Korea02

Reg_statusSubmittedRecorded

Reg_statusSubmittedRecordedKorea02

reg_statusSubmittedRecordedKorea02

Korea02 middot middot middotKorea02 middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middotmiddot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middotde_nameKorea01Korea02Korea02 middot middot

de_nameKorea01Korea02Korea02

de_nameKorea01Korea02Korea02

with RuleC with RoleD

Figure 1 The CaSOB framework

Concepts region

Sensor

System

superclassOf

subclassOf

Link Class-subsumption

RR

RR

R

C

C

LE

LE

Figure 2 An example of the MDR concepts model

(iv) 119863119879 is a set of data types A data type is a type of valuegiven to a class property

(v) 119903119890119897119886119905119894119900119899119877119890119897 rarr 119862119897times119862119897 is a triple statement expressedby (119888119897

1 119903119890119897 119888119897

2) where 119888119897

1 1198881198972 isin 119862119897 and 119903119890119897 isin 119877119890119897

such as an object property of OWL

(vi) 119901119903119900119901 119875 rarr 119862119897 times 119863119879 is a triple statement expressedby (119888119897 119901 119889119905) where 119888119897 isin 119862119897 119901 isin 119875 and 119889119905 isin 119863119879 suchas a data type property of OWL

312 CaSOB Mapping Model The CaSOB mapping modeldefines the mapping rules based on the MDR models forthe ontology schema model as shown in the preliminarydefinition provided in Section 311 Data mapped by theCaSOB mapping model is used to build an ontology

Definition 4 (mapping model) The mapping model is a two-tuple

119872119872 = (119877119906119897119890119862 119877119906119897119890

119863) (4)

where one has the following

(i) 119877119906119897119890119862is a set of rules connecting the MDR concepts

model with the ontology schema model 119877119906119897119890119862has

three rules as follows

(a) 119862 rarr 119862119897(b) 119877119877 rarr 119877119890119897(c) 119897119894119899119896 rarr 119903119890119897119886119905119894119900119899 that is 119897119894119899119896

119903(⟨1198881 1199031199031⟩

⟨1198882 1199031199032⟩) rarr 119903119890119897119886119905119894119900119899

1199031199032(1198881198971 1198881198972) or 119903119890119897119886119905119894119900119899

1199031199031

(1198881198972 1198881198971) where 119903 rarr 119903119890119897 119888

1rarr 119888119897

1 and

1198882rarr 1198881198972with 119903 isin 119877 119888

1 1198882 isin 119862 119903119903

1 1199031199032 isin

119877119877 119903119890119897 isin 119877119890119897 and 1198881198971 1198881198972 isin 119862119897

(ii) 119877119906119897119890119863

is a set of rules connecting the MDR datadescription model and the ontology schema model119877119906119897119890119863has eight rules as follows

(a) 119862119863 rarr 119862119897(b) 119881119872 rarr 119862119897(c) 119863119894119898 rarr 119862119897(d) 119874119862 rarr 119862119897(e) 119875119903 rarr 119875(f) 119881119863 rarr 119863119879(g) 119863119864119862 rarr 119862119897 times 119875(h) 119863119864 rarr 119901119903119900119901 that is (⟨119900119888 119888ℎ⟩ V119889) rarr 119901119903119900119901

119901

(119888119897 119889119905) where 119900119888 rarr 119888119897 119901119903 rarr 119901 and V119889 rarr

119889119905 with 119889119890 isin 119863119864 119900119888 isin 119874119862 119901119903 isin 119875119903 V119889 isin 119881119863119901 isin 119875 119888119897 isin 119862119897 and 119889119905 isin 119863119879

For 119877119906119897119890119862 C is specialized in 119862119863 119863119864 119874119862 and so forthin an MDR data description region so 119862 is mapped to 119862119897Due to the fact that 119877 is an undirected relation and 119877119877 hasdirection 119877119877 is mapped to 119877119890119897 And link has the same tuple119871119864 and relation also has the same tuple 119862119897 hence there aretwo types of results when 119897119894119899119896 is mapped into 119903119890119897119886119905119894119900119899 whichdepends on 119877119877 This is because the ontology schema modelexpresses the ontology as a triple statement with a directionsuch as (subject predicate object) However the 119897119894119899119896 is able

International Journal of Distributed Sensor Networks 5

sensor

system

superclassOf

MDR concepts model Ontology schema model

subclassOfsystem

sensor

subclassOf

(2)

system

sensor

superclassOf

(1)

Class-subsumption

Rel

RelRR

RR

R

C

C

Cl

Cl Cl

Cl

Figure 3 The expected mapping results with 119877119906119897119890119862

MDR data description model Ontology schema model

system

string

hasSerialNumberhasSerialNumber

DE

DEC

Pr

VD

system

string

Cl

DT

P

OC

Figure 4 A mapping example using 119877119906119897119890119863

to map two 119903119890119897119886119905119894119900119899119904 by 119877119877 Thus a user needs to select asubject and an object when CaSOB uses rule (c) in 119877119906119897119890

119862

For example Figure 3 shows two expected mappingresults (1) and (2) where 119897119894119899119896 has two 119871119864119904 that islt ldquoSensorrdquo ldquosuperclassOfrdquo gt lt ldquoSystemrdquo ldquosubclassof rdquo gtisin 119871119864 whereas the mapping model cannot automaticallydetermine which 119871119864 becomes a subject or an object in119903119890119897119886119905119894119900119899 of the ontology schema model Thus a user needs toselect the subject and object of 119903119890119897119886119905119894119900119899 Because the subclassis typically more used than superclass in ontology languagethe user could select (1) as the mapping result expressed by119903119890119897119886119905119894119900119899subclassOf (ldquoSensorrdquo ldquoSystemrdquo)

The MDR data description model specifically describesthe meaning of metadata and provides an explanation ofthe concepts defined in the MDR concepts model Thesix tuples of the MDR data description model that is119862119863 119863119864119862 119874119862 119875119903 119881119872 and 119863119894119898 are inherited by 119862 in theMDR concepts model 119862 is expressed differently dependingon the property of the inherited tuples Thus each tupleis mapped to 119862119897 119875 or 119863119879 while most of the ontologiesmapped by RuleD are triple statements such as (119862119897 119875 and119863119879) 119862119863 119874119862 119881119872 and 119863119894119898 are only mapped to 119862119897 in thesix tuples because they are entities which are connected byother classes 119881119863 is mapped to 119863119879 although 119881119863 does notmean data type However 119881119863 contains a data type insideand 119863119864 contains 119881119863 not a data type directly Also if 119881119863 ismapped to 119863119879 we can define some special data types like 2-alpha country code 119875119903 is mapped to 119875 because 119875119903 indicatesan attribute of classes 119863119864119862 contains 119874119862 and 119875119903 so 119863119864119862 is

mapped to 119862119897 and 119875 both Similarly 119863119864 contains 119863119864119862 and119881119863 so119863119864 could be mapped to (119862119897 119875 119863119879) statement

Figure 4 shows a mapping example for 119877119906119897119890119863 The MDR

data description model expresses 119863119864 as ldquoSystem hasSerial-Numberrdquo with a ldquoStringrdquo data type where ldquoSystemrdquo isin 119874119862ldquohasSerialNumberrdquo isin 119875119903 ltldquoSystemrdquo ldquohasSerialNumberrdquogtisin 119863119864119862 and ldquoStringrdquo isin 119881119863 As a result the ontology schemamodel constructs a (ldquoSystemrdquo ldquohasSerialNumberrdquo ldquoStringrdquo)statement where ldquoSystem10158401015840 isin 119862119897 ldquohasSerialNumberrdquo isin P andldquoStringrdquo isin 119863119879

32 Ontology Building Process

321 Concept System Selection The first process for buildingontology is to decide a domain of an ontology If domains aredifferent from each other ontology meanings and relationsare different even if they have the same terminology Aconcept system includes the domain and scope of the dataThus CaSOB determines the domain of an ontology byselecting a concept system from 119862119878

In the first process shown in Figure 5 the concept systemldquoCSIRO Sensor Ontologyrdquo in 119862119878 is selected if a user wants tobuild an ontology in a sensor domain defined by CSIRO

322 Candidate Selection In the candidate selection processcandidates are selected to build an ontology Tuples of theMDR concepts model such as119862 119877 and 119897119894119899119896may be selectedas candidates The candidates are the same as the set of termsused when ontologies are created

119862 and link are selected from 119862119878 as candidate 119862 andcandidate 119897119894119899119896 respectively 119897119894119899119896 contains119862 119877 119877119877 and 119871119864 soboth candidate119862 and candidate 119897119894119899119896 can be selected from one119897119894119899119896 The selected 119897119894119899119896 becomes candidate 119897119894119899119896 119862 included in119897119894119899119896 is automatically selected as candidate 119862

The concept system ldquoCSIRO Sensor Ontologyrdquo is selectedduring the first step of Figure 5 The next step is to select theterms contained at the domain Candidates are selected suchas ldquoSensorrdquo ldquoSensorGroundingrdquo and ldquosupportsrdquo

323 Class and Relation Definition In the third process 119862119897and 119877119890119897 of the ontology schema model are defined by thecandidates A set of candidate concepts is defined for119862119897 whilea set of candidate links is defined for 119877119890119897

However CaSOB does not know the difference of 119877119877 for119862 such as the ldquoSubjectrdquo and ldquoObjectrdquo in an actual system Itis difficult to automatically determine roles simply by usingcandidate 119897119894119899119896 Thus a user has to determine the subject andobject of 119903119890119897119886119905119894119900119899 in the ontology schema model

In the third step shown in Figure 5119862119897 and119877119890119897 are definedusing the selected terms ldquoSensorrdquo ldquoSensorGroundingrdquo sub

119862119897 are defined while ldquosupportsrdquo isin 119877119890119897 is defined betweenldquoSensorrdquo as a subject and ldquoSensorGroundingrdquo as an object Inthis process it is possible to define concepts and relation overthe domains To define 119862119897 and 119877119890119897 in other domains we needto come back to the first process choose ldquoMMI Ontologyrdquoand select candidates for selecting terms defined in ldquoMMIOntologyrdquo domain Then Figure 5 shows ldquoSystemrdquo sub 119862119897

6 International Journal of Distributed Sensor Networks

TermsSensorSensorGroundingOperationModelSupportshasOperationModel

Concept system

CSIRO sensor ontology

MMI ontology

SensorOnto

Sensor

System SensorGrounding

subclassOf Supports

System

String

Boolean

hasSerialNumber

isConsumable

Created ontology schema

Sensor

System

SensorGrounding

Boolean

String

Supports

subclassOf

1 Concept system selection 2 Candidate selection 3 Class and relation definition

4 Detailed class definition

ClassData type

RelationProperty

hasSerialNumber

isConsumable

middot middot middotmiddot middot middot

Figure 5 An example of the ontology building process

is also defined and ldquosubclassOfrdquo isin 119877119890119897 is defined betweenldquoSensorrdquo as a subject and ldquoSystemrdquo as an object

324 Detailed Class Definition In the final process119875 and119863119879are defined to decide properties of classes and additionally119862119897and 119877119890119897 are defined by the mapping model

Because ldquoSystemrdquo isin 119862119897was defined in the previous step itis given that ldquohasSerialNumberrdquo isin 119875 with ldquoStringrdquo isin 119863119879 andldquoisConsumablerdquo isin 119875 using ldquoBooleanrdquo isin 119863119879 in the final stepof Figure 5

4 Implementation

This section describes a metadata registry and CaSOBimplementation To make easy connection and mappingmodel we need to implement a metadata registry based onMDR specification The metadata registry is implementedby MySQL database which is a RDBMS (relational databasemanagement system) For testing we need to store datasets inthe metadata registry so we select several sensor ontologiesas the dataset Then we assume that the selected ontologiescontained common concepts so the datasets stored in themetadata registry also contain common concepts CaSOB isdeveloped inC for a user interface database connection andthe ontology building processes

41 A Metadata Registry Implementation The metadata reg-istry is implemented so the MDR metamodel could collect

Figure 6 Implementation of the concepts region

data directly as required to import the administered meta-data and create an ontology Thus we initially develop themetadata registry by implementing the metamodel of MDRSection 41 presents the MDR-based system structured byRDBMS

Each component in the metamodel is defined as RDBMStable while properties of each component are defined as tableattributes Moreover associations between components aredefined using foreign key referential integrity

Figure 6 shows the table and foreign key references of theconcepts region in MDR The ldquoConceptrdquo table includes theattributes ldquoconceptrdquo and ldquosourcerdquo ldquoconceptrdquo is an attributewhere the name held by the concept of MDR is expressedusing strings ldquosourcerdquo is an attribute that expresses a concept

International Journal of Distributed Sensor Networks 7

Figure 7 Implementation of the data description region

system including concepts using foreign key referencesMoreover the ldquoLinkrdquo table has a ldquorelationrdquo attribute for theldquoRelationrdquo tableThe ldquoLink Endrdquo table has the attributes ldquoendrdquoand ldquorolerdquo for the ldquolinkrdquo attribute where ldquoendrdquo means theconcept ldquorolerdquo means the relation role and ldquolinkrdquo means thelink Thus one link has at least two link ends

In Figure 7 the data description region is implemented astables and foreign key references Seven components in thedata description region inherit the concept in the conceptsregion so the components express the inheritance using eachof the attributes of ldquoconceptrdquo and ldquoconcept sourcerdquo held in theldquoConceptrdquo table

42 CaSOB Implementation In Section 42 the ontologybuilding process of CaSOB is presentedwith the implementa-tion screen which is based on the four processes of ontologycreation

421 Concept System Selection (Process 1) If the domainof the ontology to be created has been determined thesystem searches and selects the concept system (CS) of thecorresponding domain In Figure 8(a) CS of Process 1 isselected in the upper right corner of the screen as ldquoCSIROSensor Ontologyrdquo to create the sensor ontology

422 Candidate Selection (Process 2) The process selectseach candidate concept and each candidate link from theconcepts (C) and links (link) including the concept systemselected in Process 1 Type currently indicates the sevencomponents inheriting the concept

In Figure 8(a) ldquosupport Sensor (supportedBy) Sensor-Grounding (supports)rdquo is selected from links The selectedlink is added to candidate link and contained concepts

ldquoSensorrdquo and ldquoSensorGroundingrdquo are automatically added tocandidate concepts

423 Class and Relation Definition (Process 3) The processdefines the classes (119862119897) and relations (119877119890119897) of the ontologyschemamodel from the selected candidates A user selects thedesired candidate concept to define 119862119897 and selects candidatelinks to set the domain and range of Rel An 119877 including thecandidate link ismapped to a119877119890119897 of the ontologyThe domainand range are set during the selection of a candidate linkwith the roles of a subject and an object respectively A userselects each candidate to define the119862119897 and119877119890119897 of the ontologyschema model

In Figure 8(b) to define ldquoSystemrdquo isin 119862 in other do-mains ldquoMMI Ontologyrdquo isin 119862119878 is selected And ldquoSystemrdquois selected as candidate concepts and ldquoclass-subsumptionSensor (superclassOf) System (subclassOf)rdquo is selected ascandidate links The marked candidate link expresses ldquoclass-subsumptionrdquo which has (ldquoSensorrdquo ldquosubclassOfrdquo ldquoSystemrdquo)statement

424 Detailed Definition of Classes (Process 4) This processdefines classes (119862119897) and properties (119875) of the classes usingthe candidate concept and the type of concepts Additionalrelations (119877119890119897) are also created

In this process a user selects the candidate concepts Eachconcept has a type and has different mechanism to buildontologies according to the mapping model (119872119872) A userdefines119862119897 119875 119863119879 and additional 119877119890119897 of the ontology schemamodel When a candidate concept is selected the data thatcan be selected changes depending on its type so an ontologyis created containing the relations among components thatwere defined in the previous section

For example Figure 8(c) shows a screenshot of thedetailed definition of Cl in the ontology schema model Theselected candidate concept ldquoSystemrdquohas data element concept(DEC) type ldquohasSerialNumberrdquo isin 119875119903 becomes 119875 withldquoStringrdquo isin 119863119879 for ldquoSystemrdquo isin 119862119897 from ldquoSystem hasSerial-Number Stringrdquo isin 119863119864 associated with ldquoSystem hasSerial-numberrdquo isin 119863119864119862

425 The Created Ontology Figure 8(d) shows the completeontology for all processes The complete ontology is mainlycomprised of classes (119862119897) properties (119875) and relations (119877119890119897)P of each specific 119862119897 has a data type (119863119879) Rel has two 119862119897119904

with the roles of domain and rangeCaSOB provides a general ontology for a target ontology

It means that CaSOB does not provide specific ontologylanguages such as RDF OWL SKOS and Topic Map Thus auser needs to describe the complete ontology using a specificontology language Algorithm 1 shows the ontology createdin Figure 8(d) as described using OWL

5 Evaluation

51 Qualitative Evaluation We conducted a comparativeevaluation study for ontology creation This section first

8 International Journal of Distributed Sensor Networks

(a) (b)

(c) (d)

Figure 8 Screenshots of CaSOB

describes our qualitative evaluation using various com-parative items This evaluation involved the comparativeevaluation of three ontology building approaches which areuser-defined approach ontology reuse approach and ourproposedMDR based approach Table 1 shows the qualitativeevaluation results

The first factor for evaluation is standardization levelIt means whether the created ontology could be used as acommon or general ontology or not User-defined approachis hard to become a common standard approach because ofexperts who can create ontologies based on their own knowl-edge Hence created ontologies by user-defined approachcannot share their concept On the other hand since ontologyreuse approach and MDR based approach use ontologiesalready created which can contain common concepts cre-ated ontology using these ontology reuse and MDR basedapproaches can become standardized ontologies That is whyeach standardization level of these two approaches becomeshigh

The second evaluation factor is ontology quality Ontol-ogy quality means whether created ontologies are welldefined and whether the quality of created ontologies isguaranteed In case of user-defined approach a createdontology contains personal view point without general orcommon perspectiveTherefore the created ontology cannotguarantee the quality of ontologies CSIROMMI and ISTARontologies are popular ontologiesThese ontologies are one of

the results from each big projectThese ontologies are verifiedby a lot of experts whether concepts and relationships of theseontologies are well defined or not If we create a new ontologyreusing these well-defined ontologies we can guaranteesthe ontology quality In MDR based approach ontologiesand common concepts are controlled by MDR organizationsthat follow a standardized procedure for managing commonconcepts and reflect a standardized lifecycle for creatingontologies It means that the MDR-based ontology reuseapproach enables high-quality ontology creation

Limitation of expression means how the expressivepower is restricted when ontologies are created User-definedapproach has no limitation to express knowledge basedon ontologies because a user selects their own terms andthe user can make relationships following userrsquos opinionOntology reuse approach just uses existing ontologies It isnot allowed to change existing concepts and terms whenconcepts or terms are incorrect from target domainThus theexpression of ontology is very strict MDR based approachreuses registered ontologies in the metadata registry TheMDR based approach also permits changing other ontologieswhen there are no concepts or terms that are required inexisting ontologies Nevertheless the MDR approach is strictbecause it is not allowed to define unregistered ontologies

The final factor of qualitative evaluation is creation costCreation cost means convenience of creating ontologiesand time for building ontologies In user-defined approach

International Journal of Distributed Sensor Networks 9

ltxml version=ldquo10rdquogtltOntology xmlns=ldquohttpwwww3org200207owlrdquoxmlbase=ldquohttpsoftwarekoreaackrSwsysSensorOntologyowlrdquoxmlnsrdfs=ldquohttpwwww3org200001rdf-schemardquoxmlnsxsd=ldquohttpwwww3org2001XMLSchemardquoxmlnsrdf=ldquohttpwwww3org19990222-rdf-syntax-nsrdquoxmlnsxml=ldquohttpwwww3orgXML1998namespacerdquo

ltPrefix name=ldquoxsdrdquoIRI=ldquohttpwwww3org2001XMLSchemardquogt

ltPrefix name=ldquoowlrdquoIRI=ldquohttpwwww3org200207owlrdquogtltPrefix name=ldquordf rdquo IRI=ldquohttpwwww3org19990222-rdf-syntax-nsrdquogtltPrefix name=ldquordfsrdquo IRI=ldquohttpwwww3org200001rdf-schemardquogtltDeclarationgt

ltClass IRI=ldquoPhysicalQualityrdquogtltClass IRI=ldquoSensorrdquogtltClass IRI=ldquoSensorGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogtltClass IRI=ldquoSystemrdquogtltObjectProperty IRI=ldquosubclassOfrdquogtltObjectProperty IRI=ldquomeasurerdquogtltObjectProperty IRI=ldquomodelGroundingrdquogtltObjectProperty IRI=ldquosupportsrdquogtltDataProperty IRI=ldquoisConsumablerdquogtltDataProperty IRI=ldquohasSerialNumberrdquogt

ltDeclarationgtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSystemrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingtltObjectProperty IRI=ldquomeasurerdquogt

ltClass IRI=ldquoSensorrdquogtltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomeasurerdquogtltClass IRI=ldquoPhysicalQualityrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquoisConsumablerdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingt

Algorithm 1 Continued

10 International Journal of Distributed Sensor Networks

ltDataPropertyRangegtltDataProperty IRI=ldquoisConsumablerdquogtltDatatype abbreviatedIRI=ldquoxsdbooleanrdquogt

ltDataPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingtltDataPropertyRangegt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltDatatype abbreviatedIRI=ldquoxsdstringrdquogt

ltDataPropertyRangegtltOntologygt

Algorithm 1 An ontology described using OWL

Table 1 Qualitative evaluation of ontology building approaches

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

experts directly define concepts and terms and it requireshigh cost to survey domain knowledge and collect referencedocuments for verification Ontology reuse approach usesexisting ontologies without change if the existing ontologiescoincide with concepts and terms in target domainThus thecost for ontology creation is low MDR based approach usesontologies registered in ametadata registryWhen ontologiesare created users need to search terms and their relationsto apply the search result to new ontologies Users also needa customization task to create link between domains andranges Although this approach requires medium cost whichis higher cost than the cost of ontology reuse approachthe cost of MDR approach is lower than user-definedapproach

52 Quantitative Evaluation Simulation Approach This sec-tion describes our quantitative analysis which clearly showsthe advantages of the proposed system CaSOB Many sys-tems and studies have addressed interoperability betweenontologies However most focus on interoperability issueamong ontologies which have already been created withtheir own ontology schema definition rules Our approach isimplemented in the step before ontology creation which aimsto reuse common concepts and increase interoperabilityThispaper defines existing approaches as user-defined ontologyschema creation methods and we conducted a quantitativeevaluation to compare our method with the user-definedschema creationmethodThemetadata registry also providesno schema creation method because its purpose is to registerand share ontologies In other words our proposed method

CaSOB is based on the MDR but the metadata registry isexcluded from the quantitative evaluation

An appropriate comparative item was determined forthe evaluation The goal of this paper is to minimize thesemantic heterogeneity of ontologies via the reuse of commonconceptsTherefore this paper conducted a quantitative eval-uation of the semantic heterogeneity rate We can estimatethe approximate ontology integration cost using the semanticheterogeneity rate so this paper also includes the ontologyintegration cost as a comparative item

The evaluation methodology is summarized as follows

(i) comparative targets our proposed method CaSOBand the user-defined ontology schema creationmethod

(ii) comparative items the semantic heterogeneity ratethat is the number of heterogeneous semantics(concepts) shared among the created ontologies theontology integration cost that is the cost required tointegrate a set of created ontologies

The key symbols and notations are defined as follows

(i) 119874 a set of ontologies created with a target method119874 = 1199001 1199002 1199003 119900119899

(ii) 119900119894 a created ontology consisting of one or moresemantics that is a set of concepts such as classesrelations properties and data types

(iii) 119862 a set of common concepts registered and used forcreating an ontology

International Journal of Distributed Sensor Networks 11N

umbe

r of h

eter

ogen

eous

conc

epts

Case-1 the proposal is the almost worst case Case-2 the proposal is the average case

Case-3 the proposal is the almost best case

0100020003000400050006000700080009000

10000

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000N

umbe

r of h

eter

ogen

eous

conc

epts

0100020003000400050006000700080009000

10000Case-4 the proposal is from the almost best to the average⟩⟩⟩⟩

⟩⟩ ⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 9 Comparative evaluation results for the number of semantic heterogeneities

(iv) 119867119890119862119894 a set of heterogeneous concepts in the 119894th

ontology among the created ontologies(v) 119867119900119862 a set of homogeneous concepts among the

created ontologies(vi) 119899(119874) the number of created ontologies(vii) 119899(119900

119894) the number of concepts in the 119894th ontology

(viii) 119899(119862) the number of common concepts used to createan ontology

(ix) 119899(119867119890119862119894) the number of heterogeneous concepts inthe 119894th ontology

(x) 119903(119867119900119862) the average ratio of homogeneous concepts(xi) 119903(119862) the average ratio of used common concepts(xii) 119905 semantic interpretation time between two concepts

0 lt 119905 lt 1(xiii) 119878119867119873 the number of heterogeneous concepts(xiv) 119874119868119862 the ontology integration cost

For the evaluation we assume that 119899-people generate anontology in the same domain In this case the homogeneousconcept means concepts which are commonly contained bymost of the ontologies For example the concept such assensor could be a homogeneous concept even though eachof the sensor ontologies is developed by different people Onthe other hand the heterogeneous concept means discordantconcepts with each of the ontologies We assume that thenumber of heterogeneous concepts is the number of totalconcepts without an average ratio of homogeneous concepts

Figure 9 shows the comparative evaluation result for thesemantic heterogeneity as 119878119867119873 The evaluation determinesthe variation in the number of heterogeneous conceptsdepending on the change in the ratio of homogeneousconcepts and the ratio of used common concepts

119878119867119873119901119903119900119901119900119904119886119897

considers the common concepts used tobuild an ontology In other words it is the result of an evalua-tion using our proposedmethod 119878119867119873

119901119903119890V119894119900119906119904 is an evaluationresult using a user-defined schema creation method

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

4 International Journal of Distributed Sensor Networks

Metadata registry

Ontology schemaMapping model

Mapping model Mapping model

Ontology building process

3 Class and relation 4 Detailed class definition1 Concept system selection 2 Candidate selectiondefinition

de_name reg_statusKorea01 SubmittedKorea02 Recorded

Korea02

Reg_statusSubmittedRecorded

Reg_statusSubmittedRecordedKorea02

reg_statusSubmittedRecordedKorea02

Korea02 middot middot middotKorea02 middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middotmiddot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middot

middot middot middotde_nameKorea01Korea02Korea02 middot middot

de_nameKorea01Korea02Korea02

de_nameKorea01Korea02Korea02

with RuleC with RoleD

Figure 1 The CaSOB framework

Concepts region

Sensor

System

superclassOf

subclassOf

Link Class-subsumption

RR

RR

R

C

C

LE

LE

Figure 2 An example of the MDR concepts model

(iv) 119863119879 is a set of data types A data type is a type of valuegiven to a class property

(v) 119903119890119897119886119905119894119900119899119877119890119897 rarr 119862119897times119862119897 is a triple statement expressedby (119888119897

1 119903119890119897 119888119897

2) where 119888119897

1 1198881198972 isin 119862119897 and 119903119890119897 isin 119877119890119897

such as an object property of OWL

(vi) 119901119903119900119901 119875 rarr 119862119897 times 119863119879 is a triple statement expressedby (119888119897 119901 119889119905) where 119888119897 isin 119862119897 119901 isin 119875 and 119889119905 isin 119863119879 suchas a data type property of OWL

312 CaSOB Mapping Model The CaSOB mapping modeldefines the mapping rules based on the MDR models forthe ontology schema model as shown in the preliminarydefinition provided in Section 311 Data mapped by theCaSOB mapping model is used to build an ontology

Definition 4 (mapping model) The mapping model is a two-tuple

119872119872 = (119877119906119897119890119862 119877119906119897119890

119863) (4)

where one has the following

(i) 119877119906119897119890119862is a set of rules connecting the MDR concepts

model with the ontology schema model 119877119906119897119890119862has

three rules as follows

(a) 119862 rarr 119862119897(b) 119877119877 rarr 119877119890119897(c) 119897119894119899119896 rarr 119903119890119897119886119905119894119900119899 that is 119897119894119899119896

119903(⟨1198881 1199031199031⟩

⟨1198882 1199031199032⟩) rarr 119903119890119897119886119905119894119900119899

1199031199032(1198881198971 1198881198972) or 119903119890119897119886119905119894119900119899

1199031199031

(1198881198972 1198881198971) where 119903 rarr 119903119890119897 119888

1rarr 119888119897

1 and

1198882rarr 1198881198972with 119903 isin 119877 119888

1 1198882 isin 119862 119903119903

1 1199031199032 isin

119877119877 119903119890119897 isin 119877119890119897 and 1198881198971 1198881198972 isin 119862119897

(ii) 119877119906119897119890119863

is a set of rules connecting the MDR datadescription model and the ontology schema model119877119906119897119890119863has eight rules as follows

(a) 119862119863 rarr 119862119897(b) 119881119872 rarr 119862119897(c) 119863119894119898 rarr 119862119897(d) 119874119862 rarr 119862119897(e) 119875119903 rarr 119875(f) 119881119863 rarr 119863119879(g) 119863119864119862 rarr 119862119897 times 119875(h) 119863119864 rarr 119901119903119900119901 that is (⟨119900119888 119888ℎ⟩ V119889) rarr 119901119903119900119901

119901

(119888119897 119889119905) where 119900119888 rarr 119888119897 119901119903 rarr 119901 and V119889 rarr

119889119905 with 119889119890 isin 119863119864 119900119888 isin 119874119862 119901119903 isin 119875119903 V119889 isin 119881119863119901 isin 119875 119888119897 isin 119862119897 and 119889119905 isin 119863119879

For 119877119906119897119890119862 C is specialized in 119862119863 119863119864 119874119862 and so forthin an MDR data description region so 119862 is mapped to 119862119897Due to the fact that 119877 is an undirected relation and 119877119877 hasdirection 119877119877 is mapped to 119877119890119897 And link has the same tuple119871119864 and relation also has the same tuple 119862119897 hence there aretwo types of results when 119897119894119899119896 is mapped into 119903119890119897119886119905119894119900119899 whichdepends on 119877119877 This is because the ontology schema modelexpresses the ontology as a triple statement with a directionsuch as (subject predicate object) However the 119897119894119899119896 is able

International Journal of Distributed Sensor Networks 5

sensor

system

superclassOf

MDR concepts model Ontology schema model

subclassOfsystem

sensor

subclassOf

(2)

system

sensor

superclassOf

(1)

Class-subsumption

Rel

RelRR

RR

R

C

C

Cl

Cl Cl

Cl

Figure 3 The expected mapping results with 119877119906119897119890119862

MDR data description model Ontology schema model

system

string

hasSerialNumberhasSerialNumber

DE

DEC

Pr

VD

system

string

Cl

DT

P

OC

Figure 4 A mapping example using 119877119906119897119890119863

to map two 119903119890119897119886119905119894119900119899119904 by 119877119877 Thus a user needs to select asubject and an object when CaSOB uses rule (c) in 119877119906119897119890

119862

For example Figure 3 shows two expected mappingresults (1) and (2) where 119897119894119899119896 has two 119871119864119904 that islt ldquoSensorrdquo ldquosuperclassOfrdquo gt lt ldquoSystemrdquo ldquosubclassof rdquo gtisin 119871119864 whereas the mapping model cannot automaticallydetermine which 119871119864 becomes a subject or an object in119903119890119897119886119905119894119900119899 of the ontology schema model Thus a user needs toselect the subject and object of 119903119890119897119886119905119894119900119899 Because the subclassis typically more used than superclass in ontology languagethe user could select (1) as the mapping result expressed by119903119890119897119886119905119894119900119899subclassOf (ldquoSensorrdquo ldquoSystemrdquo)

The MDR data description model specifically describesthe meaning of metadata and provides an explanation ofthe concepts defined in the MDR concepts model Thesix tuples of the MDR data description model that is119862119863 119863119864119862 119874119862 119875119903 119881119872 and 119863119894119898 are inherited by 119862 in theMDR concepts model 119862 is expressed differently dependingon the property of the inherited tuples Thus each tupleis mapped to 119862119897 119875 or 119863119879 while most of the ontologiesmapped by RuleD are triple statements such as (119862119897 119875 and119863119879) 119862119863 119874119862 119881119872 and 119863119894119898 are only mapped to 119862119897 in thesix tuples because they are entities which are connected byother classes 119881119863 is mapped to 119863119879 although 119881119863 does notmean data type However 119881119863 contains a data type insideand 119863119864 contains 119881119863 not a data type directly Also if 119881119863 ismapped to 119863119879 we can define some special data types like 2-alpha country code 119875119903 is mapped to 119875 because 119875119903 indicatesan attribute of classes 119863119864119862 contains 119874119862 and 119875119903 so 119863119864119862 is

mapped to 119862119897 and 119875 both Similarly 119863119864 contains 119863119864119862 and119881119863 so119863119864 could be mapped to (119862119897 119875 119863119879) statement

Figure 4 shows a mapping example for 119877119906119897119890119863 The MDR

data description model expresses 119863119864 as ldquoSystem hasSerial-Numberrdquo with a ldquoStringrdquo data type where ldquoSystemrdquo isin 119874119862ldquohasSerialNumberrdquo isin 119875119903 ltldquoSystemrdquo ldquohasSerialNumberrdquogtisin 119863119864119862 and ldquoStringrdquo isin 119881119863 As a result the ontology schemamodel constructs a (ldquoSystemrdquo ldquohasSerialNumberrdquo ldquoStringrdquo)statement where ldquoSystem10158401015840 isin 119862119897 ldquohasSerialNumberrdquo isin P andldquoStringrdquo isin 119863119879

32 Ontology Building Process

321 Concept System Selection The first process for buildingontology is to decide a domain of an ontology If domains aredifferent from each other ontology meanings and relationsare different even if they have the same terminology Aconcept system includes the domain and scope of the dataThus CaSOB determines the domain of an ontology byselecting a concept system from 119862119878

In the first process shown in Figure 5 the concept systemldquoCSIRO Sensor Ontologyrdquo in 119862119878 is selected if a user wants tobuild an ontology in a sensor domain defined by CSIRO

322 Candidate Selection In the candidate selection processcandidates are selected to build an ontology Tuples of theMDR concepts model such as119862 119877 and 119897119894119899119896may be selectedas candidates The candidates are the same as the set of termsused when ontologies are created

119862 and link are selected from 119862119878 as candidate 119862 andcandidate 119897119894119899119896 respectively 119897119894119899119896 contains119862 119877 119877119877 and 119871119864 soboth candidate119862 and candidate 119897119894119899119896 can be selected from one119897119894119899119896 The selected 119897119894119899119896 becomes candidate 119897119894119899119896 119862 included in119897119894119899119896 is automatically selected as candidate 119862

The concept system ldquoCSIRO Sensor Ontologyrdquo is selectedduring the first step of Figure 5 The next step is to select theterms contained at the domain Candidates are selected suchas ldquoSensorrdquo ldquoSensorGroundingrdquo and ldquosupportsrdquo

323 Class and Relation Definition In the third process 119862119897and 119877119890119897 of the ontology schema model are defined by thecandidates A set of candidate concepts is defined for119862119897 whilea set of candidate links is defined for 119877119890119897

However CaSOB does not know the difference of 119877119877 for119862 such as the ldquoSubjectrdquo and ldquoObjectrdquo in an actual system Itis difficult to automatically determine roles simply by usingcandidate 119897119894119899119896 Thus a user has to determine the subject andobject of 119903119890119897119886119905119894119900119899 in the ontology schema model

In the third step shown in Figure 5119862119897 and119877119890119897 are definedusing the selected terms ldquoSensorrdquo ldquoSensorGroundingrdquo sub

119862119897 are defined while ldquosupportsrdquo isin 119877119890119897 is defined betweenldquoSensorrdquo as a subject and ldquoSensorGroundingrdquo as an object Inthis process it is possible to define concepts and relation overthe domains To define 119862119897 and 119877119890119897 in other domains we needto come back to the first process choose ldquoMMI Ontologyrdquoand select candidates for selecting terms defined in ldquoMMIOntologyrdquo domain Then Figure 5 shows ldquoSystemrdquo sub 119862119897

6 International Journal of Distributed Sensor Networks

TermsSensorSensorGroundingOperationModelSupportshasOperationModel

Concept system

CSIRO sensor ontology

MMI ontology

SensorOnto

Sensor

System SensorGrounding

subclassOf Supports

System

String

Boolean

hasSerialNumber

isConsumable

Created ontology schema

Sensor

System

SensorGrounding

Boolean

String

Supports

subclassOf

1 Concept system selection 2 Candidate selection 3 Class and relation definition

4 Detailed class definition

ClassData type

RelationProperty

hasSerialNumber

isConsumable

middot middot middotmiddot middot middot

Figure 5 An example of the ontology building process

is also defined and ldquosubclassOfrdquo isin 119877119890119897 is defined betweenldquoSensorrdquo as a subject and ldquoSystemrdquo as an object

324 Detailed Class Definition In the final process119875 and119863119879are defined to decide properties of classes and additionally119862119897and 119877119890119897 are defined by the mapping model

Because ldquoSystemrdquo isin 119862119897was defined in the previous step itis given that ldquohasSerialNumberrdquo isin 119875 with ldquoStringrdquo isin 119863119879 andldquoisConsumablerdquo isin 119875 using ldquoBooleanrdquo isin 119863119879 in the final stepof Figure 5

4 Implementation

This section describes a metadata registry and CaSOBimplementation To make easy connection and mappingmodel we need to implement a metadata registry based onMDR specification The metadata registry is implementedby MySQL database which is a RDBMS (relational databasemanagement system) For testing we need to store datasets inthe metadata registry so we select several sensor ontologiesas the dataset Then we assume that the selected ontologiescontained common concepts so the datasets stored in themetadata registry also contain common concepts CaSOB isdeveloped inC for a user interface database connection andthe ontology building processes

41 A Metadata Registry Implementation The metadata reg-istry is implemented so the MDR metamodel could collect

Figure 6 Implementation of the concepts region

data directly as required to import the administered meta-data and create an ontology Thus we initially develop themetadata registry by implementing the metamodel of MDRSection 41 presents the MDR-based system structured byRDBMS

Each component in the metamodel is defined as RDBMStable while properties of each component are defined as tableattributes Moreover associations between components aredefined using foreign key referential integrity

Figure 6 shows the table and foreign key references of theconcepts region in MDR The ldquoConceptrdquo table includes theattributes ldquoconceptrdquo and ldquosourcerdquo ldquoconceptrdquo is an attributewhere the name held by the concept of MDR is expressedusing strings ldquosourcerdquo is an attribute that expresses a concept

International Journal of Distributed Sensor Networks 7

Figure 7 Implementation of the data description region

system including concepts using foreign key referencesMoreover the ldquoLinkrdquo table has a ldquorelationrdquo attribute for theldquoRelationrdquo tableThe ldquoLink Endrdquo table has the attributes ldquoendrdquoand ldquorolerdquo for the ldquolinkrdquo attribute where ldquoendrdquo means theconcept ldquorolerdquo means the relation role and ldquolinkrdquo means thelink Thus one link has at least two link ends

In Figure 7 the data description region is implemented astables and foreign key references Seven components in thedata description region inherit the concept in the conceptsregion so the components express the inheritance using eachof the attributes of ldquoconceptrdquo and ldquoconcept sourcerdquo held in theldquoConceptrdquo table

42 CaSOB Implementation In Section 42 the ontologybuilding process of CaSOB is presentedwith the implementa-tion screen which is based on the four processes of ontologycreation

421 Concept System Selection (Process 1) If the domainof the ontology to be created has been determined thesystem searches and selects the concept system (CS) of thecorresponding domain In Figure 8(a) CS of Process 1 isselected in the upper right corner of the screen as ldquoCSIROSensor Ontologyrdquo to create the sensor ontology

422 Candidate Selection (Process 2) The process selectseach candidate concept and each candidate link from theconcepts (C) and links (link) including the concept systemselected in Process 1 Type currently indicates the sevencomponents inheriting the concept

In Figure 8(a) ldquosupport Sensor (supportedBy) Sensor-Grounding (supports)rdquo is selected from links The selectedlink is added to candidate link and contained concepts

ldquoSensorrdquo and ldquoSensorGroundingrdquo are automatically added tocandidate concepts

423 Class and Relation Definition (Process 3) The processdefines the classes (119862119897) and relations (119877119890119897) of the ontologyschemamodel from the selected candidates A user selects thedesired candidate concept to define 119862119897 and selects candidatelinks to set the domain and range of Rel An 119877 including thecandidate link ismapped to a119877119890119897 of the ontologyThe domainand range are set during the selection of a candidate linkwith the roles of a subject and an object respectively A userselects each candidate to define the119862119897 and119877119890119897 of the ontologyschema model

In Figure 8(b) to define ldquoSystemrdquo isin 119862 in other do-mains ldquoMMI Ontologyrdquo isin 119862119878 is selected And ldquoSystemrdquois selected as candidate concepts and ldquoclass-subsumptionSensor (superclassOf) System (subclassOf)rdquo is selected ascandidate links The marked candidate link expresses ldquoclass-subsumptionrdquo which has (ldquoSensorrdquo ldquosubclassOfrdquo ldquoSystemrdquo)statement

424 Detailed Definition of Classes (Process 4) This processdefines classes (119862119897) and properties (119875) of the classes usingthe candidate concept and the type of concepts Additionalrelations (119877119890119897) are also created

In this process a user selects the candidate concepts Eachconcept has a type and has different mechanism to buildontologies according to the mapping model (119872119872) A userdefines119862119897 119875 119863119879 and additional 119877119890119897 of the ontology schemamodel When a candidate concept is selected the data thatcan be selected changes depending on its type so an ontologyis created containing the relations among components thatwere defined in the previous section

For example Figure 8(c) shows a screenshot of thedetailed definition of Cl in the ontology schema model Theselected candidate concept ldquoSystemrdquohas data element concept(DEC) type ldquohasSerialNumberrdquo isin 119875119903 becomes 119875 withldquoStringrdquo isin 119863119879 for ldquoSystemrdquo isin 119862119897 from ldquoSystem hasSerial-Number Stringrdquo isin 119863119864 associated with ldquoSystem hasSerial-numberrdquo isin 119863119864119862

425 The Created Ontology Figure 8(d) shows the completeontology for all processes The complete ontology is mainlycomprised of classes (119862119897) properties (119875) and relations (119877119890119897)P of each specific 119862119897 has a data type (119863119879) Rel has two 119862119897119904

with the roles of domain and rangeCaSOB provides a general ontology for a target ontology

It means that CaSOB does not provide specific ontologylanguages such as RDF OWL SKOS and Topic Map Thus auser needs to describe the complete ontology using a specificontology language Algorithm 1 shows the ontology createdin Figure 8(d) as described using OWL

5 Evaluation

51 Qualitative Evaluation We conducted a comparativeevaluation study for ontology creation This section first

8 International Journal of Distributed Sensor Networks

(a) (b)

(c) (d)

Figure 8 Screenshots of CaSOB

describes our qualitative evaluation using various com-parative items This evaluation involved the comparativeevaluation of three ontology building approaches which areuser-defined approach ontology reuse approach and ourproposedMDR based approach Table 1 shows the qualitativeevaluation results

The first factor for evaluation is standardization levelIt means whether the created ontology could be used as acommon or general ontology or not User-defined approachis hard to become a common standard approach because ofexperts who can create ontologies based on their own knowl-edge Hence created ontologies by user-defined approachcannot share their concept On the other hand since ontologyreuse approach and MDR based approach use ontologiesalready created which can contain common concepts cre-ated ontology using these ontology reuse and MDR basedapproaches can become standardized ontologies That is whyeach standardization level of these two approaches becomeshigh

The second evaluation factor is ontology quality Ontol-ogy quality means whether created ontologies are welldefined and whether the quality of created ontologies isguaranteed In case of user-defined approach a createdontology contains personal view point without general orcommon perspectiveTherefore the created ontology cannotguarantee the quality of ontologies CSIROMMI and ISTARontologies are popular ontologiesThese ontologies are one of

the results from each big projectThese ontologies are verifiedby a lot of experts whether concepts and relationships of theseontologies are well defined or not If we create a new ontologyreusing these well-defined ontologies we can guaranteesthe ontology quality In MDR based approach ontologiesand common concepts are controlled by MDR organizationsthat follow a standardized procedure for managing commonconcepts and reflect a standardized lifecycle for creatingontologies It means that the MDR-based ontology reuseapproach enables high-quality ontology creation

Limitation of expression means how the expressivepower is restricted when ontologies are created User-definedapproach has no limitation to express knowledge basedon ontologies because a user selects their own terms andthe user can make relationships following userrsquos opinionOntology reuse approach just uses existing ontologies It isnot allowed to change existing concepts and terms whenconcepts or terms are incorrect from target domainThus theexpression of ontology is very strict MDR based approachreuses registered ontologies in the metadata registry TheMDR based approach also permits changing other ontologieswhen there are no concepts or terms that are required inexisting ontologies Nevertheless the MDR approach is strictbecause it is not allowed to define unregistered ontologies

The final factor of qualitative evaluation is creation costCreation cost means convenience of creating ontologiesand time for building ontologies In user-defined approach

International Journal of Distributed Sensor Networks 9

ltxml version=ldquo10rdquogtltOntology xmlns=ldquohttpwwww3org200207owlrdquoxmlbase=ldquohttpsoftwarekoreaackrSwsysSensorOntologyowlrdquoxmlnsrdfs=ldquohttpwwww3org200001rdf-schemardquoxmlnsxsd=ldquohttpwwww3org2001XMLSchemardquoxmlnsrdf=ldquohttpwwww3org19990222-rdf-syntax-nsrdquoxmlnsxml=ldquohttpwwww3orgXML1998namespacerdquo

ltPrefix name=ldquoxsdrdquoIRI=ldquohttpwwww3org2001XMLSchemardquogt

ltPrefix name=ldquoowlrdquoIRI=ldquohttpwwww3org200207owlrdquogtltPrefix name=ldquordf rdquo IRI=ldquohttpwwww3org19990222-rdf-syntax-nsrdquogtltPrefix name=ldquordfsrdquo IRI=ldquohttpwwww3org200001rdf-schemardquogtltDeclarationgt

ltClass IRI=ldquoPhysicalQualityrdquogtltClass IRI=ldquoSensorrdquogtltClass IRI=ldquoSensorGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogtltClass IRI=ldquoSystemrdquogtltObjectProperty IRI=ldquosubclassOfrdquogtltObjectProperty IRI=ldquomeasurerdquogtltObjectProperty IRI=ldquomodelGroundingrdquogtltObjectProperty IRI=ldquosupportsrdquogtltDataProperty IRI=ldquoisConsumablerdquogtltDataProperty IRI=ldquohasSerialNumberrdquogt

ltDeclarationgtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSystemrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingtltObjectProperty IRI=ldquomeasurerdquogt

ltClass IRI=ldquoSensorrdquogtltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomeasurerdquogtltClass IRI=ldquoPhysicalQualityrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquoisConsumablerdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingt

Algorithm 1 Continued

10 International Journal of Distributed Sensor Networks

ltDataPropertyRangegtltDataProperty IRI=ldquoisConsumablerdquogtltDatatype abbreviatedIRI=ldquoxsdbooleanrdquogt

ltDataPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingtltDataPropertyRangegt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltDatatype abbreviatedIRI=ldquoxsdstringrdquogt

ltDataPropertyRangegtltOntologygt

Algorithm 1 An ontology described using OWL

Table 1 Qualitative evaluation of ontology building approaches

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

experts directly define concepts and terms and it requireshigh cost to survey domain knowledge and collect referencedocuments for verification Ontology reuse approach usesexisting ontologies without change if the existing ontologiescoincide with concepts and terms in target domainThus thecost for ontology creation is low MDR based approach usesontologies registered in ametadata registryWhen ontologiesare created users need to search terms and their relationsto apply the search result to new ontologies Users also needa customization task to create link between domains andranges Although this approach requires medium cost whichis higher cost than the cost of ontology reuse approachthe cost of MDR approach is lower than user-definedapproach

52 Quantitative Evaluation Simulation Approach This sec-tion describes our quantitative analysis which clearly showsthe advantages of the proposed system CaSOB Many sys-tems and studies have addressed interoperability betweenontologies However most focus on interoperability issueamong ontologies which have already been created withtheir own ontology schema definition rules Our approach isimplemented in the step before ontology creation which aimsto reuse common concepts and increase interoperabilityThispaper defines existing approaches as user-defined ontologyschema creation methods and we conducted a quantitativeevaluation to compare our method with the user-definedschema creationmethodThemetadata registry also providesno schema creation method because its purpose is to registerand share ontologies In other words our proposed method

CaSOB is based on the MDR but the metadata registry isexcluded from the quantitative evaluation

An appropriate comparative item was determined forthe evaluation The goal of this paper is to minimize thesemantic heterogeneity of ontologies via the reuse of commonconceptsTherefore this paper conducted a quantitative eval-uation of the semantic heterogeneity rate We can estimatethe approximate ontology integration cost using the semanticheterogeneity rate so this paper also includes the ontologyintegration cost as a comparative item

The evaluation methodology is summarized as follows

(i) comparative targets our proposed method CaSOBand the user-defined ontology schema creationmethod

(ii) comparative items the semantic heterogeneity ratethat is the number of heterogeneous semantics(concepts) shared among the created ontologies theontology integration cost that is the cost required tointegrate a set of created ontologies

The key symbols and notations are defined as follows

(i) 119874 a set of ontologies created with a target method119874 = 1199001 1199002 1199003 119900119899

(ii) 119900119894 a created ontology consisting of one or moresemantics that is a set of concepts such as classesrelations properties and data types

(iii) 119862 a set of common concepts registered and used forcreating an ontology

International Journal of Distributed Sensor Networks 11N

umbe

r of h

eter

ogen

eous

conc

epts

Case-1 the proposal is the almost worst case Case-2 the proposal is the average case

Case-3 the proposal is the almost best case

0100020003000400050006000700080009000

10000

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000N

umbe

r of h

eter

ogen

eous

conc

epts

0100020003000400050006000700080009000

10000Case-4 the proposal is from the almost best to the average⟩⟩⟩⟩

⟩⟩ ⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 9 Comparative evaluation results for the number of semantic heterogeneities

(iv) 119867119890119862119894 a set of heterogeneous concepts in the 119894th

ontology among the created ontologies(v) 119867119900119862 a set of homogeneous concepts among the

created ontologies(vi) 119899(119874) the number of created ontologies(vii) 119899(119900

119894) the number of concepts in the 119894th ontology

(viii) 119899(119862) the number of common concepts used to createan ontology

(ix) 119899(119867119890119862119894) the number of heterogeneous concepts inthe 119894th ontology

(x) 119903(119867119900119862) the average ratio of homogeneous concepts(xi) 119903(119862) the average ratio of used common concepts(xii) 119905 semantic interpretation time between two concepts

0 lt 119905 lt 1(xiii) 119878119867119873 the number of heterogeneous concepts(xiv) 119874119868119862 the ontology integration cost

For the evaluation we assume that 119899-people generate anontology in the same domain In this case the homogeneousconcept means concepts which are commonly contained bymost of the ontologies For example the concept such assensor could be a homogeneous concept even though eachof the sensor ontologies is developed by different people Onthe other hand the heterogeneous concept means discordantconcepts with each of the ontologies We assume that thenumber of heterogeneous concepts is the number of totalconcepts without an average ratio of homogeneous concepts

Figure 9 shows the comparative evaluation result for thesemantic heterogeneity as 119878119867119873 The evaluation determinesthe variation in the number of heterogeneous conceptsdepending on the change in the ratio of homogeneousconcepts and the ratio of used common concepts

119878119867119873119901119903119900119901119900119904119886119897

considers the common concepts used tobuild an ontology In other words it is the result of an evalua-tion using our proposedmethod 119878119867119873

119901119903119890V119894119900119906119904 is an evaluationresult using a user-defined schema creation method

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

International Journal of Distributed Sensor Networks 5

sensor

system

superclassOf

MDR concepts model Ontology schema model

subclassOfsystem

sensor

subclassOf

(2)

system

sensor

superclassOf

(1)

Class-subsumption

Rel

RelRR

RR

R

C

C

Cl

Cl Cl

Cl

Figure 3 The expected mapping results with 119877119906119897119890119862

MDR data description model Ontology schema model

system

string

hasSerialNumberhasSerialNumber

DE

DEC

Pr

VD

system

string

Cl

DT

P

OC

Figure 4 A mapping example using 119877119906119897119890119863

to map two 119903119890119897119886119905119894119900119899119904 by 119877119877 Thus a user needs to select asubject and an object when CaSOB uses rule (c) in 119877119906119897119890

119862

For example Figure 3 shows two expected mappingresults (1) and (2) where 119897119894119899119896 has two 119871119864119904 that islt ldquoSensorrdquo ldquosuperclassOfrdquo gt lt ldquoSystemrdquo ldquosubclassof rdquo gtisin 119871119864 whereas the mapping model cannot automaticallydetermine which 119871119864 becomes a subject or an object in119903119890119897119886119905119894119900119899 of the ontology schema model Thus a user needs toselect the subject and object of 119903119890119897119886119905119894119900119899 Because the subclassis typically more used than superclass in ontology languagethe user could select (1) as the mapping result expressed by119903119890119897119886119905119894119900119899subclassOf (ldquoSensorrdquo ldquoSystemrdquo)

The MDR data description model specifically describesthe meaning of metadata and provides an explanation ofthe concepts defined in the MDR concepts model Thesix tuples of the MDR data description model that is119862119863 119863119864119862 119874119862 119875119903 119881119872 and 119863119894119898 are inherited by 119862 in theMDR concepts model 119862 is expressed differently dependingon the property of the inherited tuples Thus each tupleis mapped to 119862119897 119875 or 119863119879 while most of the ontologiesmapped by RuleD are triple statements such as (119862119897 119875 and119863119879) 119862119863 119874119862 119881119872 and 119863119894119898 are only mapped to 119862119897 in thesix tuples because they are entities which are connected byother classes 119881119863 is mapped to 119863119879 although 119881119863 does notmean data type However 119881119863 contains a data type insideand 119863119864 contains 119881119863 not a data type directly Also if 119881119863 ismapped to 119863119879 we can define some special data types like 2-alpha country code 119875119903 is mapped to 119875 because 119875119903 indicatesan attribute of classes 119863119864119862 contains 119874119862 and 119875119903 so 119863119864119862 is

mapped to 119862119897 and 119875 both Similarly 119863119864 contains 119863119864119862 and119881119863 so119863119864 could be mapped to (119862119897 119875 119863119879) statement

Figure 4 shows a mapping example for 119877119906119897119890119863 The MDR

data description model expresses 119863119864 as ldquoSystem hasSerial-Numberrdquo with a ldquoStringrdquo data type where ldquoSystemrdquo isin 119874119862ldquohasSerialNumberrdquo isin 119875119903 ltldquoSystemrdquo ldquohasSerialNumberrdquogtisin 119863119864119862 and ldquoStringrdquo isin 119881119863 As a result the ontology schemamodel constructs a (ldquoSystemrdquo ldquohasSerialNumberrdquo ldquoStringrdquo)statement where ldquoSystem10158401015840 isin 119862119897 ldquohasSerialNumberrdquo isin P andldquoStringrdquo isin 119863119879

32 Ontology Building Process

321 Concept System Selection The first process for buildingontology is to decide a domain of an ontology If domains aredifferent from each other ontology meanings and relationsare different even if they have the same terminology Aconcept system includes the domain and scope of the dataThus CaSOB determines the domain of an ontology byselecting a concept system from 119862119878

In the first process shown in Figure 5 the concept systemldquoCSIRO Sensor Ontologyrdquo in 119862119878 is selected if a user wants tobuild an ontology in a sensor domain defined by CSIRO

322 Candidate Selection In the candidate selection processcandidates are selected to build an ontology Tuples of theMDR concepts model such as119862 119877 and 119897119894119899119896may be selectedas candidates The candidates are the same as the set of termsused when ontologies are created

119862 and link are selected from 119862119878 as candidate 119862 andcandidate 119897119894119899119896 respectively 119897119894119899119896 contains119862 119877 119877119877 and 119871119864 soboth candidate119862 and candidate 119897119894119899119896 can be selected from one119897119894119899119896 The selected 119897119894119899119896 becomes candidate 119897119894119899119896 119862 included in119897119894119899119896 is automatically selected as candidate 119862

The concept system ldquoCSIRO Sensor Ontologyrdquo is selectedduring the first step of Figure 5 The next step is to select theterms contained at the domain Candidates are selected suchas ldquoSensorrdquo ldquoSensorGroundingrdquo and ldquosupportsrdquo

323 Class and Relation Definition In the third process 119862119897and 119877119890119897 of the ontology schema model are defined by thecandidates A set of candidate concepts is defined for119862119897 whilea set of candidate links is defined for 119877119890119897

However CaSOB does not know the difference of 119877119877 for119862 such as the ldquoSubjectrdquo and ldquoObjectrdquo in an actual system Itis difficult to automatically determine roles simply by usingcandidate 119897119894119899119896 Thus a user has to determine the subject andobject of 119903119890119897119886119905119894119900119899 in the ontology schema model

In the third step shown in Figure 5119862119897 and119877119890119897 are definedusing the selected terms ldquoSensorrdquo ldquoSensorGroundingrdquo sub

119862119897 are defined while ldquosupportsrdquo isin 119877119890119897 is defined betweenldquoSensorrdquo as a subject and ldquoSensorGroundingrdquo as an object Inthis process it is possible to define concepts and relation overthe domains To define 119862119897 and 119877119890119897 in other domains we needto come back to the first process choose ldquoMMI Ontologyrdquoand select candidates for selecting terms defined in ldquoMMIOntologyrdquo domain Then Figure 5 shows ldquoSystemrdquo sub 119862119897

6 International Journal of Distributed Sensor Networks

TermsSensorSensorGroundingOperationModelSupportshasOperationModel

Concept system

CSIRO sensor ontology

MMI ontology

SensorOnto

Sensor

System SensorGrounding

subclassOf Supports

System

String

Boolean

hasSerialNumber

isConsumable

Created ontology schema

Sensor

System

SensorGrounding

Boolean

String

Supports

subclassOf

1 Concept system selection 2 Candidate selection 3 Class and relation definition

4 Detailed class definition

ClassData type

RelationProperty

hasSerialNumber

isConsumable

middot middot middotmiddot middot middot

Figure 5 An example of the ontology building process

is also defined and ldquosubclassOfrdquo isin 119877119890119897 is defined betweenldquoSensorrdquo as a subject and ldquoSystemrdquo as an object

324 Detailed Class Definition In the final process119875 and119863119879are defined to decide properties of classes and additionally119862119897and 119877119890119897 are defined by the mapping model

Because ldquoSystemrdquo isin 119862119897was defined in the previous step itis given that ldquohasSerialNumberrdquo isin 119875 with ldquoStringrdquo isin 119863119879 andldquoisConsumablerdquo isin 119875 using ldquoBooleanrdquo isin 119863119879 in the final stepof Figure 5

4 Implementation

This section describes a metadata registry and CaSOBimplementation To make easy connection and mappingmodel we need to implement a metadata registry based onMDR specification The metadata registry is implementedby MySQL database which is a RDBMS (relational databasemanagement system) For testing we need to store datasets inthe metadata registry so we select several sensor ontologiesas the dataset Then we assume that the selected ontologiescontained common concepts so the datasets stored in themetadata registry also contain common concepts CaSOB isdeveloped inC for a user interface database connection andthe ontology building processes

41 A Metadata Registry Implementation The metadata reg-istry is implemented so the MDR metamodel could collect

Figure 6 Implementation of the concepts region

data directly as required to import the administered meta-data and create an ontology Thus we initially develop themetadata registry by implementing the metamodel of MDRSection 41 presents the MDR-based system structured byRDBMS

Each component in the metamodel is defined as RDBMStable while properties of each component are defined as tableattributes Moreover associations between components aredefined using foreign key referential integrity

Figure 6 shows the table and foreign key references of theconcepts region in MDR The ldquoConceptrdquo table includes theattributes ldquoconceptrdquo and ldquosourcerdquo ldquoconceptrdquo is an attributewhere the name held by the concept of MDR is expressedusing strings ldquosourcerdquo is an attribute that expresses a concept

International Journal of Distributed Sensor Networks 7

Figure 7 Implementation of the data description region

system including concepts using foreign key referencesMoreover the ldquoLinkrdquo table has a ldquorelationrdquo attribute for theldquoRelationrdquo tableThe ldquoLink Endrdquo table has the attributes ldquoendrdquoand ldquorolerdquo for the ldquolinkrdquo attribute where ldquoendrdquo means theconcept ldquorolerdquo means the relation role and ldquolinkrdquo means thelink Thus one link has at least two link ends

In Figure 7 the data description region is implemented astables and foreign key references Seven components in thedata description region inherit the concept in the conceptsregion so the components express the inheritance using eachof the attributes of ldquoconceptrdquo and ldquoconcept sourcerdquo held in theldquoConceptrdquo table

42 CaSOB Implementation In Section 42 the ontologybuilding process of CaSOB is presentedwith the implementa-tion screen which is based on the four processes of ontologycreation

421 Concept System Selection (Process 1) If the domainof the ontology to be created has been determined thesystem searches and selects the concept system (CS) of thecorresponding domain In Figure 8(a) CS of Process 1 isselected in the upper right corner of the screen as ldquoCSIROSensor Ontologyrdquo to create the sensor ontology

422 Candidate Selection (Process 2) The process selectseach candidate concept and each candidate link from theconcepts (C) and links (link) including the concept systemselected in Process 1 Type currently indicates the sevencomponents inheriting the concept

In Figure 8(a) ldquosupport Sensor (supportedBy) Sensor-Grounding (supports)rdquo is selected from links The selectedlink is added to candidate link and contained concepts

ldquoSensorrdquo and ldquoSensorGroundingrdquo are automatically added tocandidate concepts

423 Class and Relation Definition (Process 3) The processdefines the classes (119862119897) and relations (119877119890119897) of the ontologyschemamodel from the selected candidates A user selects thedesired candidate concept to define 119862119897 and selects candidatelinks to set the domain and range of Rel An 119877 including thecandidate link ismapped to a119877119890119897 of the ontologyThe domainand range are set during the selection of a candidate linkwith the roles of a subject and an object respectively A userselects each candidate to define the119862119897 and119877119890119897 of the ontologyschema model

In Figure 8(b) to define ldquoSystemrdquo isin 119862 in other do-mains ldquoMMI Ontologyrdquo isin 119862119878 is selected And ldquoSystemrdquois selected as candidate concepts and ldquoclass-subsumptionSensor (superclassOf) System (subclassOf)rdquo is selected ascandidate links The marked candidate link expresses ldquoclass-subsumptionrdquo which has (ldquoSensorrdquo ldquosubclassOfrdquo ldquoSystemrdquo)statement

424 Detailed Definition of Classes (Process 4) This processdefines classes (119862119897) and properties (119875) of the classes usingthe candidate concept and the type of concepts Additionalrelations (119877119890119897) are also created

In this process a user selects the candidate concepts Eachconcept has a type and has different mechanism to buildontologies according to the mapping model (119872119872) A userdefines119862119897 119875 119863119879 and additional 119877119890119897 of the ontology schemamodel When a candidate concept is selected the data thatcan be selected changes depending on its type so an ontologyis created containing the relations among components thatwere defined in the previous section

For example Figure 8(c) shows a screenshot of thedetailed definition of Cl in the ontology schema model Theselected candidate concept ldquoSystemrdquohas data element concept(DEC) type ldquohasSerialNumberrdquo isin 119875119903 becomes 119875 withldquoStringrdquo isin 119863119879 for ldquoSystemrdquo isin 119862119897 from ldquoSystem hasSerial-Number Stringrdquo isin 119863119864 associated with ldquoSystem hasSerial-numberrdquo isin 119863119864119862

425 The Created Ontology Figure 8(d) shows the completeontology for all processes The complete ontology is mainlycomprised of classes (119862119897) properties (119875) and relations (119877119890119897)P of each specific 119862119897 has a data type (119863119879) Rel has two 119862119897119904

with the roles of domain and rangeCaSOB provides a general ontology for a target ontology

It means that CaSOB does not provide specific ontologylanguages such as RDF OWL SKOS and Topic Map Thus auser needs to describe the complete ontology using a specificontology language Algorithm 1 shows the ontology createdin Figure 8(d) as described using OWL

5 Evaluation

51 Qualitative Evaluation We conducted a comparativeevaluation study for ontology creation This section first

8 International Journal of Distributed Sensor Networks

(a) (b)

(c) (d)

Figure 8 Screenshots of CaSOB

describes our qualitative evaluation using various com-parative items This evaluation involved the comparativeevaluation of three ontology building approaches which areuser-defined approach ontology reuse approach and ourproposedMDR based approach Table 1 shows the qualitativeevaluation results

The first factor for evaluation is standardization levelIt means whether the created ontology could be used as acommon or general ontology or not User-defined approachis hard to become a common standard approach because ofexperts who can create ontologies based on their own knowl-edge Hence created ontologies by user-defined approachcannot share their concept On the other hand since ontologyreuse approach and MDR based approach use ontologiesalready created which can contain common concepts cre-ated ontology using these ontology reuse and MDR basedapproaches can become standardized ontologies That is whyeach standardization level of these two approaches becomeshigh

The second evaluation factor is ontology quality Ontol-ogy quality means whether created ontologies are welldefined and whether the quality of created ontologies isguaranteed In case of user-defined approach a createdontology contains personal view point without general orcommon perspectiveTherefore the created ontology cannotguarantee the quality of ontologies CSIROMMI and ISTARontologies are popular ontologiesThese ontologies are one of

the results from each big projectThese ontologies are verifiedby a lot of experts whether concepts and relationships of theseontologies are well defined or not If we create a new ontologyreusing these well-defined ontologies we can guaranteesthe ontology quality In MDR based approach ontologiesand common concepts are controlled by MDR organizationsthat follow a standardized procedure for managing commonconcepts and reflect a standardized lifecycle for creatingontologies It means that the MDR-based ontology reuseapproach enables high-quality ontology creation

Limitation of expression means how the expressivepower is restricted when ontologies are created User-definedapproach has no limitation to express knowledge basedon ontologies because a user selects their own terms andthe user can make relationships following userrsquos opinionOntology reuse approach just uses existing ontologies It isnot allowed to change existing concepts and terms whenconcepts or terms are incorrect from target domainThus theexpression of ontology is very strict MDR based approachreuses registered ontologies in the metadata registry TheMDR based approach also permits changing other ontologieswhen there are no concepts or terms that are required inexisting ontologies Nevertheless the MDR approach is strictbecause it is not allowed to define unregistered ontologies

The final factor of qualitative evaluation is creation costCreation cost means convenience of creating ontologiesand time for building ontologies In user-defined approach

International Journal of Distributed Sensor Networks 9

ltxml version=ldquo10rdquogtltOntology xmlns=ldquohttpwwww3org200207owlrdquoxmlbase=ldquohttpsoftwarekoreaackrSwsysSensorOntologyowlrdquoxmlnsrdfs=ldquohttpwwww3org200001rdf-schemardquoxmlnsxsd=ldquohttpwwww3org2001XMLSchemardquoxmlnsrdf=ldquohttpwwww3org19990222-rdf-syntax-nsrdquoxmlnsxml=ldquohttpwwww3orgXML1998namespacerdquo

ltPrefix name=ldquoxsdrdquoIRI=ldquohttpwwww3org2001XMLSchemardquogt

ltPrefix name=ldquoowlrdquoIRI=ldquohttpwwww3org200207owlrdquogtltPrefix name=ldquordf rdquo IRI=ldquohttpwwww3org19990222-rdf-syntax-nsrdquogtltPrefix name=ldquordfsrdquo IRI=ldquohttpwwww3org200001rdf-schemardquogtltDeclarationgt

ltClass IRI=ldquoPhysicalQualityrdquogtltClass IRI=ldquoSensorrdquogtltClass IRI=ldquoSensorGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogtltClass IRI=ldquoSystemrdquogtltObjectProperty IRI=ldquosubclassOfrdquogtltObjectProperty IRI=ldquomeasurerdquogtltObjectProperty IRI=ldquomodelGroundingrdquogtltObjectProperty IRI=ldquosupportsrdquogtltDataProperty IRI=ldquoisConsumablerdquogtltDataProperty IRI=ldquohasSerialNumberrdquogt

ltDeclarationgtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSystemrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingtltObjectProperty IRI=ldquomeasurerdquogt

ltClass IRI=ldquoSensorrdquogtltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomeasurerdquogtltClass IRI=ldquoPhysicalQualityrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquoisConsumablerdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingt

Algorithm 1 Continued

10 International Journal of Distributed Sensor Networks

ltDataPropertyRangegtltDataProperty IRI=ldquoisConsumablerdquogtltDatatype abbreviatedIRI=ldquoxsdbooleanrdquogt

ltDataPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingtltDataPropertyRangegt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltDatatype abbreviatedIRI=ldquoxsdstringrdquogt

ltDataPropertyRangegtltOntologygt

Algorithm 1 An ontology described using OWL

Table 1 Qualitative evaluation of ontology building approaches

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

experts directly define concepts and terms and it requireshigh cost to survey domain knowledge and collect referencedocuments for verification Ontology reuse approach usesexisting ontologies without change if the existing ontologiescoincide with concepts and terms in target domainThus thecost for ontology creation is low MDR based approach usesontologies registered in ametadata registryWhen ontologiesare created users need to search terms and their relationsto apply the search result to new ontologies Users also needa customization task to create link between domains andranges Although this approach requires medium cost whichis higher cost than the cost of ontology reuse approachthe cost of MDR approach is lower than user-definedapproach

52 Quantitative Evaluation Simulation Approach This sec-tion describes our quantitative analysis which clearly showsthe advantages of the proposed system CaSOB Many sys-tems and studies have addressed interoperability betweenontologies However most focus on interoperability issueamong ontologies which have already been created withtheir own ontology schema definition rules Our approach isimplemented in the step before ontology creation which aimsto reuse common concepts and increase interoperabilityThispaper defines existing approaches as user-defined ontologyschema creation methods and we conducted a quantitativeevaluation to compare our method with the user-definedschema creationmethodThemetadata registry also providesno schema creation method because its purpose is to registerand share ontologies In other words our proposed method

CaSOB is based on the MDR but the metadata registry isexcluded from the quantitative evaluation

An appropriate comparative item was determined forthe evaluation The goal of this paper is to minimize thesemantic heterogeneity of ontologies via the reuse of commonconceptsTherefore this paper conducted a quantitative eval-uation of the semantic heterogeneity rate We can estimatethe approximate ontology integration cost using the semanticheterogeneity rate so this paper also includes the ontologyintegration cost as a comparative item

The evaluation methodology is summarized as follows

(i) comparative targets our proposed method CaSOBand the user-defined ontology schema creationmethod

(ii) comparative items the semantic heterogeneity ratethat is the number of heterogeneous semantics(concepts) shared among the created ontologies theontology integration cost that is the cost required tointegrate a set of created ontologies

The key symbols and notations are defined as follows

(i) 119874 a set of ontologies created with a target method119874 = 1199001 1199002 1199003 119900119899

(ii) 119900119894 a created ontology consisting of one or moresemantics that is a set of concepts such as classesrelations properties and data types

(iii) 119862 a set of common concepts registered and used forcreating an ontology

International Journal of Distributed Sensor Networks 11N

umbe

r of h

eter

ogen

eous

conc

epts

Case-1 the proposal is the almost worst case Case-2 the proposal is the average case

Case-3 the proposal is the almost best case

0100020003000400050006000700080009000

10000

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000N

umbe

r of h

eter

ogen

eous

conc

epts

0100020003000400050006000700080009000

10000Case-4 the proposal is from the almost best to the average⟩⟩⟩⟩

⟩⟩ ⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 9 Comparative evaluation results for the number of semantic heterogeneities

(iv) 119867119890119862119894 a set of heterogeneous concepts in the 119894th

ontology among the created ontologies(v) 119867119900119862 a set of homogeneous concepts among the

created ontologies(vi) 119899(119874) the number of created ontologies(vii) 119899(119900

119894) the number of concepts in the 119894th ontology

(viii) 119899(119862) the number of common concepts used to createan ontology

(ix) 119899(119867119890119862119894) the number of heterogeneous concepts inthe 119894th ontology

(x) 119903(119867119900119862) the average ratio of homogeneous concepts(xi) 119903(119862) the average ratio of used common concepts(xii) 119905 semantic interpretation time between two concepts

0 lt 119905 lt 1(xiii) 119878119867119873 the number of heterogeneous concepts(xiv) 119874119868119862 the ontology integration cost

For the evaluation we assume that 119899-people generate anontology in the same domain In this case the homogeneousconcept means concepts which are commonly contained bymost of the ontologies For example the concept such assensor could be a homogeneous concept even though eachof the sensor ontologies is developed by different people Onthe other hand the heterogeneous concept means discordantconcepts with each of the ontologies We assume that thenumber of heterogeneous concepts is the number of totalconcepts without an average ratio of homogeneous concepts

Figure 9 shows the comparative evaluation result for thesemantic heterogeneity as 119878119867119873 The evaluation determinesthe variation in the number of heterogeneous conceptsdepending on the change in the ratio of homogeneousconcepts and the ratio of used common concepts

119878119867119873119901119903119900119901119900119904119886119897

considers the common concepts used tobuild an ontology In other words it is the result of an evalua-tion using our proposedmethod 119878119867119873

119901119903119890V119894119900119906119904 is an evaluationresult using a user-defined schema creation method

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

6 International Journal of Distributed Sensor Networks

TermsSensorSensorGroundingOperationModelSupportshasOperationModel

Concept system

CSIRO sensor ontology

MMI ontology

SensorOnto

Sensor

System SensorGrounding

subclassOf Supports

System

String

Boolean

hasSerialNumber

isConsumable

Created ontology schema

Sensor

System

SensorGrounding

Boolean

String

Supports

subclassOf

1 Concept system selection 2 Candidate selection 3 Class and relation definition

4 Detailed class definition

ClassData type

RelationProperty

hasSerialNumber

isConsumable

middot middot middotmiddot middot middot

Figure 5 An example of the ontology building process

is also defined and ldquosubclassOfrdquo isin 119877119890119897 is defined betweenldquoSensorrdquo as a subject and ldquoSystemrdquo as an object

324 Detailed Class Definition In the final process119875 and119863119879are defined to decide properties of classes and additionally119862119897and 119877119890119897 are defined by the mapping model

Because ldquoSystemrdquo isin 119862119897was defined in the previous step itis given that ldquohasSerialNumberrdquo isin 119875 with ldquoStringrdquo isin 119863119879 andldquoisConsumablerdquo isin 119875 using ldquoBooleanrdquo isin 119863119879 in the final stepof Figure 5

4 Implementation

This section describes a metadata registry and CaSOBimplementation To make easy connection and mappingmodel we need to implement a metadata registry based onMDR specification The metadata registry is implementedby MySQL database which is a RDBMS (relational databasemanagement system) For testing we need to store datasets inthe metadata registry so we select several sensor ontologiesas the dataset Then we assume that the selected ontologiescontained common concepts so the datasets stored in themetadata registry also contain common concepts CaSOB isdeveloped inC for a user interface database connection andthe ontology building processes

41 A Metadata Registry Implementation The metadata reg-istry is implemented so the MDR metamodel could collect

Figure 6 Implementation of the concepts region

data directly as required to import the administered meta-data and create an ontology Thus we initially develop themetadata registry by implementing the metamodel of MDRSection 41 presents the MDR-based system structured byRDBMS

Each component in the metamodel is defined as RDBMStable while properties of each component are defined as tableattributes Moreover associations between components aredefined using foreign key referential integrity

Figure 6 shows the table and foreign key references of theconcepts region in MDR The ldquoConceptrdquo table includes theattributes ldquoconceptrdquo and ldquosourcerdquo ldquoconceptrdquo is an attributewhere the name held by the concept of MDR is expressedusing strings ldquosourcerdquo is an attribute that expresses a concept

International Journal of Distributed Sensor Networks 7

Figure 7 Implementation of the data description region

system including concepts using foreign key referencesMoreover the ldquoLinkrdquo table has a ldquorelationrdquo attribute for theldquoRelationrdquo tableThe ldquoLink Endrdquo table has the attributes ldquoendrdquoand ldquorolerdquo for the ldquolinkrdquo attribute where ldquoendrdquo means theconcept ldquorolerdquo means the relation role and ldquolinkrdquo means thelink Thus one link has at least two link ends

In Figure 7 the data description region is implemented astables and foreign key references Seven components in thedata description region inherit the concept in the conceptsregion so the components express the inheritance using eachof the attributes of ldquoconceptrdquo and ldquoconcept sourcerdquo held in theldquoConceptrdquo table

42 CaSOB Implementation In Section 42 the ontologybuilding process of CaSOB is presentedwith the implementa-tion screen which is based on the four processes of ontologycreation

421 Concept System Selection (Process 1) If the domainof the ontology to be created has been determined thesystem searches and selects the concept system (CS) of thecorresponding domain In Figure 8(a) CS of Process 1 isselected in the upper right corner of the screen as ldquoCSIROSensor Ontologyrdquo to create the sensor ontology

422 Candidate Selection (Process 2) The process selectseach candidate concept and each candidate link from theconcepts (C) and links (link) including the concept systemselected in Process 1 Type currently indicates the sevencomponents inheriting the concept

In Figure 8(a) ldquosupport Sensor (supportedBy) Sensor-Grounding (supports)rdquo is selected from links The selectedlink is added to candidate link and contained concepts

ldquoSensorrdquo and ldquoSensorGroundingrdquo are automatically added tocandidate concepts

423 Class and Relation Definition (Process 3) The processdefines the classes (119862119897) and relations (119877119890119897) of the ontologyschemamodel from the selected candidates A user selects thedesired candidate concept to define 119862119897 and selects candidatelinks to set the domain and range of Rel An 119877 including thecandidate link ismapped to a119877119890119897 of the ontologyThe domainand range are set during the selection of a candidate linkwith the roles of a subject and an object respectively A userselects each candidate to define the119862119897 and119877119890119897 of the ontologyschema model

In Figure 8(b) to define ldquoSystemrdquo isin 119862 in other do-mains ldquoMMI Ontologyrdquo isin 119862119878 is selected And ldquoSystemrdquois selected as candidate concepts and ldquoclass-subsumptionSensor (superclassOf) System (subclassOf)rdquo is selected ascandidate links The marked candidate link expresses ldquoclass-subsumptionrdquo which has (ldquoSensorrdquo ldquosubclassOfrdquo ldquoSystemrdquo)statement

424 Detailed Definition of Classes (Process 4) This processdefines classes (119862119897) and properties (119875) of the classes usingthe candidate concept and the type of concepts Additionalrelations (119877119890119897) are also created

In this process a user selects the candidate concepts Eachconcept has a type and has different mechanism to buildontologies according to the mapping model (119872119872) A userdefines119862119897 119875 119863119879 and additional 119877119890119897 of the ontology schemamodel When a candidate concept is selected the data thatcan be selected changes depending on its type so an ontologyis created containing the relations among components thatwere defined in the previous section

For example Figure 8(c) shows a screenshot of thedetailed definition of Cl in the ontology schema model Theselected candidate concept ldquoSystemrdquohas data element concept(DEC) type ldquohasSerialNumberrdquo isin 119875119903 becomes 119875 withldquoStringrdquo isin 119863119879 for ldquoSystemrdquo isin 119862119897 from ldquoSystem hasSerial-Number Stringrdquo isin 119863119864 associated with ldquoSystem hasSerial-numberrdquo isin 119863119864119862

425 The Created Ontology Figure 8(d) shows the completeontology for all processes The complete ontology is mainlycomprised of classes (119862119897) properties (119875) and relations (119877119890119897)P of each specific 119862119897 has a data type (119863119879) Rel has two 119862119897119904

with the roles of domain and rangeCaSOB provides a general ontology for a target ontology

It means that CaSOB does not provide specific ontologylanguages such as RDF OWL SKOS and Topic Map Thus auser needs to describe the complete ontology using a specificontology language Algorithm 1 shows the ontology createdin Figure 8(d) as described using OWL

5 Evaluation

51 Qualitative Evaluation We conducted a comparativeevaluation study for ontology creation This section first

8 International Journal of Distributed Sensor Networks

(a) (b)

(c) (d)

Figure 8 Screenshots of CaSOB

describes our qualitative evaluation using various com-parative items This evaluation involved the comparativeevaluation of three ontology building approaches which areuser-defined approach ontology reuse approach and ourproposedMDR based approach Table 1 shows the qualitativeevaluation results

The first factor for evaluation is standardization levelIt means whether the created ontology could be used as acommon or general ontology or not User-defined approachis hard to become a common standard approach because ofexperts who can create ontologies based on their own knowl-edge Hence created ontologies by user-defined approachcannot share their concept On the other hand since ontologyreuse approach and MDR based approach use ontologiesalready created which can contain common concepts cre-ated ontology using these ontology reuse and MDR basedapproaches can become standardized ontologies That is whyeach standardization level of these two approaches becomeshigh

The second evaluation factor is ontology quality Ontol-ogy quality means whether created ontologies are welldefined and whether the quality of created ontologies isguaranteed In case of user-defined approach a createdontology contains personal view point without general orcommon perspectiveTherefore the created ontology cannotguarantee the quality of ontologies CSIROMMI and ISTARontologies are popular ontologiesThese ontologies are one of

the results from each big projectThese ontologies are verifiedby a lot of experts whether concepts and relationships of theseontologies are well defined or not If we create a new ontologyreusing these well-defined ontologies we can guaranteesthe ontology quality In MDR based approach ontologiesand common concepts are controlled by MDR organizationsthat follow a standardized procedure for managing commonconcepts and reflect a standardized lifecycle for creatingontologies It means that the MDR-based ontology reuseapproach enables high-quality ontology creation

Limitation of expression means how the expressivepower is restricted when ontologies are created User-definedapproach has no limitation to express knowledge basedon ontologies because a user selects their own terms andthe user can make relationships following userrsquos opinionOntology reuse approach just uses existing ontologies It isnot allowed to change existing concepts and terms whenconcepts or terms are incorrect from target domainThus theexpression of ontology is very strict MDR based approachreuses registered ontologies in the metadata registry TheMDR based approach also permits changing other ontologieswhen there are no concepts or terms that are required inexisting ontologies Nevertheless the MDR approach is strictbecause it is not allowed to define unregistered ontologies

The final factor of qualitative evaluation is creation costCreation cost means convenience of creating ontologiesand time for building ontologies In user-defined approach

International Journal of Distributed Sensor Networks 9

ltxml version=ldquo10rdquogtltOntology xmlns=ldquohttpwwww3org200207owlrdquoxmlbase=ldquohttpsoftwarekoreaackrSwsysSensorOntologyowlrdquoxmlnsrdfs=ldquohttpwwww3org200001rdf-schemardquoxmlnsxsd=ldquohttpwwww3org2001XMLSchemardquoxmlnsrdf=ldquohttpwwww3org19990222-rdf-syntax-nsrdquoxmlnsxml=ldquohttpwwww3orgXML1998namespacerdquo

ltPrefix name=ldquoxsdrdquoIRI=ldquohttpwwww3org2001XMLSchemardquogt

ltPrefix name=ldquoowlrdquoIRI=ldquohttpwwww3org200207owlrdquogtltPrefix name=ldquordf rdquo IRI=ldquohttpwwww3org19990222-rdf-syntax-nsrdquogtltPrefix name=ldquordfsrdquo IRI=ldquohttpwwww3org200001rdf-schemardquogtltDeclarationgt

ltClass IRI=ldquoPhysicalQualityrdquogtltClass IRI=ldquoSensorrdquogtltClass IRI=ldquoSensorGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogtltClass IRI=ldquoSystemrdquogtltObjectProperty IRI=ldquosubclassOfrdquogtltObjectProperty IRI=ldquomeasurerdquogtltObjectProperty IRI=ldquomodelGroundingrdquogtltObjectProperty IRI=ldquosupportsrdquogtltDataProperty IRI=ldquoisConsumablerdquogtltDataProperty IRI=ldquohasSerialNumberrdquogt

ltDeclarationgtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSystemrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingtltObjectProperty IRI=ldquomeasurerdquogt

ltClass IRI=ldquoSensorrdquogtltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomeasurerdquogtltClass IRI=ldquoPhysicalQualityrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquoisConsumablerdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingt

Algorithm 1 Continued

10 International Journal of Distributed Sensor Networks

ltDataPropertyRangegtltDataProperty IRI=ldquoisConsumablerdquogtltDatatype abbreviatedIRI=ldquoxsdbooleanrdquogt

ltDataPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingtltDataPropertyRangegt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltDatatype abbreviatedIRI=ldquoxsdstringrdquogt

ltDataPropertyRangegtltOntologygt

Algorithm 1 An ontology described using OWL

Table 1 Qualitative evaluation of ontology building approaches

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

experts directly define concepts and terms and it requireshigh cost to survey domain knowledge and collect referencedocuments for verification Ontology reuse approach usesexisting ontologies without change if the existing ontologiescoincide with concepts and terms in target domainThus thecost for ontology creation is low MDR based approach usesontologies registered in ametadata registryWhen ontologiesare created users need to search terms and their relationsto apply the search result to new ontologies Users also needa customization task to create link between domains andranges Although this approach requires medium cost whichis higher cost than the cost of ontology reuse approachthe cost of MDR approach is lower than user-definedapproach

52 Quantitative Evaluation Simulation Approach This sec-tion describes our quantitative analysis which clearly showsthe advantages of the proposed system CaSOB Many sys-tems and studies have addressed interoperability betweenontologies However most focus on interoperability issueamong ontologies which have already been created withtheir own ontology schema definition rules Our approach isimplemented in the step before ontology creation which aimsto reuse common concepts and increase interoperabilityThispaper defines existing approaches as user-defined ontologyschema creation methods and we conducted a quantitativeevaluation to compare our method with the user-definedschema creationmethodThemetadata registry also providesno schema creation method because its purpose is to registerand share ontologies In other words our proposed method

CaSOB is based on the MDR but the metadata registry isexcluded from the quantitative evaluation

An appropriate comparative item was determined forthe evaluation The goal of this paper is to minimize thesemantic heterogeneity of ontologies via the reuse of commonconceptsTherefore this paper conducted a quantitative eval-uation of the semantic heterogeneity rate We can estimatethe approximate ontology integration cost using the semanticheterogeneity rate so this paper also includes the ontologyintegration cost as a comparative item

The evaluation methodology is summarized as follows

(i) comparative targets our proposed method CaSOBand the user-defined ontology schema creationmethod

(ii) comparative items the semantic heterogeneity ratethat is the number of heterogeneous semantics(concepts) shared among the created ontologies theontology integration cost that is the cost required tointegrate a set of created ontologies

The key symbols and notations are defined as follows

(i) 119874 a set of ontologies created with a target method119874 = 1199001 1199002 1199003 119900119899

(ii) 119900119894 a created ontology consisting of one or moresemantics that is a set of concepts such as classesrelations properties and data types

(iii) 119862 a set of common concepts registered and used forcreating an ontology

International Journal of Distributed Sensor Networks 11N

umbe

r of h

eter

ogen

eous

conc

epts

Case-1 the proposal is the almost worst case Case-2 the proposal is the average case

Case-3 the proposal is the almost best case

0100020003000400050006000700080009000

10000

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000N

umbe

r of h

eter

ogen

eous

conc

epts

0100020003000400050006000700080009000

10000Case-4 the proposal is from the almost best to the average⟩⟩⟩⟩

⟩⟩ ⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 9 Comparative evaluation results for the number of semantic heterogeneities

(iv) 119867119890119862119894 a set of heterogeneous concepts in the 119894th

ontology among the created ontologies(v) 119867119900119862 a set of homogeneous concepts among the

created ontologies(vi) 119899(119874) the number of created ontologies(vii) 119899(119900

119894) the number of concepts in the 119894th ontology

(viii) 119899(119862) the number of common concepts used to createan ontology

(ix) 119899(119867119890119862119894) the number of heterogeneous concepts inthe 119894th ontology

(x) 119903(119867119900119862) the average ratio of homogeneous concepts(xi) 119903(119862) the average ratio of used common concepts(xii) 119905 semantic interpretation time between two concepts

0 lt 119905 lt 1(xiii) 119878119867119873 the number of heterogeneous concepts(xiv) 119874119868119862 the ontology integration cost

For the evaluation we assume that 119899-people generate anontology in the same domain In this case the homogeneousconcept means concepts which are commonly contained bymost of the ontologies For example the concept such assensor could be a homogeneous concept even though eachof the sensor ontologies is developed by different people Onthe other hand the heterogeneous concept means discordantconcepts with each of the ontologies We assume that thenumber of heterogeneous concepts is the number of totalconcepts without an average ratio of homogeneous concepts

Figure 9 shows the comparative evaluation result for thesemantic heterogeneity as 119878119867119873 The evaluation determinesthe variation in the number of heterogeneous conceptsdepending on the change in the ratio of homogeneousconcepts and the ratio of used common concepts

119878119867119873119901119903119900119901119900119904119886119897

considers the common concepts used tobuild an ontology In other words it is the result of an evalua-tion using our proposedmethod 119878119867119873

119901119903119890V119894119900119906119904 is an evaluationresult using a user-defined schema creation method

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

International Journal of Distributed Sensor Networks 7

Figure 7 Implementation of the data description region

system including concepts using foreign key referencesMoreover the ldquoLinkrdquo table has a ldquorelationrdquo attribute for theldquoRelationrdquo tableThe ldquoLink Endrdquo table has the attributes ldquoendrdquoand ldquorolerdquo for the ldquolinkrdquo attribute where ldquoendrdquo means theconcept ldquorolerdquo means the relation role and ldquolinkrdquo means thelink Thus one link has at least two link ends

In Figure 7 the data description region is implemented astables and foreign key references Seven components in thedata description region inherit the concept in the conceptsregion so the components express the inheritance using eachof the attributes of ldquoconceptrdquo and ldquoconcept sourcerdquo held in theldquoConceptrdquo table

42 CaSOB Implementation In Section 42 the ontologybuilding process of CaSOB is presentedwith the implementa-tion screen which is based on the four processes of ontologycreation

421 Concept System Selection (Process 1) If the domainof the ontology to be created has been determined thesystem searches and selects the concept system (CS) of thecorresponding domain In Figure 8(a) CS of Process 1 isselected in the upper right corner of the screen as ldquoCSIROSensor Ontologyrdquo to create the sensor ontology

422 Candidate Selection (Process 2) The process selectseach candidate concept and each candidate link from theconcepts (C) and links (link) including the concept systemselected in Process 1 Type currently indicates the sevencomponents inheriting the concept

In Figure 8(a) ldquosupport Sensor (supportedBy) Sensor-Grounding (supports)rdquo is selected from links The selectedlink is added to candidate link and contained concepts

ldquoSensorrdquo and ldquoSensorGroundingrdquo are automatically added tocandidate concepts

423 Class and Relation Definition (Process 3) The processdefines the classes (119862119897) and relations (119877119890119897) of the ontologyschemamodel from the selected candidates A user selects thedesired candidate concept to define 119862119897 and selects candidatelinks to set the domain and range of Rel An 119877 including thecandidate link ismapped to a119877119890119897 of the ontologyThe domainand range are set during the selection of a candidate linkwith the roles of a subject and an object respectively A userselects each candidate to define the119862119897 and119877119890119897 of the ontologyschema model

In Figure 8(b) to define ldquoSystemrdquo isin 119862 in other do-mains ldquoMMI Ontologyrdquo isin 119862119878 is selected And ldquoSystemrdquois selected as candidate concepts and ldquoclass-subsumptionSensor (superclassOf) System (subclassOf)rdquo is selected ascandidate links The marked candidate link expresses ldquoclass-subsumptionrdquo which has (ldquoSensorrdquo ldquosubclassOfrdquo ldquoSystemrdquo)statement

424 Detailed Definition of Classes (Process 4) This processdefines classes (119862119897) and properties (119875) of the classes usingthe candidate concept and the type of concepts Additionalrelations (119877119890119897) are also created

In this process a user selects the candidate concepts Eachconcept has a type and has different mechanism to buildontologies according to the mapping model (119872119872) A userdefines119862119897 119875 119863119879 and additional 119877119890119897 of the ontology schemamodel When a candidate concept is selected the data thatcan be selected changes depending on its type so an ontologyis created containing the relations among components thatwere defined in the previous section

For example Figure 8(c) shows a screenshot of thedetailed definition of Cl in the ontology schema model Theselected candidate concept ldquoSystemrdquohas data element concept(DEC) type ldquohasSerialNumberrdquo isin 119875119903 becomes 119875 withldquoStringrdquo isin 119863119879 for ldquoSystemrdquo isin 119862119897 from ldquoSystem hasSerial-Number Stringrdquo isin 119863119864 associated with ldquoSystem hasSerial-numberrdquo isin 119863119864119862

425 The Created Ontology Figure 8(d) shows the completeontology for all processes The complete ontology is mainlycomprised of classes (119862119897) properties (119875) and relations (119877119890119897)P of each specific 119862119897 has a data type (119863119879) Rel has two 119862119897119904

with the roles of domain and rangeCaSOB provides a general ontology for a target ontology

It means that CaSOB does not provide specific ontologylanguages such as RDF OWL SKOS and Topic Map Thus auser needs to describe the complete ontology using a specificontology language Algorithm 1 shows the ontology createdin Figure 8(d) as described using OWL

5 Evaluation

51 Qualitative Evaluation We conducted a comparativeevaluation study for ontology creation This section first

8 International Journal of Distributed Sensor Networks

(a) (b)

(c) (d)

Figure 8 Screenshots of CaSOB

describes our qualitative evaluation using various com-parative items This evaluation involved the comparativeevaluation of three ontology building approaches which areuser-defined approach ontology reuse approach and ourproposedMDR based approach Table 1 shows the qualitativeevaluation results

The first factor for evaluation is standardization levelIt means whether the created ontology could be used as acommon or general ontology or not User-defined approachis hard to become a common standard approach because ofexperts who can create ontologies based on their own knowl-edge Hence created ontologies by user-defined approachcannot share their concept On the other hand since ontologyreuse approach and MDR based approach use ontologiesalready created which can contain common concepts cre-ated ontology using these ontology reuse and MDR basedapproaches can become standardized ontologies That is whyeach standardization level of these two approaches becomeshigh

The second evaluation factor is ontology quality Ontol-ogy quality means whether created ontologies are welldefined and whether the quality of created ontologies isguaranteed In case of user-defined approach a createdontology contains personal view point without general orcommon perspectiveTherefore the created ontology cannotguarantee the quality of ontologies CSIROMMI and ISTARontologies are popular ontologiesThese ontologies are one of

the results from each big projectThese ontologies are verifiedby a lot of experts whether concepts and relationships of theseontologies are well defined or not If we create a new ontologyreusing these well-defined ontologies we can guaranteesthe ontology quality In MDR based approach ontologiesand common concepts are controlled by MDR organizationsthat follow a standardized procedure for managing commonconcepts and reflect a standardized lifecycle for creatingontologies It means that the MDR-based ontology reuseapproach enables high-quality ontology creation

Limitation of expression means how the expressivepower is restricted when ontologies are created User-definedapproach has no limitation to express knowledge basedon ontologies because a user selects their own terms andthe user can make relationships following userrsquos opinionOntology reuse approach just uses existing ontologies It isnot allowed to change existing concepts and terms whenconcepts or terms are incorrect from target domainThus theexpression of ontology is very strict MDR based approachreuses registered ontologies in the metadata registry TheMDR based approach also permits changing other ontologieswhen there are no concepts or terms that are required inexisting ontologies Nevertheless the MDR approach is strictbecause it is not allowed to define unregistered ontologies

The final factor of qualitative evaluation is creation costCreation cost means convenience of creating ontologiesand time for building ontologies In user-defined approach

International Journal of Distributed Sensor Networks 9

ltxml version=ldquo10rdquogtltOntology xmlns=ldquohttpwwww3org200207owlrdquoxmlbase=ldquohttpsoftwarekoreaackrSwsysSensorOntologyowlrdquoxmlnsrdfs=ldquohttpwwww3org200001rdf-schemardquoxmlnsxsd=ldquohttpwwww3org2001XMLSchemardquoxmlnsrdf=ldquohttpwwww3org19990222-rdf-syntax-nsrdquoxmlnsxml=ldquohttpwwww3orgXML1998namespacerdquo

ltPrefix name=ldquoxsdrdquoIRI=ldquohttpwwww3org2001XMLSchemardquogt

ltPrefix name=ldquoowlrdquoIRI=ldquohttpwwww3org200207owlrdquogtltPrefix name=ldquordf rdquo IRI=ldquohttpwwww3org19990222-rdf-syntax-nsrdquogtltPrefix name=ldquordfsrdquo IRI=ldquohttpwwww3org200001rdf-schemardquogtltDeclarationgt

ltClass IRI=ldquoPhysicalQualityrdquogtltClass IRI=ldquoSensorrdquogtltClass IRI=ldquoSensorGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogtltClass IRI=ldquoSystemrdquogtltObjectProperty IRI=ldquosubclassOfrdquogtltObjectProperty IRI=ldquomeasurerdquogtltObjectProperty IRI=ldquomodelGroundingrdquogtltObjectProperty IRI=ldquosupportsrdquogtltDataProperty IRI=ldquoisConsumablerdquogtltDataProperty IRI=ldquohasSerialNumberrdquogt

ltDeclarationgtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSystemrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingtltObjectProperty IRI=ldquomeasurerdquogt

ltClass IRI=ldquoSensorrdquogtltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomeasurerdquogtltClass IRI=ldquoPhysicalQualityrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquoisConsumablerdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingt

Algorithm 1 Continued

10 International Journal of Distributed Sensor Networks

ltDataPropertyRangegtltDataProperty IRI=ldquoisConsumablerdquogtltDatatype abbreviatedIRI=ldquoxsdbooleanrdquogt

ltDataPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingtltDataPropertyRangegt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltDatatype abbreviatedIRI=ldquoxsdstringrdquogt

ltDataPropertyRangegtltOntologygt

Algorithm 1 An ontology described using OWL

Table 1 Qualitative evaluation of ontology building approaches

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

experts directly define concepts and terms and it requireshigh cost to survey domain knowledge and collect referencedocuments for verification Ontology reuse approach usesexisting ontologies without change if the existing ontologiescoincide with concepts and terms in target domainThus thecost for ontology creation is low MDR based approach usesontologies registered in ametadata registryWhen ontologiesare created users need to search terms and their relationsto apply the search result to new ontologies Users also needa customization task to create link between domains andranges Although this approach requires medium cost whichis higher cost than the cost of ontology reuse approachthe cost of MDR approach is lower than user-definedapproach

52 Quantitative Evaluation Simulation Approach This sec-tion describes our quantitative analysis which clearly showsthe advantages of the proposed system CaSOB Many sys-tems and studies have addressed interoperability betweenontologies However most focus on interoperability issueamong ontologies which have already been created withtheir own ontology schema definition rules Our approach isimplemented in the step before ontology creation which aimsto reuse common concepts and increase interoperabilityThispaper defines existing approaches as user-defined ontologyschema creation methods and we conducted a quantitativeevaluation to compare our method with the user-definedschema creationmethodThemetadata registry also providesno schema creation method because its purpose is to registerand share ontologies In other words our proposed method

CaSOB is based on the MDR but the metadata registry isexcluded from the quantitative evaluation

An appropriate comparative item was determined forthe evaluation The goal of this paper is to minimize thesemantic heterogeneity of ontologies via the reuse of commonconceptsTherefore this paper conducted a quantitative eval-uation of the semantic heterogeneity rate We can estimatethe approximate ontology integration cost using the semanticheterogeneity rate so this paper also includes the ontologyintegration cost as a comparative item

The evaluation methodology is summarized as follows

(i) comparative targets our proposed method CaSOBand the user-defined ontology schema creationmethod

(ii) comparative items the semantic heterogeneity ratethat is the number of heterogeneous semantics(concepts) shared among the created ontologies theontology integration cost that is the cost required tointegrate a set of created ontologies

The key symbols and notations are defined as follows

(i) 119874 a set of ontologies created with a target method119874 = 1199001 1199002 1199003 119900119899

(ii) 119900119894 a created ontology consisting of one or moresemantics that is a set of concepts such as classesrelations properties and data types

(iii) 119862 a set of common concepts registered and used forcreating an ontology

International Journal of Distributed Sensor Networks 11N

umbe

r of h

eter

ogen

eous

conc

epts

Case-1 the proposal is the almost worst case Case-2 the proposal is the average case

Case-3 the proposal is the almost best case

0100020003000400050006000700080009000

10000

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000N

umbe

r of h

eter

ogen

eous

conc

epts

0100020003000400050006000700080009000

10000Case-4 the proposal is from the almost best to the average⟩⟩⟩⟩

⟩⟩ ⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 9 Comparative evaluation results for the number of semantic heterogeneities

(iv) 119867119890119862119894 a set of heterogeneous concepts in the 119894th

ontology among the created ontologies(v) 119867119900119862 a set of homogeneous concepts among the

created ontologies(vi) 119899(119874) the number of created ontologies(vii) 119899(119900

119894) the number of concepts in the 119894th ontology

(viii) 119899(119862) the number of common concepts used to createan ontology

(ix) 119899(119867119890119862119894) the number of heterogeneous concepts inthe 119894th ontology

(x) 119903(119867119900119862) the average ratio of homogeneous concepts(xi) 119903(119862) the average ratio of used common concepts(xii) 119905 semantic interpretation time between two concepts

0 lt 119905 lt 1(xiii) 119878119867119873 the number of heterogeneous concepts(xiv) 119874119868119862 the ontology integration cost

For the evaluation we assume that 119899-people generate anontology in the same domain In this case the homogeneousconcept means concepts which are commonly contained bymost of the ontologies For example the concept such assensor could be a homogeneous concept even though eachof the sensor ontologies is developed by different people Onthe other hand the heterogeneous concept means discordantconcepts with each of the ontologies We assume that thenumber of heterogeneous concepts is the number of totalconcepts without an average ratio of homogeneous concepts

Figure 9 shows the comparative evaluation result for thesemantic heterogeneity as 119878119867119873 The evaluation determinesthe variation in the number of heterogeneous conceptsdepending on the change in the ratio of homogeneousconcepts and the ratio of used common concepts

119878119867119873119901119903119900119901119900119904119886119897

considers the common concepts used tobuild an ontology In other words it is the result of an evalua-tion using our proposedmethod 119878119867119873

119901119903119890V119894119900119906119904 is an evaluationresult using a user-defined schema creation method

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

8 International Journal of Distributed Sensor Networks

(a) (b)

(c) (d)

Figure 8 Screenshots of CaSOB

describes our qualitative evaluation using various com-parative items This evaluation involved the comparativeevaluation of three ontology building approaches which areuser-defined approach ontology reuse approach and ourproposedMDR based approach Table 1 shows the qualitativeevaluation results

The first factor for evaluation is standardization levelIt means whether the created ontology could be used as acommon or general ontology or not User-defined approachis hard to become a common standard approach because ofexperts who can create ontologies based on their own knowl-edge Hence created ontologies by user-defined approachcannot share their concept On the other hand since ontologyreuse approach and MDR based approach use ontologiesalready created which can contain common concepts cre-ated ontology using these ontology reuse and MDR basedapproaches can become standardized ontologies That is whyeach standardization level of these two approaches becomeshigh

The second evaluation factor is ontology quality Ontol-ogy quality means whether created ontologies are welldefined and whether the quality of created ontologies isguaranteed In case of user-defined approach a createdontology contains personal view point without general orcommon perspectiveTherefore the created ontology cannotguarantee the quality of ontologies CSIROMMI and ISTARontologies are popular ontologiesThese ontologies are one of

the results from each big projectThese ontologies are verifiedby a lot of experts whether concepts and relationships of theseontologies are well defined or not If we create a new ontologyreusing these well-defined ontologies we can guaranteesthe ontology quality In MDR based approach ontologiesand common concepts are controlled by MDR organizationsthat follow a standardized procedure for managing commonconcepts and reflect a standardized lifecycle for creatingontologies It means that the MDR-based ontology reuseapproach enables high-quality ontology creation

Limitation of expression means how the expressivepower is restricted when ontologies are created User-definedapproach has no limitation to express knowledge basedon ontologies because a user selects their own terms andthe user can make relationships following userrsquos opinionOntology reuse approach just uses existing ontologies It isnot allowed to change existing concepts and terms whenconcepts or terms are incorrect from target domainThus theexpression of ontology is very strict MDR based approachreuses registered ontologies in the metadata registry TheMDR based approach also permits changing other ontologieswhen there are no concepts or terms that are required inexisting ontologies Nevertheless the MDR approach is strictbecause it is not allowed to define unregistered ontologies

The final factor of qualitative evaluation is creation costCreation cost means convenience of creating ontologiesand time for building ontologies In user-defined approach

International Journal of Distributed Sensor Networks 9

ltxml version=ldquo10rdquogtltOntology xmlns=ldquohttpwwww3org200207owlrdquoxmlbase=ldquohttpsoftwarekoreaackrSwsysSensorOntologyowlrdquoxmlnsrdfs=ldquohttpwwww3org200001rdf-schemardquoxmlnsxsd=ldquohttpwwww3org2001XMLSchemardquoxmlnsrdf=ldquohttpwwww3org19990222-rdf-syntax-nsrdquoxmlnsxml=ldquohttpwwww3orgXML1998namespacerdquo

ltPrefix name=ldquoxsdrdquoIRI=ldquohttpwwww3org2001XMLSchemardquogt

ltPrefix name=ldquoowlrdquoIRI=ldquohttpwwww3org200207owlrdquogtltPrefix name=ldquordf rdquo IRI=ldquohttpwwww3org19990222-rdf-syntax-nsrdquogtltPrefix name=ldquordfsrdquo IRI=ldquohttpwwww3org200001rdf-schemardquogtltDeclarationgt

ltClass IRI=ldquoPhysicalQualityrdquogtltClass IRI=ldquoSensorrdquogtltClass IRI=ldquoSensorGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogtltClass IRI=ldquoSystemrdquogtltObjectProperty IRI=ldquosubclassOfrdquogtltObjectProperty IRI=ldquomeasurerdquogtltObjectProperty IRI=ldquomodelGroundingrdquogtltObjectProperty IRI=ldquosupportsrdquogtltDataProperty IRI=ldquoisConsumablerdquogtltDataProperty IRI=ldquohasSerialNumberrdquogt

ltDeclarationgtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSystemrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingtltObjectProperty IRI=ldquomeasurerdquogt

ltClass IRI=ldquoSensorrdquogtltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomeasurerdquogtltClass IRI=ldquoPhysicalQualityrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquoisConsumablerdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingt

Algorithm 1 Continued

10 International Journal of Distributed Sensor Networks

ltDataPropertyRangegtltDataProperty IRI=ldquoisConsumablerdquogtltDatatype abbreviatedIRI=ldquoxsdbooleanrdquogt

ltDataPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingtltDataPropertyRangegt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltDatatype abbreviatedIRI=ldquoxsdstringrdquogt

ltDataPropertyRangegtltOntologygt

Algorithm 1 An ontology described using OWL

Table 1 Qualitative evaluation of ontology building approaches

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

experts directly define concepts and terms and it requireshigh cost to survey domain knowledge and collect referencedocuments for verification Ontology reuse approach usesexisting ontologies without change if the existing ontologiescoincide with concepts and terms in target domainThus thecost for ontology creation is low MDR based approach usesontologies registered in ametadata registryWhen ontologiesare created users need to search terms and their relationsto apply the search result to new ontologies Users also needa customization task to create link between domains andranges Although this approach requires medium cost whichis higher cost than the cost of ontology reuse approachthe cost of MDR approach is lower than user-definedapproach

52 Quantitative Evaluation Simulation Approach This sec-tion describes our quantitative analysis which clearly showsthe advantages of the proposed system CaSOB Many sys-tems and studies have addressed interoperability betweenontologies However most focus on interoperability issueamong ontologies which have already been created withtheir own ontology schema definition rules Our approach isimplemented in the step before ontology creation which aimsto reuse common concepts and increase interoperabilityThispaper defines existing approaches as user-defined ontologyschema creation methods and we conducted a quantitativeevaluation to compare our method with the user-definedschema creationmethodThemetadata registry also providesno schema creation method because its purpose is to registerand share ontologies In other words our proposed method

CaSOB is based on the MDR but the metadata registry isexcluded from the quantitative evaluation

An appropriate comparative item was determined forthe evaluation The goal of this paper is to minimize thesemantic heterogeneity of ontologies via the reuse of commonconceptsTherefore this paper conducted a quantitative eval-uation of the semantic heterogeneity rate We can estimatethe approximate ontology integration cost using the semanticheterogeneity rate so this paper also includes the ontologyintegration cost as a comparative item

The evaluation methodology is summarized as follows

(i) comparative targets our proposed method CaSOBand the user-defined ontology schema creationmethod

(ii) comparative items the semantic heterogeneity ratethat is the number of heterogeneous semantics(concepts) shared among the created ontologies theontology integration cost that is the cost required tointegrate a set of created ontologies

The key symbols and notations are defined as follows

(i) 119874 a set of ontologies created with a target method119874 = 1199001 1199002 1199003 119900119899

(ii) 119900119894 a created ontology consisting of one or moresemantics that is a set of concepts such as classesrelations properties and data types

(iii) 119862 a set of common concepts registered and used forcreating an ontology

International Journal of Distributed Sensor Networks 11N

umbe

r of h

eter

ogen

eous

conc

epts

Case-1 the proposal is the almost worst case Case-2 the proposal is the average case

Case-3 the proposal is the almost best case

0100020003000400050006000700080009000

10000

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000N

umbe

r of h

eter

ogen

eous

conc

epts

0100020003000400050006000700080009000

10000Case-4 the proposal is from the almost best to the average⟩⟩⟩⟩

⟩⟩ ⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 9 Comparative evaluation results for the number of semantic heterogeneities

(iv) 119867119890119862119894 a set of heterogeneous concepts in the 119894th

ontology among the created ontologies(v) 119867119900119862 a set of homogeneous concepts among the

created ontologies(vi) 119899(119874) the number of created ontologies(vii) 119899(119900

119894) the number of concepts in the 119894th ontology

(viii) 119899(119862) the number of common concepts used to createan ontology

(ix) 119899(119867119890119862119894) the number of heterogeneous concepts inthe 119894th ontology

(x) 119903(119867119900119862) the average ratio of homogeneous concepts(xi) 119903(119862) the average ratio of used common concepts(xii) 119905 semantic interpretation time between two concepts

0 lt 119905 lt 1(xiii) 119878119867119873 the number of heterogeneous concepts(xiv) 119874119868119862 the ontology integration cost

For the evaluation we assume that 119899-people generate anontology in the same domain In this case the homogeneousconcept means concepts which are commonly contained bymost of the ontologies For example the concept such assensor could be a homogeneous concept even though eachof the sensor ontologies is developed by different people Onthe other hand the heterogeneous concept means discordantconcepts with each of the ontologies We assume that thenumber of heterogeneous concepts is the number of totalconcepts without an average ratio of homogeneous concepts

Figure 9 shows the comparative evaluation result for thesemantic heterogeneity as 119878119867119873 The evaluation determinesthe variation in the number of heterogeneous conceptsdepending on the change in the ratio of homogeneousconcepts and the ratio of used common concepts

119878119867119873119901119903119900119901119900119904119886119897

considers the common concepts used tobuild an ontology In other words it is the result of an evalua-tion using our proposedmethod 119878119867119873

119901119903119890V119894119900119906119904 is an evaluationresult using a user-defined schema creation method

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

International Journal of Distributed Sensor Networks 9

ltxml version=ldquo10rdquogtltOntology xmlns=ldquohttpwwww3org200207owlrdquoxmlbase=ldquohttpsoftwarekoreaackrSwsysSensorOntologyowlrdquoxmlnsrdfs=ldquohttpwwww3org200001rdf-schemardquoxmlnsxsd=ldquohttpwwww3org2001XMLSchemardquoxmlnsrdf=ldquohttpwwww3org19990222-rdf-syntax-nsrdquoxmlnsxml=ldquohttpwwww3orgXML1998namespacerdquo

ltPrefix name=ldquoxsdrdquoIRI=ldquohttpwwww3org2001XMLSchemardquogt

ltPrefix name=ldquoowlrdquoIRI=ldquohttpwwww3org200207owlrdquogtltPrefix name=ldquordf rdquo IRI=ldquohttpwwww3org19990222-rdf-syntax-nsrdquogtltPrefix name=ldquordfsrdquo IRI=ldquohttpwwww3org200001rdf-schemardquogtltDeclarationgt

ltClass IRI=ldquoPhysicalQualityrdquogtltClass IRI=ldquoSensorrdquogtltClass IRI=ldquoSensorGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogtltClass IRI=ldquoSystemrdquogtltObjectProperty IRI=ldquosubclassOfrdquogtltObjectProperty IRI=ldquomeasurerdquogtltObjectProperty IRI=ldquomodelGroundingrdquogtltObjectProperty IRI=ldquosupportsrdquogtltDataProperty IRI=ldquoisConsumablerdquogtltDataProperty IRI=ldquohasSerialNumberrdquogt

ltDeclarationgtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosubclassOfrdquogtltClass IRI=ldquoSystemrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingtltObjectProperty IRI=ldquomeasurerdquogt

ltClass IRI=ldquoSensorrdquogtltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomeasurerdquogtltClass IRI=ldquoPhysicalQualityrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquomodelGroundingrdquogtltClass IRI=ldquoSensorModelGroundingrdquogt

ltObjectPropertyRangegtltObjectPropertyDomaingt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorrdquogt

ltObjectPropertyDomaingtltObjectPropertyRangegt

ltObjectProperty IRI=ldquosupportsrdquogtltClass IRI=ldquoSensorGroundingrdquogt

ltObjectPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquoisConsumablerdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingt

Algorithm 1 Continued

10 International Journal of Distributed Sensor Networks

ltDataPropertyRangegtltDataProperty IRI=ldquoisConsumablerdquogtltDatatype abbreviatedIRI=ldquoxsdbooleanrdquogt

ltDataPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingtltDataPropertyRangegt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltDatatype abbreviatedIRI=ldquoxsdstringrdquogt

ltDataPropertyRangegtltOntologygt

Algorithm 1 An ontology described using OWL

Table 1 Qualitative evaluation of ontology building approaches

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

experts directly define concepts and terms and it requireshigh cost to survey domain knowledge and collect referencedocuments for verification Ontology reuse approach usesexisting ontologies without change if the existing ontologiescoincide with concepts and terms in target domainThus thecost for ontology creation is low MDR based approach usesontologies registered in ametadata registryWhen ontologiesare created users need to search terms and their relationsto apply the search result to new ontologies Users also needa customization task to create link between domains andranges Although this approach requires medium cost whichis higher cost than the cost of ontology reuse approachthe cost of MDR approach is lower than user-definedapproach

52 Quantitative Evaluation Simulation Approach This sec-tion describes our quantitative analysis which clearly showsthe advantages of the proposed system CaSOB Many sys-tems and studies have addressed interoperability betweenontologies However most focus on interoperability issueamong ontologies which have already been created withtheir own ontology schema definition rules Our approach isimplemented in the step before ontology creation which aimsto reuse common concepts and increase interoperabilityThispaper defines existing approaches as user-defined ontologyschema creation methods and we conducted a quantitativeevaluation to compare our method with the user-definedschema creationmethodThemetadata registry also providesno schema creation method because its purpose is to registerand share ontologies In other words our proposed method

CaSOB is based on the MDR but the metadata registry isexcluded from the quantitative evaluation

An appropriate comparative item was determined forthe evaluation The goal of this paper is to minimize thesemantic heterogeneity of ontologies via the reuse of commonconceptsTherefore this paper conducted a quantitative eval-uation of the semantic heterogeneity rate We can estimatethe approximate ontology integration cost using the semanticheterogeneity rate so this paper also includes the ontologyintegration cost as a comparative item

The evaluation methodology is summarized as follows

(i) comparative targets our proposed method CaSOBand the user-defined ontology schema creationmethod

(ii) comparative items the semantic heterogeneity ratethat is the number of heterogeneous semantics(concepts) shared among the created ontologies theontology integration cost that is the cost required tointegrate a set of created ontologies

The key symbols and notations are defined as follows

(i) 119874 a set of ontologies created with a target method119874 = 1199001 1199002 1199003 119900119899

(ii) 119900119894 a created ontology consisting of one or moresemantics that is a set of concepts such as classesrelations properties and data types

(iii) 119862 a set of common concepts registered and used forcreating an ontology

International Journal of Distributed Sensor Networks 11N

umbe

r of h

eter

ogen

eous

conc

epts

Case-1 the proposal is the almost worst case Case-2 the proposal is the average case

Case-3 the proposal is the almost best case

0100020003000400050006000700080009000

10000

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000N

umbe

r of h

eter

ogen

eous

conc

epts

0100020003000400050006000700080009000

10000Case-4 the proposal is from the almost best to the average⟩⟩⟩⟩

⟩⟩ ⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 9 Comparative evaluation results for the number of semantic heterogeneities

(iv) 119867119890119862119894 a set of heterogeneous concepts in the 119894th

ontology among the created ontologies(v) 119867119900119862 a set of homogeneous concepts among the

created ontologies(vi) 119899(119874) the number of created ontologies(vii) 119899(119900

119894) the number of concepts in the 119894th ontology

(viii) 119899(119862) the number of common concepts used to createan ontology

(ix) 119899(119867119890119862119894) the number of heterogeneous concepts inthe 119894th ontology

(x) 119903(119867119900119862) the average ratio of homogeneous concepts(xi) 119903(119862) the average ratio of used common concepts(xii) 119905 semantic interpretation time between two concepts

0 lt 119905 lt 1(xiii) 119878119867119873 the number of heterogeneous concepts(xiv) 119874119868119862 the ontology integration cost

For the evaluation we assume that 119899-people generate anontology in the same domain In this case the homogeneousconcept means concepts which are commonly contained bymost of the ontologies For example the concept such assensor could be a homogeneous concept even though eachof the sensor ontologies is developed by different people Onthe other hand the heterogeneous concept means discordantconcepts with each of the ontologies We assume that thenumber of heterogeneous concepts is the number of totalconcepts without an average ratio of homogeneous concepts

Figure 9 shows the comparative evaluation result for thesemantic heterogeneity as 119878119867119873 The evaluation determinesthe variation in the number of heterogeneous conceptsdepending on the change in the ratio of homogeneousconcepts and the ratio of used common concepts

119878119867119873119901119903119900119901119900119904119886119897

considers the common concepts used tobuild an ontology In other words it is the result of an evalua-tion using our proposedmethod 119878119867119873

119901119903119890V119894119900119906119904 is an evaluationresult using a user-defined schema creation method

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

10 International Journal of Distributed Sensor Networks

ltDataPropertyRangegtltDataProperty IRI=ldquoisConsumablerdquogtltDatatype abbreviatedIRI=ldquoxsdbooleanrdquogt

ltDataPropertyRangegtltDataPropertyDomaingt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltClass IRI=ldquoPersonrdquogt

ltDataPropertyDomaingtltDataPropertyRangegt

ltDataProperty IRI=ldquohasSerialNumberrdquogtltDatatype abbreviatedIRI=ldquoxsdstringrdquogt

ltDataPropertyRangegtltOntologygt

Algorithm 1 An ontology described using OWL

Table 1 Qualitative evaluation of ontology building approaches

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

experts directly define concepts and terms and it requireshigh cost to survey domain knowledge and collect referencedocuments for verification Ontology reuse approach usesexisting ontologies without change if the existing ontologiescoincide with concepts and terms in target domainThus thecost for ontology creation is low MDR based approach usesontologies registered in ametadata registryWhen ontologiesare created users need to search terms and their relationsto apply the search result to new ontologies Users also needa customization task to create link between domains andranges Although this approach requires medium cost whichis higher cost than the cost of ontology reuse approachthe cost of MDR approach is lower than user-definedapproach

52 Quantitative Evaluation Simulation Approach This sec-tion describes our quantitative analysis which clearly showsthe advantages of the proposed system CaSOB Many sys-tems and studies have addressed interoperability betweenontologies However most focus on interoperability issueamong ontologies which have already been created withtheir own ontology schema definition rules Our approach isimplemented in the step before ontology creation which aimsto reuse common concepts and increase interoperabilityThispaper defines existing approaches as user-defined ontologyschema creation methods and we conducted a quantitativeevaluation to compare our method with the user-definedschema creationmethodThemetadata registry also providesno schema creation method because its purpose is to registerand share ontologies In other words our proposed method

CaSOB is based on the MDR but the metadata registry isexcluded from the quantitative evaluation

An appropriate comparative item was determined forthe evaluation The goal of this paper is to minimize thesemantic heterogeneity of ontologies via the reuse of commonconceptsTherefore this paper conducted a quantitative eval-uation of the semantic heterogeneity rate We can estimatethe approximate ontology integration cost using the semanticheterogeneity rate so this paper also includes the ontologyintegration cost as a comparative item

The evaluation methodology is summarized as follows

(i) comparative targets our proposed method CaSOBand the user-defined ontology schema creationmethod

(ii) comparative items the semantic heterogeneity ratethat is the number of heterogeneous semantics(concepts) shared among the created ontologies theontology integration cost that is the cost required tointegrate a set of created ontologies

The key symbols and notations are defined as follows

(i) 119874 a set of ontologies created with a target method119874 = 1199001 1199002 1199003 119900119899

(ii) 119900119894 a created ontology consisting of one or moresemantics that is a set of concepts such as classesrelations properties and data types

(iii) 119862 a set of common concepts registered and used forcreating an ontology

International Journal of Distributed Sensor Networks 11N

umbe

r of h

eter

ogen

eous

conc

epts

Case-1 the proposal is the almost worst case Case-2 the proposal is the average case

Case-3 the proposal is the almost best case

0100020003000400050006000700080009000

10000

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000N

umbe

r of h

eter

ogen

eous

conc

epts

0100020003000400050006000700080009000

10000Case-4 the proposal is from the almost best to the average⟩⟩⟩⟩

⟩⟩ ⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 9 Comparative evaluation results for the number of semantic heterogeneities

(iv) 119867119890119862119894 a set of heterogeneous concepts in the 119894th

ontology among the created ontologies(v) 119867119900119862 a set of homogeneous concepts among the

created ontologies(vi) 119899(119874) the number of created ontologies(vii) 119899(119900

119894) the number of concepts in the 119894th ontology

(viii) 119899(119862) the number of common concepts used to createan ontology

(ix) 119899(119867119890119862119894) the number of heterogeneous concepts inthe 119894th ontology

(x) 119903(119867119900119862) the average ratio of homogeneous concepts(xi) 119903(119862) the average ratio of used common concepts(xii) 119905 semantic interpretation time between two concepts

0 lt 119905 lt 1(xiii) 119878119867119873 the number of heterogeneous concepts(xiv) 119874119868119862 the ontology integration cost

For the evaluation we assume that 119899-people generate anontology in the same domain In this case the homogeneousconcept means concepts which are commonly contained bymost of the ontologies For example the concept such assensor could be a homogeneous concept even though eachof the sensor ontologies is developed by different people Onthe other hand the heterogeneous concept means discordantconcepts with each of the ontologies We assume that thenumber of heterogeneous concepts is the number of totalconcepts without an average ratio of homogeneous concepts

Figure 9 shows the comparative evaluation result for thesemantic heterogeneity as 119878119867119873 The evaluation determinesthe variation in the number of heterogeneous conceptsdepending on the change in the ratio of homogeneousconcepts and the ratio of used common concepts

119878119867119873119901119903119900119901119900119904119886119897

considers the common concepts used tobuild an ontology In other words it is the result of an evalua-tion using our proposedmethod 119878119867119873

119901119903119890V119894119900119906119904 is an evaluationresult using a user-defined schema creation method

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

International Journal of Distributed Sensor Networks 11N

umbe

r of h

eter

ogen

eous

conc

epts

Case-1 the proposal is the almost worst case Case-2 the proposal is the average case

Case-3 the proposal is the almost best case

0100020003000400050006000700080009000

10000

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

SHNpreviousSHNproposal

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000

Num

ber o

f het

erog

eneo

us co

ncep

ts

0100020003000400050006000700080009000

10000N

umbe

r of h

eter

ogen

eous

conc

epts

0100020003000400050006000700080009000

10000Case-4 the proposal is from the almost best to the average⟩⟩⟩⟩

⟩⟩ ⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 9 Comparative evaluation results for the number of semantic heterogeneities

(iv) 119867119890119862119894 a set of heterogeneous concepts in the 119894th

ontology among the created ontologies(v) 119867119900119862 a set of homogeneous concepts among the

created ontologies(vi) 119899(119874) the number of created ontologies(vii) 119899(119900

119894) the number of concepts in the 119894th ontology

(viii) 119899(119862) the number of common concepts used to createan ontology

(ix) 119899(119867119890119862119894) the number of heterogeneous concepts inthe 119894th ontology

(x) 119903(119867119900119862) the average ratio of homogeneous concepts(xi) 119903(119862) the average ratio of used common concepts(xii) 119905 semantic interpretation time between two concepts

0 lt 119905 lt 1(xiii) 119878119867119873 the number of heterogeneous concepts(xiv) 119874119868119862 the ontology integration cost

For the evaluation we assume that 119899-people generate anontology in the same domain In this case the homogeneousconcept means concepts which are commonly contained bymost of the ontologies For example the concept such assensor could be a homogeneous concept even though eachof the sensor ontologies is developed by different people Onthe other hand the heterogeneous concept means discordantconcepts with each of the ontologies We assume that thenumber of heterogeneous concepts is the number of totalconcepts without an average ratio of homogeneous concepts

Figure 9 shows the comparative evaluation result for thesemantic heterogeneity as 119878119867119873 The evaluation determinesthe variation in the number of heterogeneous conceptsdepending on the change in the ratio of homogeneousconcepts and the ratio of used common concepts

119878119867119873119901119903119900119901119900119904119886119897

considers the common concepts used tobuild an ontology In other words it is the result of an evalua-tion using our proposedmethod 119878119867119873

119901119903119890V119894119900119906119904 is an evaluationresult using a user-defined schema creation method

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

12 International Journal of Distributed Sensor Networks

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

Ont

olog

y in

tegr

atio

n co

st (u

nit

t)

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

70

80

(10

10)

(20

10)

(30

10)

(40

10)

(50

10)

(60

10)

(70

10)

(80

10)

(90

10)

OICpreviousOICproposal

OICpreviousOICproposal

0

10

20

30

40

50

60

70

80

(10

50)

(20

50)

(30

50)

(40

50)

(50

50)

(60

50)

(70

50)

(80

50)

(90

50)

(10

90)

(20

90)

(30

90)

(40

90)

(50

90)

(60

90)

(70

90)

(80

90)

(90

90)

(10

0)

(20

5)

(30

10)

(40

15)

(50

20)

(60

25)

(70

30)

(80

35)

(90

40)

OICpreviousOICproposal

OICpreviousOICproposal

times106times10

6

times106 times10

6

Case-4 the proposal is from the almost best to the average⟩⟩Case-3 the proposal is the almost best case⟩⟩

Case-1 the proposal is the almost worst case⟩⟩ Case-2 the proposal is the average case⟩⟩

(r(HoC) r(C)) (r(HoC) r(C))

(r(HoC) r(C)) (r(HoC) r(C))

Figure 10 Comparative evaluation results for the ontology integration costs

The number of heterogeneous concepts in 119878119867119873119901119903119890V119894119900119906119904

and 119878119867119873119901119903119900119901119900119904119886119897

is calculated as follows

119878119867119873 =

119899(119874)

sum

119894=1

119899 (119867119890119862119894) (5)

Once 119878119867119873119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts is

119899 (119867119890119862119894) =

119899 (119900119894) minus (119899 (119900

119894) times 119903 (119867119900119862)) 119903 (119867119900119862) lt 1

0 otherwise(6)

And when 119878119867119873119901119903119900119901119900119904119886119897

is determined the number of hetero-geneous concepts is

119899 (119867119890119862119894) =

119899 (119900119894)

minus ((119899 (119900119894) times 119903 (119867119900119862))

+ (119899 (119900119894) times 119903 (119862))) 119903 (119867119900119862) + 119903 (119888) lt 1

0 otherwise(7)

Figure 9 shows that in all cases there is a decrease inthe number of heterogeneous concepts which is inverselyproportional to the ratio of used common concepts Thusthe results demonstrate the efficiency of the use of commonconcepts for heterogeneity problems

Figure 10 shows the comparative evaluation results forthe ontology integration costs The ontology integration

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

International Journal of Distributed Sensor Networks 13

cost is the time taken for the comparison of ontologyintegrationThemagnitude of the comparison decreases withthe increasing size of the homogeneous concepts and thecommon conceptsTheontology integration cost is calculatedas follows

119874119868119862 =

119899(119900)

sum

119894=1

(119899 (119867119890119862119894)

times ((

119899(119900)

sum

119895=1

119899 (119867119890119862119895)) minus 119899 (119867119890119862119894)) times 119905

(8)

When 119874119868119862119901119903119890V119894119900119906119904 is determined the number of heteroge-

neous concepts uses the same equation as the 119878119867119873119901119903119890V119894119900119906119904

Similarly when 119874119868119862119901119903119900119901119900119904119886119897

is determined the number ofheterogeneous concepts uses the same equation as the119878119867119873119901119903119900119901119900119904119886119897

Figure 10 shows that in all cases the decrease in theontology integration cost is inversely proportional to thesquare of the ratio of the common concepts Thus the resultsshow that a greater use of common concepts is efficient forontology matching and integration

6 Conclusion

In various domains of sensor network environment sensorontologies are developed to represent sensor informationconsistently and increase interoperability However thesesensor ontologies are definedwith specific purposes and thuswe cannot use the existing sensor ontologies as it is

This paper proposed MDR based approach to solvethe heterogeneity problems MDR based approach developsontologies using common concepts and metadata registeredin a metadata registry The approach guarantees a qualityof ontologies and solves the heterogeneity problems Weproposed MDR based Ontology Builder (CaSOB) frame-work describedmappingmodel betweenMDRand ontologyand presented ontology building processes For implementa-tion we developed the metadata registry with RDBMS andCaSOB system In qualitative evaluation we compared theproposed approach with user-defined approach and ontologyreuse approach As a result the proposed approach showsadvantages from ontology quality and creation cost Forquantitative evaluation we compared CaSOB system withuser-defined ontology creation method and CaSOB systemefficiently solves heterogeneity problems rather than the user-defined ontology creation method in ontology matching andintegration technique perspective

The proposed approach still has several limitations whichshould be resolved First CaSOB does not handle constraintsand objects (individuals) in instance level Therefore theproposed system should be extended to address this issueCaSOB requires a manual processing by ontology designersfor selecting proper concepts It causes high cost and thus anautomatic creation function should be studied

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

Acknowledgments

This research was supported by the Next-GenerationInformation Computing Development Program through theNational Research Foundation of Korea (NRF) fundedby the Ministry of Science ICT amp Future Planning(2012M3C4A7033346) And this research was supported bythe Basic Science Research Program through the NationalResearch Foundation of Korea (NRF) funded by theMinistryof Education Science and Technology (no 2011-0004911)The cocorresponding authors are Doo-Kwon Baik andDongwon Jeong

References

[1] M Botts G Percivall C Reed and J Davidson ldquoOGC sen-sor web enablement overview and high level architecturerdquoOpenGIS White Paper OGC 07-165 Open Geospatial Consor-tium 2007

[2] A Sheth C Henson and S S Sahoo ldquoSemantic sensor webrdquoIEEE Internet Computing vol 12 no 4 pp 78ndash83 2008

[3] D J Russomanno C Kothari and O Thomas ldquoSensor ontolo-gies from shallow to deep modelsrdquo in Proceedings of the 37thSoutheastern Symposium on SystemTheory (SST rsquo05) 2005

[4] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of the W3C semantic sensor network incubator grouprdquoJournal of Web Semantics vol 17 pp 25ndash32 2012

[5] R Eastman C Schlenoff S Balakirsky and T Hong ldquoA sensorontology literature reviewrdquo NISTIR 7908 National Institute ofStandards and Technology 2013

[6] W3C Incubator Group ldquoSemantic sensor network XG finalreportrdquo W3C Incubator Group Report W3C 2011

[7] D Kim S Cha and K Cho ldquoOntology-based methodologyformanaging heterogeneouswireless sensor networksrdquo Interna-tional Journal of Distributed Sensor Networks vol 2013 ArticleID 610684 9 pages 2013

[8] L Lezcano L Santos and E Garcıa-Barriocanal ldquoSemanticintegration of sensor data and disaster management systemsthe emergency archetype approachrdquo International Journal ofDistributed Sensor Networks vol 2013 Article ID 424821 11pages 2013

[9] Y Shi G Li X Zhou and X Zhang ldquoSensor ontology buildingin semantic sensor webrdquo in IInternet of Things pp 277ndash2842012

[10] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 1 Framework 3rd edition 2013

[11] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 2 Classification 2nd edition 2005

[12] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 3 Registry Metamodel and Basic Attributes 3rd edition2013

[13] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 4 Formulation of Data Definition 2nd edition 2007

[14] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 5 Naming and Identification Principles 3rd edition 2013

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

14 International Journal of Distributed Sensor Networks

[15] ISOIEC JTC1SC32 ISOIEC 11179 Metadata Registries (MDR)Part 6 Registration 3rd edition 2013

[16] S Castano A Ferrara and S Montanelli ldquoOntology-basedinteroperability services for semantic collaboration in opennetworked systemsrdquo in Interoperability of Enterprise Softwareand Applications pp 135ndash146 2006

[17] S Castano A Ferrara and S Montanelli ldquoMatching ontologiesin open networked systems techniques and applicationsrdquo inJournal on Data Semantics V pp 25ndash63 2006

[18] G Pirro M Ruffolo and D Talia ldquoSECCO on buildingsemantic links in Peer-to-Peer networksrdquo in Journal on DataSemantics XII pp 1ndash36 2009

[19] M Bakillah and M A Mostafavi ldquoG-Map semantic mappingapproach to improve semantic interoperability of distributedgeospatial web servicesrdquo in Advances in Conceptual ModelingApplications and Challenges pp 12ndash22 2010

[20] C Matuszek J Cabrai M Witbrock and J DeOliveira ldquoAnintroduction to the syntax and content of Cycrdquo in Proceedingsof the Spring Symposium on Formalizing and Compiling Back-ground Knowledge and Its Applications to Knowledge Represen-tation and Question Answering pp 44ndash49 March 2006

[21] B Biebow and S Szulman ldquoTERMINAE a linguistics-basedtool for the building of a domain ontologyrdquo in KnowledgeAcquisition Modeling and Management pp 49ndash66 1999

[22] SensorOntology2009 ldquoCSIRO sensor ontologyrdquo 2009 httpwwww3org2005IncubatorssnwikiSensorOntology2009

[23] ldquoMMI Marine Metadata Interoperabilityrdquo 2009 httpmarine-metadataorgcommunityteamsontdevices

[24] Defence Science and Technology Laboratory ldquoISTAR andsensorsrdquo httpswwwdstlgovukistarandsensors

[25] M Compton C Henson L Lefort H Neuhaus and ASheth ldquoA survey of the semantic specification of sensorsrdquo inProceedings of the 2nd International Workshop on SemanticSensor Networks (SSN rsquo09) pp 17ndash32 2009

[26] H Neuhaus and M Compton ldquoThe semantic sensor networkontology a generic language to describe sensor assetsrdquo inProceedings of the AGILE Pre-Conference Workshop Challengesin Geospatial Data Harmonisation 2009

[27] C Rueda L Bermudez and J Fredericks ldquoThe MMI ontologyregistry and repository a portal for marinemetadata interoper-abilityrdquo in Proceedings of the MTSIEEE Biloxi Marine Technol-ogy for Our Future Global and Local Challenges (OCEANS rsquo09)pp 1ndash6 2009

[28] A Preece M Gomez G de Mel et al ldquoMatching sensorsto missions using a knowledge-based approachrdquo in DefenseTransformation and Net-Centric Systems Proceedings of SPIE2008

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Active and Passive Electronic Components

Control Scienceand Engineering

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

RotatingMachinery

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Shock and Vibration

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation httpwwwhindawicom

Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Navigation and Observation

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

DistributedSensor Networks

International Journal of