Building a Service-Oriented Ontology for Wireless Sensor Networks Implementation Report

Term Project Implementation

Ubiquitous Sensor Network

Muhammad Shoaib Department of Computer Engineering Jeju National University muhammad.shoaib@live.com

Abstract:
Wireless sensor networks (WSNs) provide various environment data in the real-world, and also WSNss middleware is able to offer field data in real-time by user queries. For materialization of the future ubiquitous computing which enables networking with things at anytime, anywhere and any-devices, WSNs occupy the important position with RFID technologies, and it has evolved and advanced currently. This paper proposes a service-oriented sensor ontology which enables service-oriented services in future ubiquitous computing. Taking reuse of ontology into consideration, ServiceProperty, LocationProperty and PhysicalProperty classes were derived from Geography Markup Language (GML), Sensor Web Enablement (SWE), SensorML and Suggested Upper Merged Ontology (SUMO) and OntoSensor ontology, and its properties and constraints were also defined newly as service-oriented service. We presented the validation and consistency check of the proposed ontology using Protege 3.3.4 and Pallet, respectively, and indicated the results of service query which used the SPARQL query language.

Introduction to Semantically Enabled Service-oriented Architectures:

In this section we provide an overview of the fundamental elements of the SESA architecture, one which enables the execution of Semantic Web Services and resolves the fundamental challenges related to the open SOA environment. We expect that in the near future a service-oriented world will consist of an uncountable number of services. Their computation will involve services searching for other services based on functional and nonfunctional requirements, and then resolving any interoperability conflicts from those services selected. However, services will not be able to interact automatically and existing SOA solutions will not scale without significant mechanization of the service provisioning process. Hence, machine processable semantics is essential for the next generation of Service-Oriented Computing (SOC) to reach its full potential. In this chapter we define methods, algorithms, and tools forming a skeleton of SESA, introducing automation to the service provisioning process, including service discovery, negotiation, adaptation, composition, invocation, and monitoring, as well as service interaction requiring data and process mediation. SOA outside a tightly controlled environment cannot succeed until semantic issues are addressed and critical tasks within the service provisioning process are automated leaving humans to focus on higher-level problems. While this chapter describes how these building blocks are consolidated into a coherent software architecture, which can be used as a blueprint for

implementation, following chapters present the basic conceptual and technical building blocks required to set up the SESA infrastructure. SESA has evolved from the collaborative efforts of three research/standardization groups: OASIS Semantic Execution Environment Technical Committee (SEE TC), Web Service Modeling Execution Environment (WSMX) Working Group, and NESSI. The aim of the OASIS SEE TC is to provide guidelines, justifications, and implementation directions for an execution environment for Semantic Web Services. The resulting infrastructure incorporates the application of semantics to service-oriented systems and provides mechanisms for consuming Semantic Web Services. WSMX is the reference implementation of Web Service Modeling Ontology (WSMO) and SEE. It is an execution environment for business application integration where enhanced Web Services are integrated for various business applications. The aim is to increase business processes automation in a very flexible manner while providing scalable integration solutions. The WSMX Working Group builds a prototypical execution infrastructure for Semantic Web Services based on the SOA paradigm of loosely coupled components. Finally SESA also relates to the work carried out by the NESSI initiative addressing semantic aspects of the NESSI platform. NESSI semantic technologies provide the semantics-based solutions for search and integration, which aim to enable progressive development of SESA. The NESSI Semantic Technology Working Group aims to use SESA as its roadmap defining the development of its semantic technologies.

Ontology:
The word ontology is used with different senses in different communities. The most radical difference is perhaps between the philosophical sense, which has of course a well-established tradition, and the computational sense, which emerged in the recent years in the knowledge engineering community, starting from an early informal definition of (computational) ontologies as explicit specifications of conceptualizations . In this paper we shall revisit the previous attempts to clarify and formalize such original definition, providing a detailed account of the notions of conceptualization and explicit specification, while discussing at the same time the importance of shared explicit specifications.

