Modeling context and situations in pervasive computing environments
Preeti Bhargava, Shivsubramani Krishnamoorthy, Ashok Agrawala
11 Modeling context and situations in pervasivecomputing environments
Preeti Bhargava, Shivsubramani Krishnamoorthy, Ashok AgrawalaDepartment of Computer Science, University of Maryland, College ParkE-mail:prbharga,shiv,[email protected]
Abstract —In pervasive computing environments, various entities often have to cooperate and integrate seamlessly in a situation which can, thus, be considered as an amalgamation of the context of several entities interacting and coordinatingwith each other, and often performing one or more activities. However, none of the existing context models and ontologiesaddress situation modeling. In this paper, we describe the design, structure and implementation of a generic, flexibleand extensible context ontology called Rover Context Model Ontology (RoCoMO) for context and situation modelingin pervasive computing systems and environments. We highlight several limitations of the existing context models andontologies, such as lack of provision for provenance, traceability, quality of context, multiple representation of contextualinformation, as well as support for security, privacy and interoperability, and explain how we are addressing theselimitations in our approach. We also illustrate the applicability and utility of RoCoMO using a practical and extensivecase study.
Keywords —Context-aware Computing, Context Modeling and Representation, Situation Modeling (cid:70)
NTRODUCTION
Recent years have witnessed rapid advancesin enabling technologies for pervasive comput-ing environments - an important step beingcontext-awareness in systems. Dey and Abowd[1] describe a context-aware system as one that“uses context to provide relevant informationand/or services to the user, where relevancydepends on the user’s task.” Context aware-ness enables a new class of applications inpervasive computing that can help users navi-gate through unfamiliar territory, find preferredrestaurants nearby, receive messages in the leastobtrusive manner, get extra sleep when meet-ings are canceled, find people with similar in-terests, and so on. The use of context informa-tion in these applications reduces the amount ofhuman effort and attention that an applicationneeds to service the user’s requests.Moreover, in pervasive computing environ-ments, various entities often have to cooper-ate and integrate seamlessly in a
Situation toachieve a common objective. Thus, SituationAwareness can be defined as “the capabilityof the entities in pervasive computing environ-ments to be aware of situation changes and au-tomatically adapt themselves to such changesto satisfy user requirements, including securityand privacy.” and a
Situation can be describedas “a set of contexts in the application over a period of time that affects future system behav-ior.” [2]. A situation can be considered as anamalgamation of the context of several entitiesinteracting and coordinating with each other,and often performing one or more activities.The context model forms the underlyingframework for modeling and representing con-text in the pervasive computing environmentand context-aware systems. To support context-and situation-awareness, and adaptation of theentities in pervasive computing environments,it is necessary to model and specify context andsituations in a suitable way such that the con-textual information can be easily exchanged,shared and reused. As discussed in severalpapers including Chen et al. [3] and Krish-namoorthy et al. [4], ontologies are a powerfultool for modeling context and the encompass-ing situations in context-aware systems becausethey promote knowledge sharing and reuseacross different applications and services inter-acting in a pervasive computing environment,thus, enhancing their interoperability. They al-low context-aware systems to use existing logicreasoning mechanisms to deduce high-level,conceptual context from low-level, raw context,and handle uncertainty and inconsistency incontext. They can be combined to form a morecomplex ontology and save the effort.However, none of the existing context models a r X i v : . [ c s . C Y ] M a r and ontologies address situation modeling ina dynamic environment where the situationconstantly evolves. To address this limitation,we described the design of a general and intel-ligent context-aware middleware called RoverII and its general, flexible and extensible con-text model for context and situation model-ing, called Rover Context Model (RoCoM), inKrishnamoorthy et al. [4] and Bhargava et al.[5]. RoCoM has four Primitives - Entity, Event,Activity and Relationship. These Primitives arethe building blocks of every context-aware sys-tem or middleware built using this model. Anypiece of contextual information in the systemcan be attached to one of these primitives andany situation can be modeled via them.We introduced the Rover Context Model On-tology (RoCoMO), which is the underlying on-tology for RoCoM and is currently deployedand implemented in Rover II, in [5]. In this pa-per, we describe its design, structure and imple-mentation in detail. Each primitive of RoCoMcorresponds to a top level concept in RoCoMOfrom which other concepts are derived. Ourmain contributions in this paper are: • Highlighting several shortcomings ofother existing standard models and on-tologies for context and situation mod-eling and demonstrating the utility ofRoCoMO’s capabilities that address thoseshortcomings, • Illustrating the benefits, applicability andutility of RoCoMO, as opposed to otherexisting models and ontologies, using asimple and practical case study for con-text and situation modeling in pervasivecomputing environments.The rest of this paper is organized as fol-lows. In Section 2, we describe a case studywhich we use in this paper to motivate andillustrate the benefits and utility of RoCoMO.We briefly discuss the existing approaches tocontext and situation modeling, and highlighttheir limitations in Section 3. In Section 4, weexplain the design and implementation of Ro-CoMO and how it addresses several limitationsof contemporary approaches such as lack ofprovision for provenance, quality of context,multiple representations of contextual informa-tion as well as support for security etc. Weillustrate the benefits of RoCoMO by revisitingthe case study in Section 6. We conclude andoutline future work in Section 7.
OTIVATION
We describe a simple but practical case studyhere in order to motivate and illustrate the var-ied nature of context, and the capabilities thatcontext models and ontologies should possessfor representing and modeling this situationin real time pervasive computing systems andenvironments. We will return to this case studyin Sections 5 and 6 to illustrate RoCoMO’smodeling capabilities. For illustration, we haveselected a situation from the domain of rescueand evacuation but this, by no means, restrictsRoCoMO’s applicability and generality.
A fire incident takes place in a room on the fourthfloor of a building on a university campus. Firefighters and responders are using a context-awaresystem to coordinate the rescue efforts. A responder,using the system, gets updated readings from twotemperature sensors in the room on fire. Using thiscontextual information, the system determines thetime that responders have to evacuate the buildingbefore the whole building is engulfed in flames. Thetemperature information also has a quality measureattached to it to convey any inaccurate or incompleteinformation. Another responder is accessing the sys-tem to get confidential floor maps of the building andalso determine the evacuation route people shouldtake based on the floormaps and the time remaining.
Representing and modeling this situation in acontext-aware system (such as Rover II), usingthe existing ontologies, is not trivial. It involvesinteraction between several entities such as re-sponders which perform one or more activities.The entire situation is catalyzed by an eventlike the fire incident and the goal of the situa-tion is to evacuate the building. Each activity,whether being performed by the system or anentity, is driven by the goal or a sub-goal.Some of the activities can occur simultaneously,for instance, calculating the time remaining forevacuation and accessing the floor maps ofthe building. Other activities need to be per-formed sequentially - the evacuation routes canbe determined only when the floor maps areavailable. The room has contextual information,that needs to be modeled and represented,such as the temperature readings of the room.To avoid ambiguity, the information must beclearly marked with its source (which sensor itis coming from) as well as the encoding format(whether it is in Celsius or Fahrenheit). Thisrequires support for encoding format as wellas provenance. The model should also support attachment of quality attributes to contextualinformation such as probability or certainty.Also, since the readings are getting updated at afixed time interval, they should be timestampedto help determine the most recent reading.Another aspect of the system is security - onlyauthorized personnel such as responders haveaccess to the floor maps of the building. Allthese requirements call for a deeper under-standing of modeling situations.
ELATED W ORK IN C ONTEXT AND S ITUATION M ODELING
We briefly describe some of the existing contextmodels and their underlying ontologies in thissection, and examine their limitations.CoBrA-Ont[6] is a collection of ontologies fordescribing places, agents and events and theirassociated properties in an intelligent meeting-room domain. SOUPA[3] was developed toprovide pervasive computing developers witha shared and upper ontology that combinesmany useful vocabularies from different con-sensus ontologies such as FOAF, DAML-Time,RCC, BDI, and Rei policy ontology. A full listof these well known ontologies can be found at[7].Other contemporary ontologies includeCONON[8] where the context ontologies aredivided into upper ontology and domain-specific ontologies; CoDAMoS[9] where thecontext ontology is centered around fourentities - user, environment, platform andservice; ASC/CoOL[10] that enables contextawareness and interoperability; Gaia [11] thatincorporates ontologies for context awareness,service discovery and matchmaking, andinteroperation between entities in a pervasivecomputing infrastructure mainly gearedtowards smart spaces; and GLOSS[12]which employs ontologies for the preciseunderstanding of various contexts and servicesin smart spaces.Several surveys such as those by Reichle etal. ([13], Krummenacher et al. [14] and Bettiniet al. [15]) have asserted that, of all the currentontologies used for context modeling, SOUPAis the most comprehensive ontology. However,both SOUPA and CoBrA-Ont have no provisionfor provenance, quality of context and multiplerepresentations. CONON enables provenanceby using the concept of sensed, derived, ag-gregated or deduced context but lacks features like comparability. Gaia takes on the challengeof modeling uncertainty and reasoning overit. However, their ontologies are restricted tothe smart spaces domain. They do not modelprovenance either. A more detailed evaluationof all these ontologies can be found in thesurveys mentioned.Moreover, a major shortcoming of generaland exhaustive ontologies such as OpenCyc[16] is that they become too cumbersome touse in a system that is designed to be usedefficiently and effectively in real time. Also, itis not possible for a small group of people toenumerate all the possible concepts and rela-tionships between them that could be used ina practical mobile or desktop application orsystem. Hence, in our opinion, it is better to de-velop the base ontology and make it extensiblefor users just as most of the previous contextmodels and ontologies have done. Our goal inthis paper is to follow a similar approach andgo one step further by addressing all the limi-tations that these existing ontologies posses.We do not find much work in the literaturewhere context-aware systems are extensivelymarried to situational modeling. For modelinga situation (such as the Fire Incident mentionedearlier), none of the existing ontologies is ade-quate. This is mainly because these situationsare rich and include events, which set a goalfor the context-aware system to achieve, as wellas entities interacting and performing a numberof activities, along with their associated context.Moreover, a number of them have no provisionfor provenance, encoding bias and quality ofcontext, and are often restricted to a singledomain of use such as smart spaces.To address all these shortcomings, RoCoMOhas been designed with an extensive ontologi-cal model-driven foundation along with capa-bilities to model both context and situation ina coherent and cohesive fashion.
TRUCTURE , D
ESIGN AND I MPLE - MENTATION OF R O C O MO Figure 1 shows how a situation can be repre-sented in terms of the different concepts of Ro-CoMO - entities, events, activities and relation-ships. Each of them has contextual informationassociated with it such as location, identity etc.At time t , the Event catalyzes the context-aware system and sets the
Goal for it. To achieve
Event Goal Activity1 Activity2 Activity3 Activity4
Sub-goal1 Sub-goal2 Sub-goal 3
Entity1 Entity2
Context (Entity1)
Time
Context (Entity2) Context (Activity3) Context (Activity4) Context (Activity1) Context (Activity2)
Legend:
Entity Goal
Event
Context Activity
Interaction Legend: hasContext Relationship involvedIn sequence Has/sets t=t t=t t=t t=t t=t Fig. 1: Interaction between the primitivesthe goal, different
Entities - Entity1 and Entity2perform a sequence of
Activities , such as Activ-ity1 and Activity2 beginning at time t . Everyactivity is driven by its own goal - which canbe the overall goal that is set by the event, asin case of Activity4, or a sub-goal, as in caseof Activity1. Every activity has a start time, anend time and a duration associated with it (asshown on the Time scale). It has a pre-conditionand a post-condition which are goal(s) thatshould have been met before the activity startsand once the activity ends respectively. Forinstance, Activity3 starts at time t , when bothSubGoal1 and SubGoal2 have been met, andends at time t , when its own goal, SubGoal3,has been met. The duration for this activityis t - t . An activity can be atomic and non-interruptable.RoCoMO has been developed in OWL2 DLand has two components:1) RoCoM Core Ontology which is dividedinto two upper level ontologies: • RoCoM Domain ontology - This on-tology includes concepts that char-acterize the knowledge of the do-main i.e. the primitives
Entities and
Events , along with concepts thatrepresent Location and Time. Ex-amples of entities include persons, devices etc. while events can rangefrom a simple service request to aroad accident. • RoCoM Task ontology - This ontol-ogy characterizes the problem solv-ing structure of the domain andprovides primitives for describingthe problem solving process i.e.
Ac-tivities as well as their
Goals . Ex-amples of Activities include Calling,Scheduling etc.2) RoCoM Application Ontology which hasconcepts that extend the core ontologyconcepts and are specific to an applica-tion.Figure 2 shows a partial view of the Ro-CoM Core and Application Ontologies. Theclasses representing the primitives such as ‘en-tity’, ‘event’ and ‘activity’, along with ‘loca-tion’, ‘time’ and ‘goal’ are derived from thedefault OWL class ‘Thing’ and form the toplevel classes in the RoCoM Core Ontology.Each of the classes derived from these toplevel classes represents a different, unique andunambiguous concept in the ontology. For in-stance, ‘physicalentity’ is derived from ‘entity’and can be used to denote any entity that hasa physical or logical form. It has more specificderived classes such as ‘person’, ‘device’ or ‘or-
Location Time Entity Activity Event Goal
Thing
Communicate
External Activity Internal Activity Assign Virtual Entity Physical Entity Service Environment Application
Person
Vehicle
Structure
Organization Device Building Closed Space Open Space
House
Elevator Room Place Rail Vehicle Road Vehicle Water Vehicle Car Van M-Urgency assignment M-Urgency Officer M-Urgency Event
Core Ontology
Task Ontology
Application Ontology
Domain
Ontology
M-Urgency Dispatcher
Fig. 2: Partial view of The RoCoM Ontology Version 1.0ganization’. The fourth primitive ‘relationship’can be represented in OWL in many ways:between two classes (as a subclass/superclass),a class and an individual (as a member) or aspecific relationship between two individuals(as object properties). The context of any ele-ment - entity, event or activity is representedusing datatype properties in OWL.The following shows an OWL code snippetfor the description of an individual instancenamed “xyz” of class ‘person’ which has arelationship with another entity (representedby the object property termed ‘daughter’) andcontextual information such as food preference(represented by the datatype property termed‘likesfood’). (cid:104)
Class rdf:about=”&person;person” (cid:105)(cid:104) rdfs:label xml:lang=”en” (cid:105) person (cid:104) /rdfs:label (cid:105)(cid:104) rdfs:subClassOf rdf:resource=”http://mind7.cs.umd.edu:8134/Rover/physicalentity (cid:105)(cid:104) /Class (cid:105)(cid:104)
ObjectProperty rdf:about=”&person;daughter” (cid:105)(cid:104) rdf:type rdf:resource=”&owl;FunctionalProperty”/ (cid:105)(cid:104) rdf:type rdf:resource=”&owl;InverseFunctionalProperty”/ (cid:105)(cid:104) rdfs:label xml:lang=”en” (cid:105) daughter (cid:104) /rdfs:label (cid:105)(cid:104) rdfs:subPropertyOf rdf:resource=”&person;contact”/ (cid:105)(cid:104) inverseOf rdf:resource=”&person;father”/ (cid:105)(cid:104) inverseOf rdf:resource=”&person;mother”/ (cid:105)(cid:104) /ObjectProperty (cid:105)(cid:104)
DatatypeProperty rdf:about=”&person;likesfood” (cid:105)(cid:104) rdfs:label xml:lang=”en” (cid:105) likesfood (cid:104) /rdfs:label (cid:105)(cid:104) rdfs:subPropertyOf rdf:resource=”&person;likes”/ (cid:105)(cid:104) /DatatypeProperty (cid:105)(cid:104)
NamedIndividual rdf:about=“&person;xyz” (cid:105)(cid:104) rdf:type rdf:resource=“&person;person”/ (cid:105)(cid:104) rdfs:label xml:lang=“en” (cid:105) xyz (cid:104) /rdfs:label (cid:105)(cid:104) person:likesfood rdf:datatype=“&xsd;string” (cid:105) indian (cid:104) /person:likesfood (cid:105)(cid:104) /NamedIndividual (cid:105)
The core ontology can be further extended to concepts specific to an application, such as M-Urgency [17], to form a part of the ApplicationOntology. M-Urgency is a public safety appli-cation that enables mobile users to stream livevideo from their devices to local PSAP (PublicSafety Answering Point) along with the audiostream, the real time location information andany personal and relevant information aboutthe caller.Thus, a simple M-Urgency scenario can in-volve the entities (corresponding RoCoMOclasses in parentheses): caller (‘person’), dis-patcher (‘murgencydispatcher’ extended from‘person’) and responder (‘murgencyofficer’ ex-tended from ‘person’). For instance, because ofan accident that is an event (‘murgencyevent’extended from ‘event’), a series of activitiesfollow such as, the caller calls the police,the dispatcher accepts the call, the dispatcherassigns (‘murgencyassignment’ extended from‘Assign’) a responder or officer to the call etc.This is only an illustration of how the conceptsin the core ontology can be extended to modelconcepts specific to an application.
NALYSIS AND E VALUATION OF R O -C O MO Bettini et al. [15] and Ye et al. [18] have specifieda set of requirements that both context models and ontologies for pervasive computing envi-ronments should support. We assess RoCoMand RoCoMO on the basis of these criteria andexplain how it addresses them:
Contextual information can be static i.e. thoseaspects of a pervasive system that are invariant,such as a person’s date of birth. However, themajority of contextual information is dynamic,such as location, with its persistence beinghighly variable. Every element of the RoCoMontology, beginning with the top level classeslike ‘entity’, ‘activity’ and ‘event’, have theircontextual information separated into two hier-archies - static and dynamic. This enables easeof distinction between contextual informationthat is persistent over a long period of time(static) and that which needs to be updatedfrequently based on its freshness (dynamic).
For every primitive such as an entity, activityor event, we have defined a time class thatrecords properties such as its start time - timeat which the event/activity started or the en-tity came into being, end time - time at whichthe event/activity ended or the entity ceasedto exist (equivalent to the current time if theindividual still exists), duration or life time ofan individual (difference of the start time andthe end time) and recurrence - frequency ofrepetition for an event/activity. The followingOWL code snippet shows the time class: (cid:104)
Class rdf:about=”http://mind7.cs.umd.edu:8134/Rover/time (cid:105)(cid:104) /Class (cid:105)(cid:104) owl :DatatypeProperty rdf:about=”http://mind7.cs.umd.edu:8134/Rover/time (cid:105)(cid:104) rdfs:domain rdf:resource=”http://mind7.cs.umd.edu:8134/Rover/time (cid:105)(cid:104) rdfs:range rdf:resource=”&xsd;dateTime”/ (cid:105)(cid:104) rdfs:subPropertyOf rdf:resource=”&owl;topDataProperty”/ (cid:105)(cid:104) /owl:DatatypeProperty (cid:105) .......... (cid:104) owl:DatatypeProperty rdf:about=”http://mind7.cs.umd.edu:8134/Rover/time (cid:105)(cid:104) rdfs:range:resource=”&xsd;string”/ (cid:105)(cid:104) rdfs:subPropertyOf rdf:resource=”&owl;topDataProperty”/ (cid:105)(cid:104) /owl:DatatypeProperty (cid:105)
Timestamping the dynamic contextual informa-tion allows the system to determine the fresh-ness and versioning of the contextual informa-tion which further enables resolution of con-flicts and ambiguity. In RoCoMO, the contex-tual information is timestamped at two levels: 1) fine-grained level - timestamping everydynamic contextual information of anindividual instance of a primitive to keeptrack of when it was last modified and bywhich entity and2) coarse-grained level - timestamping theindividual instance itself to determinewhen it was modified and by whichentity.The following OWL code snippet shows howthe hasMood context of an individual xyz of the person class in RoCoMO is assigned a value happy and is timestamped to determine whenthe contextual information was last updated. (cid:104)
Axiom (cid:105)(cid:104) annotatedTarget rdf:datatype=”&xsd;string” (cid:105) happy (cid:104) /annotatedTarget (cid:105)(cid:104) rocomo-schema:timeStamp rdf:datatype=”&xsd;dateTime” (cid:105) (cid:104) /rocomo-schema:timeStamp (cid:105)(cid:104) annotatedProperty rdf:resource=”&person;hasMood”/ (cid:105)(cid:104) annotatedSource rdf:resource=”&person;xyz”/ (cid:105)(cid:104) /Axiom (cid:105)
The model and ontology must employ amachine-interpretable representation of contextto tackle heterogeneity by using semantic anno-tations. These annotations can enable automaticexploitation and transformation of informationin distributed context sharing scenarios as wellas automatic context reasoning. They shouldprovide efficient access paths to contextual in-formation and represent it at different levelsof abstraction. For instance, location of a usercan be represented at a fine-grained level interms of latitude/longitude and at a coarse-grained level in terms of the name of a city ora building.RoCoMO is implemented in OWL2 DLwhich is expressive and allows more versatileknowledge representation. In OWL, context canbe represented as annotated semantics via dataproperties and relationships between differentelements can be represented via object proper-ties. It also enables automatic context reason-ing. Also, OWL represents information hierar-chically which allows efficient provisioning ofcontext and representation at multiple levels ofabstraction or granularity.
Contextual information sources constitute a va-riety of sensors and devices which often usedifferent measurement and encoding systems, thus, resulting in a heterogeneous set of valuesdescribing the same entities. Hence, the contextmodel and ontology must not depend on aparticular symbol-level encoding, such as therepresentation of date in a particular format. Itshould provide means to compare and convertvalues with different scale and encodings.To address this, we annotate any measur-able contextual information with an annotationproperty, called ‘scale’, defined in a RoCoMOschema (This schema enables reification of ev-ery OWL statement that is part of RoCoMO).This removes the model’s dependency on anyparticular encoding or measurement unit andalso facilitates comparison or conversion fromone unit to another.For instance, a person’s context can includeheight which can be in feet, meters or any otherunit. Thus, for person “xyz”, we can representheight and its measurement unit as: (cid:104)
Axiom (cid:105)(cid:104) annotatedTarget rdf:datatype=”&xsd;float” (cid:105) (cid:104) /annotatedTarget (cid:105)(cid:104) rocomo-schema:unit rdf:datatype=”&xsd;string” (cid:105) feet (cid:104) /rocomo-schema:unit (cid:105)(cid:104) annotatedProperty rdf:resource=”&person2;height”/ (cid:105)(cid:104) annotatedSource rdf:resource=”&person2;xyz”/ (cid:105)(cid:104) /Axiom (cid:105)
Pervasive computing environments are highlydynamic and hence context data is character-ized by properties such as incompleteness, am-biguity, uncertainty, inaccuracy, and temporalnature. For instance, in some environments, thecontextual information may be incorrect dueto a faulty sensor or incomplete due to lackof sufficient input. The model and ontologyshould be able to represent this imperfection.Several papers including Gray and Salber[19] introduced the notion of attaching informa-tion quality attributes to every piece of sensedcontext. To facilitate this, we have definedseven QoC attributes that model imperfectionin contextual information - accuracy to representcorrectness, probability or confidence to repre-sent the certainty of being correct, coverage torepresent the range, resolution to represent thesmallest perceivable element, meanError to rep-resent average error, and recurrence to measurerepeatability. These annotations are defined inthe RoCoMO schema and can be attached to theappropriate contextual information or a rela-tionship and can be propagated to applications.For instance, a person’s context can includehis/her weight which can be in kgs, pounds orany other scale. Also, the weight measure can have a mean error attached to it depending onthe sensitivity of the instrument. Thus, person“xyz” having weight 55 Kgs with an averageerror of 1 Kg, can be represented as: (cid:104)
Axiom (cid:105)(cid:104) annotatedTarget rdf:datatype=”&xsd;float” (cid:105) (cid:104) /annotatedTarget (cid:105)(cid:104) rocomo-schema:scale rdf:datatype=”&xsd;string” (cid:105) kgs (cid:104) /rocomo-schema:scale (cid:105)(cid:104) rocomo-schema:meanError rdf:datatype=”&xsd;float” (cid:105) (cid:104) /rocomo-schema:meanError (cid:105)(cid:104) annotatedProperty rdf:resource=”&person2;weight”/ (cid:105)(cid:104) annotatedSource rdf:resource=”&person2;xyz”/ (cid:105)(cid:104) /Axiom (cid:105)
In order to provide adequate control and inter-pretation of contextual information, the modeland ontology should provide the means to de-termine the source of data and transformationsmade to it. In RoCoMO, this is done at acoarse-grained level where we store, when thecontextual information of any instance or anindividual was created, when was it last modi-fied, the last modification made to the instanceand the entity by which it was made. However,we are not tracking every single modificationmade to every unique attribute or contextualinformation since this is too cumbersome atthe modeling level. This can be achieved atthe system level by logging context history andtransformations.For instance, in our case study, we require thetemperature of a room along with its source,its measurement scale, its time stamp and itscertainty. Thus, the following OWL snippet rep-resents an instance of an environment havingtemperature reading of 100 degree Fahrenheit,with certainty 0.9, created by a sensor instance‘sensor1’ at 2 pm on 09-18-2013. (cid:104) owl:NamedIndividual rdf:about=”&environment;envreading1” (cid:105)(cid:104) rdf:type rdf:resource=”&environment;environment”/ (cid:105)(cid:104) rdfs:label xml:lang=”en” (cid:105) envreading1 (cid:104) /rdfs:label (cid:105)(cid:104) environment:temperature rdf:datatype=”&xsd;float” (cid:105) (cid:104) /environment:temperature (cid:105)(cid:104) entity:createdBy rdf:resource=”http://mind7.cs.umd.edu:8134/Rover/sensor (cid:105)(cid:104) /owl:NamedIndividual (cid:105)(cid:104)
Axiom (cid:105)(cid:104) rocomo-schema:probability rdf:datatype=”&xsd;float” (cid:105) (cid:104) /rocomo-schema:probability (cid:105)(cid:104) rocomo-schema:timeStamp rdf:datatype=”&xsd;dateTime” (cid:105) (cid:104) /rocomo-schema:timeStamp (cid:105)(cid:104) owl:annotatedTarget rdf:datatype=”&xsd;float” (cid:105) (cid:104) /owl:annotatedTarget (cid:105)(cid:104) rocomo-schema:scale rdf:datatype=”&xsd;string” (cid:105)
Fahrenheit (cid:104) /rocomo-schema:scale (cid:105)(cid:104) owl:annotatedSource rdf:resource=”&environment;envreading1”/ (cid:105)(cid:104) owl:annotatedProperty rdf:resource=”&environment;temperature”/ (cid:105)(cid:104) /owl:Axiom (cid:105)
Pervasive computing environments are charac-terized by distribution, heterogeneity, unpre-dictability and unreliable communication links.Thus, the model and ontology should supportthese requirements and enable the aggregation and merging of the data when needed. RoCoMis an ontological model and promotes knowl-edge sharing and reuse across distributed sys-tems and applications in pervasive comput-ing environments. Hence, even if the sourcesof context are heterogeneous, distributed andpartitioned, the contextual information can beshared and aggregated across environments.
RoCoMO is developed on the principle ofModel-Driven Development. The ontology isalso available publicly. Hence, developers haveadequate support for development and imple-mentation.
Context models and ontologies should not berigid but flexible and extensible. Thus, theyshould not be restricted to a single domain,and should be able to support new and variedapplication domains. They should evolve withthe applications and their context needs.RoCoMO is structured in a modular fashionwith clear distinction between the Core andApplication ontologies. Also, as the applica-tions evolve, more concepts can be added to it.Thus, it is easily extensible, flexible and evolv-able. It does not target any specific domain inpervasive computing and is intended to be gen-eral and applicable across several applicationsand domains. As a result, we do not claim thatthe ontology is complete.
Since several existing projects use standard up-per ontologies, every generic ontology shouldbe interoperable i.e. its term definitions mustbe consistent with other standard, generic andconsensus ontologies such as SOUPA [3]. Thisalso enables reuse of domain knowledge [8].We have designed RoCoMO to be inter-operable with other ontologies, for instanceSOUPA[3], via the equivalentClass and equiva-lentProperty
OWL statements. The example be-low shows that the RoCoMO person class isdefined equivalent to the person class in SOUPAand the dateofbirth property is defined equiva-lent to birthDate property in SOUPA. (cid:104)
Class rdf:about=”&person;person” (cid:105) (cid:104) rdfs:label xml:lang=”en” (cid:105) person (cid:104) /rdfs:label (cid:105)(cid:104) equivalentClass rdf:resource=”http://pervasive.semanticweb.org/ont/2004/06/person (cid:105)(cid:104) rdfs:subClassOf rdf:resource=”http://mind7.cs.umd.edu:8134/Rover/physicalentity (cid:105)(cid:104) /Class (cid:105)(cid:104)
DataProperty rdf:about=”&person;dateofbirth” (cid:105)(cid:104) rdfs:label xml:lang=”en” (cid:105) dateofbirth (cid:104) rdfs:label (cid:105)(cid:104) rdfs:subClassOf rdf:resource=”&person;personalinfo”/ (cid:105)(cid:104) equivalentProperty rdf:resource=”http://pervasive.semanticweb.org/ont/2004/06/person (cid:105)(cid:104) /DataProperty (cid:105)
The concepts in RoCoMO are unique, unam-biguous, independent and consistent.
These are implemented in RoCoM using RoleBased Access Control (RBAC) for groups andmembers. A group is an instance of type ‘ac-cessgroup’ class. This class has object propertieslike ‘groupmember’ which includes the entitieslike users or devices that can be assigned to aninstance of the group. The ‘accessgroup’ classalso has an object property called ‘privileges’which defines the permissions that the groupcan have. These permissions can be in the formof an ‘activity’ that the group is allowed toperform. Every entity can belong to multipleaccess groups while each access group can havemultiple entities and privileges. This form ofaccess control, obtained by assigning users togroups and granting privileges to groups ratherthan individual users, reduces the number ofassociations involved that need to be managed.Hence, it is easier to define security policiesaround this framework.
ODELING THE F IRE I NCIDENT C ASE S TUDY USING R O C O MO In this section, we revisit the Fire Incidentcase study from Section 2 and illustrate howRoCoMO can be used to model it. Figure 3shows a graphical representation of the situ-ation modeled in RoCoMO. At time t , the Fire Incident
Event triggers the situation thatfollows and sets the Goal
Evacuate . This goalcan be subdivided into smaller sub-goals whichcan be performed by one or more activities.Entity
Responder1 performs the Activity
Getupdated temperature readings , at time t , to getthe context information of room Room123 - theupdated temperature readings from the tem-perature sensors
TempSensor1 and
TempSensor2 . Fire Incident Evacuate
Get updated temperature readings Access building floor maps Evacuate people Determine time left for evacuation
Room123
Responder2
Location
Role: Responder AccessGroup: Responders
TempSensor1 TempSensor2
Responder1
Determine exit routes for evacuation Temp=150
Unit=Fahrenheit
Probability=0.9 CreatedBy:TempSensor2
Role: Responder AccessGroup: Responders
Legend:
Entity
Goal Event Context
Activity
Temp=10 Unit=Fahrenheit Probability=0.1 CreatedBy:TempSensor1
Interaction Legend: hasContext
Relationship involvedIn sequence contains contains
Time t=t t=t t=t t=t Has/sets
Fig. 3: Fire Incident Case Study modeled using RoCoMOThe Goal for this activity is
Determine time leftfor evacuation . Since the information is times-tamped, the system can refresh it periodicallybased on its freshness and this resolves anyambiguity.The contextual information also has a prob-ability measure attached to it. As shown in thefigure, the probability of temperature reading,from
TempSensor1 , being correct is 0.1 whichmeans it is highly unreliable and that the sensorcould be faulty. This is evident by the fact thatit shows a reading of 10 deg Fahrenheit whilethe other sensor shows a reading of 150 degFahrenheit. Also, the contextual informationhas source or provenance information attachedto it and so this determines which reading camefrom which sensor. Based on the temperaturereading and its encoding (Fahrenheit in thiscase), the system can calculate how much timeit will take till the temperature reaches thevalue at which the building bursts into flames.This is the amount of time that the respondershave for evacuation.Simultaneously, another entity
Responder2 isperforming the activity
Access building floormaps with the Goal -
Determine exit routes for evacu-ation . Since the responders belong to the Ac-cessGroup responders , the system checks theirprivileges (which are inherited from the ‘re- sponders’ accessgroup) and grants access tothe temperature readings from the sensor andbuilding floor plans. Once these two activitieshave achieved their goals, both the respondersstart the activity
Evacuate people , at time t , andachieve the goal set by the event. ONCLUSION AND F UTURE W ORK
In this paper, we described a generic, flexibleand extensible ontology called Rover ContextModel Ontology(RoCoMO) and illustrated itsbenefits for context and situation modeling inpervasive computing environments, via a prac-tical case study. We highlighted several short-comings of contemporary context models andontologies and explained how RoCoMO ad-dresses them. We also established the utility ofits capabilities by evaluating it against severalcriteria that ontologies for context and situa-tion modeling should possess. Our next stepis to develop a GUI to allow users to browseand explore the RoCoM ontologies, and furtherextend and modify them. An API for workingwith the ontology will also be available. Ouraim is to encourage users to build applicationsand systems using this ontology so that theycan be used in both in an isolated manner orintegrated with Rover II. R EFERENCES [1] G. Abowd, A. Dey, P. Brown, N. Davies, M. Smith, andP. Steggles, “Towards a better understanding of contextand context-awareness,” in
Handheld and Ubiquitous Com-puting . Springer, 1999, pp. 304–307.[2] S. Yau and J. Liu, “Hierarchical situation modeling andreasoning for pervasive computing,” in
Software Tech-nologies for Future Embedded and Ubiquitous Systems, 2006and the 2006 Second International Workshop on CollaborativeComputing, Integration, and Assurance. SEUS 2006/WCCIA2006. The Fourth IEEE Workshop on , 2006.[3] H. Chen, F. Perich, T. Finin, and A. Joshi, “Soupa:Standard ontology for ubiquitous and pervasive appli-cations,” in
Mobile and Ubiquitous Systems: Networkingand Services, 2004. MOBIQUITOUS 2004. The First AnnualInternational Conference on , 2004, pp. 258–267.[4] S. Krishnamoorthy, P. Bhargava, M. Mah, andA. Agrawala, “Representing and managing the contextof a situation,”
The Computer Journal , vol. 55 (8), 2012.[5] P. Bhargava, S. Krishnamoorthy, and A. Agrawala, “Anontological context model for representing a situationand the design of an intelligent context-aware middle-ware,” in
Proceedings of the 2012 ACM Conference onUbiquitous Computing , 2012, pp. 1016–1025.[6] H. Chen, T. Finin, and A. Joshi, “An ontology for context-aware pervasive computing environments,”
The Knowl-edge Engineering Review , vol. 18, no. 03, pp. 197–207, 2003.[7] S. W. Ontologies. http://semanticweb.org/wiki/Ontology.[8] T. Gu, X. Wang, H. Pung, and D. Zhang, “An ontology-based context model in intelligent environments,” in
Pro-ceedings of communication networks and distributed systemsmodeling and simulation conference , 2004, pp. 270–275.[9] D. Preuveneers, J. Van den Bergh, D. Wagelaar,A. Georges, P. Rigole, T. Clerckx, Y. Berbers, K. Coninx,V. Jonckers, and K. De Bosschere, “Towards an extensi-ble context ontology for ambient intelligence,”
Ambientintelligence , pp. 148–159, 2004.[10] T. Strang, C. Linnhoff-Popien, and K. Frank, “Cool: Acontext ontology language to enable contextual interoper-ability,” in
Distributed applications and interoperable systems .Springer, 2003, pp. 236–247.[11] A. Ranganathan, R. McGrath, R. Campbell, and M. Mick-unas, “Use of ontologies in a pervasive computing en-vironment,”
The Knowledge Engineering Review , vol. 18,no. 03, pp. 209–220, 2003.[12] J. Coutaz, A. Dearle, S. Dupuy-Chessa, G. Kirby,C. Lachenal, R. Morrison, G. Rey, and E. Zirintsis,“Working document on gloss ontology,”
Arxiv preprintarXiv:1006.5661 , 2010.[13] R. Reichle, M. Wagner, M. Khan, K. Geihs, J. Lorenzo,M. Valla, C. Fra, N. Paspallis, and G. Papadopoulos, “Acomprehensive context modeling framework for perva-sive computing systems,” in
Distributed applications andinteroperable systems . Springer, 2008, pp. 281–295.[14] R. Krummenacher and T. Strang, “Ontology-based con-text modeling,” in
Proceedings Third Workshop on Context-Aware Proactive Systems (CAPS 2007)(June 2007) , 2007.[15] C. Bettini, O. Brdiczka, K. Henricksen, J. Indulska,D. Nicklas, A. Ranganathan, and D. Riboni, “A survey ofcontext modelling and reasoning techniques,”
Pervasiveand Mobile Computing , vol. 6, no. 2, pp. 161–180, 2010.[16] (2012) Opencyc for the semantic web.http://sw.opencyc.org/.[17] M-Urgency. (2012) http://m-urgency.umd.edu/. [18] J. Ye, L. Coyle, S. Dobson, and P. Nixon, “Ontology-basedmodels in pervasive computing systems,”
The KnowledgeEngineering Review , vol. 22, no. 4, pp. 315–347, 2007.[19] P. Gray and D. Salber, “Modelling and using sensed con-text information in the design of interactive applications,”