Use of Ontologies:
The usage of an ontology is of interest whenever the costs that arise through terminological disagreements and misunderstandings while not using ontologies exceed the costs for providing ontologies and formalised descriptions of situations. There are a number of characteristics of settings where use of ontologies appears promising: 1. Important heterogeneous (and possibly imprecise) vocabularies: When vocabularies constitute an important asset by itself, the value of formalising the domain tends to increase, too. 2. Small to medium sized domain: Open domains, e.g. the content of general web pages, cannot be appropriately formalised and change too often. Small and medium sized domains naturally exhibit boundaries between what should and what should not be part of a conceptualisation. Multitude of participants with overlapping interests: In such a situation the need for agreement rises.

3. Long-term interest in understanding of vocabulary and corresponding data: Over a longer period of time the increased benefits of improved understanding tend to outweigh the costs of providing ontologies with corresponding data. 4. Many and/or (rather) expensive transactions: More frequent and/or more valuable transactions, e.g. exchange of data, naturally generate more benefit through preciseness implied by the use of an ontology.

Ontologies for the Service Lifecycle:

The value proposition for ontologies used to manage the service life cycle lies in reducing errors, failures, and time-to-manage via ontologies that (i) increase agreement about core concepts in service provisioning and (ii) provide (semi-)automation of crucial service lifecycle management tasks. Service provisioning may be conceptualized as a complex sub-domain of software and systems engineering. The issue is of utmost monetary or other value to the service lifecycle stakeholders, i.e. its service providers and service users (cf. characteristics above). Service provisioning touches upon many different aspects of the world and implements models of the world. Thereby, the core domain of services that describes services as software entities and that describes the working of and interrelationships between services is of moderate size, while the application domain of services that describes what services are about (e.g. about payment, customer relationships) may be very largethough circumscribed by the boundaries of what the software accomplishes. Hence, the different ontologies that are relevant for service modelling, i.e. (at least) one for modelling the software aspects and (at least) one for modelling application aspects remain of small to moderate size (2). At the same time each service management platform has many stakeholders (3) with long-term interests (4) that often attribute many valuable transactions (5) with the services performed on the service platform (e.g. large numbers of business transactions).

Ontology Engineering:
When building a concept taxonomy using the FO and the OKBC Ontology, the following primitives can be used:

Classes, class partitions and instances:

In the frame-based KR paradigm, two types of frames can be represented: classes and instances. On the one hand, classes (aka concepts) represent collections or stereotypes of objects. On the other hand, instances represent individuals belonging to one or to several of those classes. The latter are called individuals in the OKBC Ontology. Two of the primitives, y y Class (?Class). This primitive defines the class ?Class as a collection of individuals. It is the only primitive appearing in both ontologies. Individual (?Individual). This primitive defines an individual or instance.

Class taxonomies:
Taxonomies are used to organize classes and instances in the ontology. The most important relations here are Subclass-Of (which means that a class is a specialization of another class) and Instance-Of (which

states that an individual is an element of a class). Both primitives and some more specific ones for creating taxonomies are described below. y y Subclass-Of (?Child-Class ?Parent-Class), which states that the class ?Child-Class is a subclass of the class ?Parent-Class. Superclass-Of (?Parent-Class ?Child-Class), which states that the class ?Parent-Class is a superclass of the class ?Child-Class. This relation is the inverse relation of the Subclass-Of relation. Disjoint-Decomposition (?Class ?Class-Set), which defines the set of disjoint classes ?ClassSet as subclasses of the class ?Class. This classification does not necessarily have to be complete, that is, there may be instances of ?Class that are not instances of any of the classes of ?Class-Set. Exhaustive-Decomposition (?Class ?Class-Set), which defines the set of classes ?Class-Set as subclasses of the class ?Class. This classification is complete, that is, there are no instances of ?Class that are not instances of any of the classes of ?Class-Set. However, the classes in the set ?Class-Set are not necessarily disjoint, as with the previous primitive. Partition (?Class ?Class-Set), which defines the set of disjoint classes ?Class- Set as subclasses of the class ?Class. This classification is complete, that is, the class ?Class is the union of all the classes that belong to ?Class-Set.

Relations and their properties:

A relation represents the dependency between concepts in the domain. In Mathematics, relations are formally defined as sets of tuples of individuals. Relations in ontology can be organized in relation taxonomies according to a specialization relationship, called Subrelation-Of. Several mathematical properties of a relation can also be determined: reflexive, irreflexive, symmetric, etc. Some of the primitives for defining relations identified in the FO are: y y Relation (?Rel), which defines a relation ?Rel in the domain. The classes to which the relation applies are defined as the domain and range of the relation respectively. Subrelation-Of (?Child-Rel ?Parent-Rel). A relation ?Child-Rel is a subrelation of the relation ?Parent-Rel if, viewed as sets, ?Child-Rel is a subset of ?Parent-Rel. In other words, every tuple of ?Child-Rel is also a tuple of ?Parent-Rel, that is, if ?Child-Rel holds for some arguments arg_1, arg_2, ...arg_n, then ?Parent-Rel holds for the same arguments. Thus a relation and its subrelation must have the same arity, which could be undefined. Reflexive-Relation (?Rel). Relation ?Rel is reflexive if ?Rel(x,x) holds for all x in the domain and range of ?Rel. Irreflexive-Relation (?Rel). Relation ?Rel is irreflexive if ?Rel(x,x) never holds for all x in the domain and range of ?Rel. Symmetric-Relation (?Rel). Relation ?Rel is symmetric if ?Rel(x,y) implies ?Rel(y,x) for all x and y in the domain and range of ?Rel. Antisymmetric-Relation (?Rel). Relation ?Rel is antisymmetric if ?Rel(x,y) implies not ?Rel(y,x) when x y, for all x and y in the domain and range of ?Rel.

y y y y

y y y

Asymmetric-Relation (?Rel). Relation ?Rel is asymmetric if it is antisymmetric and irreflexive over its exact domain. The exact domain of ?Rel is the set elements of the ?Rel domain linked to some element of the ?Rel range through this relation; that is, the exact domain only keeps the domain elements that participate in the relation. Transitive-Relation (?Rel). Relation ?Rel is transitive if ?Rel(x,y) and ?Rel(y,z) implies ?Rel(x,z), for all x and z in the domain and range of ?Rel respectively, and for all y in the domain and range of ?Rel. Equivalence-Relation (?Rel). Relation ?Rel is an equivalence relation if it is reflexive, symmetric, and transitive. Partial-Order-Relation (?Rel). Relation ?Rel is a partial-order relation if it is reflexive, antisymmetric, and transitive. Total-Order-Relation (?Rel). Relation ?Rel is a total-order relation if it is a partial-order relation for which either ?Rel(x,y) or ?Rel(y,x) holds for every x or y in its exact domain.

Slots:
A slot (aka attribute) defines a characteristic of a class, which is also inherited by its subclasses. Attributes can be defined with the following two primitives of the OKBC Ontology: y y Template-Slot-Of (?Slot ?Class), which states that ?Slot is a slot of ?Class. The slot ?Slot can take different values in the different instances of ?Class. Slot-Of (?Slot ?Frame), which states that ?Slot is a slot of ?Frame. ?Frame can be either a class or an individual.

Facets and types of facets:

A facet is a slot property. In the FO facets are defined as ternary relations that hold between a frame (which can be either a class or an individual), a slot, and the facet. Common facets in the frame-based KR paradigm are, for example, those that define the cardinality of a slot, the type of a slot, and default values. Some of the primitives related to facets that are identified in the OKBC Ontology are: y y y Facet-Of (?Facet ?Slot ?Frame), where ?Facet is facet of the slot ?Slot in the frame ?Frame. Minimum-Cardinality (?Slot ?Frame ?Number), which expresses that ?Number is the minimum cardinality of the slot ?Slot in the frame ?Frame. Maximum-Cardinality (?Slot ?Frame ?Number), which expresses that ?Number is the maximum cardinality of the slot ?Slot in the frame ?Frame.

The design of context ontology:

The purpose of the ontology-based context model is to formalize the structured contextual entities in smart spaces by making use of the ontology methodology to define the concepts and relationships of the context elements. The context ontology is divided into a core context ontology for general conceptual entities in the smart space and an extended context ontology for the domain-specific environment, e.g., the classroom domain. The core context ontology defines very general concepts for the context in the smart space that are universal and sharable for building context-aware applications. The extended context

ontology defines additional concepts and vocabularies for supporting various types of domain-specific applications.

The core context ontology describes seven basic concepts: user, location, time, activity, service, environment, and platform, which are the basic entities in the smart space as shown in Fig. 2. Part of the core context ontology is adopted from various widely-used consensus ontologies, such as DAML-Time and OWLS. The instance of the smart space consists of User, Location, Time, Activity, Service, Environment, and Platform classes. y User: Since user plays an important, central role in smart space applications, this ontology defines the vocabularies representing profile information, contact information, user preference, and users mood which are sensitive to the current user activity or task. Location, Time, and Activity: The relationships between location, time, and activity facilitate validation of inconsistent contextual information when these contexts are sensed by sensors with different accuracies. Platform and Service: The platform ontology defines descriptions and vocabularies of hardware devices or sensors and software infrastructure in a smart space. The service ontology defines the multi-level specifications of services that the platform provides to support service discovery and composition. In the semantic web community, OWL is used as a standardized framework to describe services in general. Environment: The environment ontology defines the context specification of the physical environment conditions around the user, such as noise level, lighting condition, humidity, and temperature.

Figure 2: A part of Service Ontology The extended context ontology extends the core context ontology and defines the details and additional vocabulary which applies to the various domains. The advantage of the extended context ontology is that the domain separation reduces the scale of the context knowledge and context processing burdens for pervasive computing applications, and facilitates effective context inference with limited complexity. We conducted a case study based on location and physiological WSNs. The location WSN maintains the location of persons or objects and provides their position in terms of longitude and latitude values. The physiological WSN measures the Electrocardiogram (ECG) of a person. The ECG WSN consists of just one ECG node that provides the health index which is a certain aggregate value of a given electrocardiogram. This health index determines the condition of the person and its value range can be defined arbitrarily. To describe the semantics of sensor data, we need to create ontology. We used the Noy and McGuniness ontology development guide. We determined the domain and scope of the sensor ontology and identified all the important terms that can be part of the WSNs (e.g. ECG sensor node) and sensor data (e.g. latitude, longitude, timestamp etc). Then we separated concepts from properties and relationships. Concepts become classes and are organized in a class-subclass relation. For instance, Lab ClassRoom or

LectureHall are sub-classes of Locations Concept. We have defined two different kinds of properties. Object Properties like hasService or hasDevice are used for relating different classes. The other types of properties are Data Type Properties which represent the data attributes of classes. For instance, the ServiceProperty class has hasService property. Humidity and Pressure, being a subclass of Quantity inherits these properties and also contains the hasLongitude and hasLatitude property. The domain and range of these properties are also defined accordingly. A part of sensor ontology is shown in Figure 2.

SPARQL:
SPARQL, a Query Language for RDF formerly called BrQL, has been developed by members of the W3C RDF Data Access Working Group. SPARQL is an extension of RDQL designed according to requirements and use cases and is still under development. SPARQL extends RDQL with facilities to: y y y y y Extract RDF subgraphs. Construct, using CONSTRUCT clauses, one new RDF graph with data from the RDF graph queried. Like RDQL queries, the new graph can be specifie with triple, or graph, patterns. Return, using DESCRIBE clauses, descriptions of the resources matching the query part. The exact meaning of description is not yet defined, cf. for a proposal. Specify OPTIONAL triple or graph query patterns, i.e., data that should contribute to an answer if present in the data queried, but whose absence does not prevent to return an answer. Testing the absence, or non-existence, of tuples.

SPARQL queries have the following form: y y y y y y y y PREFIX Specification of a name for a URI (like RDQLs USING) SELECT Returns all or some of the variables bound in the WHERE clause. CONSTRUCT Returns a RDF graph with all or some of the variable bindings. DESCRIBE Returns a description of the resources found. ASK Returns whether a query pattern matches or not WHERE list, i.e., conjunction of query (triple or graph) patterns OPTIONAL list, i.e., conjunction of optional (triple or graph) patterns AND Boolean expression (the filter to be applied to the result)

Figure 8 showed the query results about temporary service query related with equvalance class. And we have following question: What is the temperature at current location? when we be somewhere. In here, current location, based on logitude and latitude, is the same location as its own portable device. Therefore, service query can be maked as Table 2. and its results was showd like Figure 3.

Figure 3: SPARQL Query and its results

Conclusion:
The semantic representation of wireless sensor networks data is an exciting vision that enables structured information to be interpreted unambiguously. Precise interpretation is a necessary prerequisite for automatic search, retrieval, and processing of sensor data. For ubiquitous computing, this paper is the first attempt to define an ontology for describing concepts and relationships of the wireless sensor networks based on service-oriented services. The benefits of this work are to classify the property and improve the approach about the sensor ontology for serviceoriented service in the future ubiquitous environments. As for future work, we are considering extending the ontology so that it describes the entire available property base on user preference; including URL and UFID location property. Moreover, we plan to test the effectiveness of the ontology approach by quantitatively measuring the improvements in the property and recall rates of a search engine when utilizing the ontology against traditional string-based searching approaches. This effort will be a further step in the direction towards enabling ubiquitous services to access and process sensing and sensors data.

References:
1. M. Klien and A. Bernstein, Searching for services on the Semantic Web using process ontologies, 1st Semanti c 2. Web Working Symposium (SWWS-1), Stanford, CA, 2001. 3. D.J. Russomanno, C. Kothari and O. Thomas, Building a Sensor Ontology: A Practical Approach Leveraging ISO and OGC Models, The 2005 International Conference on Artificial Intelligence, Las Vegas, NV, 2005, pp. 637-643. 4. S. Avancha, C. Patel, and A. Joshi, Ontology-driven Adaptive Sensor Networks, First Annual International Conference on Mobile and Ubiquitous Systems, Networking and Services, 2004, pp. 194-202. 5. Mohamad Eid, Ramiro Liscano, Abdulmotaleb El Saddik, A Novel Ontology for Sensor Networks Data, IEEE International Conference on Computational Intelligence for Measurement Systems and Applications La Coruna - Spain, 12-14 July 2006

6. Mohamad Eid, Ramiro Liscano, Abdulmotaleb El Saddik, A Universal Ontology for Sensor Networks Data, IEEE International Conference on Computational Intelligence for Measurement Systems and Applications Ostuni- Italy, 27-29 June 2007 7. Mark Wiser, The computer of the 21st century, Scientific American, 1991. 8. Nicola Guarino, Massimiliano Carrara, Pierdaniele Giaretta, An Ontology of Meta-Level Categories, Proceedings of the Fourth International Conference (KR94), Morgan Kaufmann, San Mateo, CA, 1994. 9. Natalya F. Noy and Deborah L. McGuinness, Ontology Development 101: A Guide to Creating Your First Ontology, Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880, March 2001. 10. R. Jurdak, C. V. Lopes, and P. Baldi, A Framework for Modeling Sensor Networks, Proceedings of the Building Software for Pervasive Computing Workshop at OOPSLA_04, Vancouver, Canada 2004. 11. George V. Cybenko, Guofei Jiang, and Wayne Chung, Semantic Agent Technologies for Tactical Sensor Networks, Proceedings of the SPIE Conference on Unattended Ground Sensor Technologies and Applications V, pages 311-320, Orlando, FL, September, 2003. SPIE. 12. Jie Liu and Feng Zhao, Towards Semantic Services for Sensor-Rich Information Systems, Proceedings of the 2nd IEEE/CreateNet International Workshop on Broadband Advanced Sensor Networks (Basenets 2005), Boston, MA, Oct. 3, 2005. 13. IEEE P1451Project official web site, http://ieee1451.nist.gov, accessed in 27, Sep., 2007. 14. M. Botts, A. Robin, OpenGIS Sensor Model Language (sensorML) Implementation Specification, http://www.opengeospatial.org, accessed Oct. 12, 2007. 15. M. Horridge, H. Knublauch, A. Rector, R. Stevens, and C. Wroe, A Practical Guide to Building OWL Ontologies Using the Protege-OWL, Plugin and COODE Tools, Edition 1.0, Tutorial, http://www.coode.org, accessed Oct. 10, 2007.