Semantic Web in a Pervasive Context-Aware Architecture ∗

Harry ChenUniversity of Maryland

Baltimore Countyhchen4@cs.umbc.edu

Tim FininUniversity of Maryland

Baltimore Countyfinin@cs.umbc.edu

Anupam JoshiUniversity of Maryland

Baltimore Countyjoshi@cs.umbc.edu

ABSTRACTThis document describes a new approach that explores theuse of Semantic Web languages in building an architec-ture for supporting context-aware systems. This new archi-tecture called Context Broker Architecture (CoBrA) differsfrom other architectures in using the Web Ontlogy LanguageOWL for modeling ontologies of context and for supportingcontext reasoning. Central to our architecture is a brokeragent that maintains a shared model of context for all com-puting entities in the space and enforces the privacy policiesdefined by the users. We also describe the use of CoBrA andits associated ontologies in prototyping an intelligent meet-ing room.

1. INTRODUCTIONThe Semantic Web, described by Tim Berners-Leeet. al.[4],is an extension of the current web in which information isgiven well-defined meaning, better enabling computers andpeople to work in cooperation . A key difference betweenthe Semantic Web and the present Web lies in the repre-sentation of information. In the present Web, the repre-sentation is meant for machines to process information atthe syntax level. In the future Semantic Web, however,the representation allows machines to process and reasonabout information at the semantic level. In this paper, wedescribe a new approach that explores the use of Seman-tic Web technologies (i.e., languages, logic inferences, andprogramming tools) in building an architecture for support-ing context-aware systems in smart spaces (e.g., intelligentmeeting rooms, smart vehicles, and smart houses).

Context is any information that can be used to characterizethe situation of a person or a computing entity [8]. Previ-ous research [16, 23] have viewed location information asan important aspect of context. We believe in addition tothe location information, an understanding of context shouldalso include information that describes system capabilities,services offered and sought, the activities and tasks in whichpeople and computing entities are engaged, and their situa-tional roles, beliefs, desires, and intentions.

The dynamic nature of a smart space environment createsgreat challenges for developing context-aware systems. Webelieve some of the critical research issues are context mod-eling, context reasoning, knowledge sharing, and user pri-vacy protection. To address these issues, we propose an

∗This work was partially supported by DARPA contract F30602-97-1-0215, Hewlett Packard, NSF award 9875433, and NSF award0209001.

agent-oriented architecture called Context Broker Architec-ture that exploits Semantic Web languages to model ontolo-gies of context, reason with context in a smart space, anddefine a policy language for users to control their contextinformation.

The rest of this document is organized as the following: Sec-tion 2 gives a brief overview of the Semantic Web and theWeb Ontology Language OWL. In Section 3 we describethe rationale behind our Semantic Web approach to build-ing a new architecture for context-aware systems. Section4 presents the design of CoBrA and its use case scenario inan intelligent meeting room. Section 5 describes our pre-liminary work on prototypingEasyMeeting, an intelligentmeeting room system that builds on the design of CoBrA.Discussions of the related work and concluding remarks aregiven in Section 6 and Section 7, respectively.

2. AN OVERVIEW OF THE SEMANTIC WEBThe Semantic Web is a vision in which web pages are aug-mented with information and data that is expressed in a waythat facilitates its understanding by computing machines[1]. The current human-centered web is largely encoded inHTML, which focuses largely on how text and images wouldbe rendered for human viewing. Over the past few years wehave seen a rapid increase in the use of XML as an alter-native encoding, one that is intended primarily for machineprocessing. The machine which process XML documentscan be the end consumers of the information or they can beused to transform the information into a form appropriatefor human understand (e.g., as HTML, graphics, and syn-thesized speech). As a representation language, XML pro-vides essentially a mechanism to declare and use simple datastructures and thus leave much to be desired as a languagein which to express complex knowledge. Enhancements tobasic XML, such XML Scheme, address some of the short-comings, but still do not result in an adequate language forrepresenting and reasoning about the kind of knowledge es-sential to realizing the Semantic Web vision.

A goal of the Semantic Web initiatives sponsored by theWorld Wide Web Consortium (W3C) is to develop languagesthat are adequate for representing and reasoning about thesemantics of information on the Web. The Web OntologyLanguage OWL is the latest standard proposed by the Web-Ontology Working Group. The OWL language builds onXML’s ability to define customized taggging schemes andRDF’s flexible approach to representing data [15]. Due tospace limitation, in this section we describe some of theOWL language constructs and show how they are used to

Figure 1: An example of OWL classes and properties ofa simple ontology.

define ontologies.

OWL is a language for defining and instantiating ontologies.An ontology is a formal explicit description of concepts ina domain of discourse (or classes), properties of each classdescribing various features and attributes of the class, and re-strictions on properties [20]. The normative OWL exchangesyntax is RDF/XML. OWL ontologies are usually placed onweb servers as web documents, which can be referenced byother ontologies and downloaded by applications that useontologies. Figure 1 shows an example of an OWL ontol-ogy encoded in RDF/XML.

The definition in our example ontology has two parts. Thefirst part is a set of classes and properties that describe peo-ple, devices, and the ownership relation between them. The

second part is a set of class individuals that represent specificpeople and devices in some imaginary domain discourse.

The beginning of our ontology defines a set of XML names-paces declarations, enclosed in an openingrdf:RDF tag,that indicate what specific vocabularies are being used. Thefirst two declarations identify the namespace associated withthis ontology. The first makes it the default namespace, stat-ing that unprefixed names refer to our example ontology.The second identifies the namespace of our example ontol-ogy with the prefixexd: .

The third namespace declaration says that in this document,elements prefixed withowl: should be understood as re-ferring to things drawn from the OWL namespace (http://www.w3.org/2002/07/owl# ). This declaration in-troduces the OWL vocabulary.

OWL depends on constructs defined by RDF, RDF-S, andXML Schema datatypes. In our example, therdf: prefixrefers to things drawn from the namespace calledhttp://www.w3.org/1999/02/22-rdf-syntax-ns# . Thenext two namespace declarations make similar statementsabout the RDF Schema (rdfs: ) and XML Schemadatatype (xsd: ) namespaces.

After the namespace declarations, a collection of assertionsabout the ontology is grouped under theowl:Ontologytag. These assertations define the meta-data for the exam-ple ontology document. Therdfs:comment tag enclosesa short comment about this document. Therdfs:labeltag encloses a string that is meant to be a human-readableversion of the ontology label.

The class definition in our example begins with the conceptPerson andDevice . A class represents a set of individu-als in the domain (i.e.,Person represents a set of individualperson,Device represents a set of individual device).PDAandCellphone are two other classes that represent a setof individual PDA and cellphones in our domain. They areboth subclasses of the classDevice . Note that, by default,every individual in the OWL world is a member of the classowl:Thing . Thus, all of our defined classes are implicitlysubclasses ofowl:Thing .

Properties in OWL lets us assert general facts about themembers of classes and specific facts about individuals [22].A property is a binary relation. Two types of propertiesare distinguished: datatype properties and object proper-ties. The former is relations between instances of classesand RDF literals and XML Schema datatypes. The latter isrelations between instances of two classes.

When defining a property, its domain and range can be spec-ified. Specifying the domain of a property asserts that thedomain value of the property must belong to a specifiedclass. Specifying the range of a property asserts that therange value of the property must belong to a specified classor to a specified data type.

In our example, thename property is defined as a typeof the datatype property. It has domainowl:Thingand rangehttp://www.w3.org/2001/XMLSchema#string . This asserts that any individual member of the

owl:Thing class can have aname property with somestring value. For example, the individualP1 is instantiatedwith the name stirng “Harry Chen”, and individualD1 is in-stantiated with the name string “Harry’s Blue Phone”.

There are two object properties in our ontologies. First,the ownedBy property has domainDevice and rangePerson . This asserts that theownedBy property can re-late a device to its owner (e.g., the deviceD2 is owned bythe personP2). The owns property is defined as an in-verse of theownedBy property. This asserts that for everytriple (X, ownedBy, Y), there is a triple (Y, owns, X) andvice versa (since the inverse relation is symmetric). Thus,from the example, since we know(P1, owns, D1) , wecan conclude(D1, ownedBy, P1) , and similiarly sincewe know(D2, ownedBy, P2) , we can conclude(P2,owns, D2) also holds.

3. WHY SEMANTIC WEBA key requirement for realizing context-aware systems is togive computer systems the ability to understand their situ-ational conditions. To achieve this, it requires contextualinformation to be represented in ways that are adequate formachine processing and reasoning. We believe the Seman-tic Web languages are well suited for this purpose for thefollowing reasons:

• Ontologies expressed in the Semantic Web languagesprovide a means for independently developed context-aware systems to share context knowledge, minimizingthe cost of and redundancy in sensing.

• RDF and OWL are knowledge representation languageswith rich expressive power that are adequate for modelingvarious types of contextual information, e.g., informationassociated with people, events, devices, places, time, andspace.

• Because context ontologies have explicit representationsof semantics, they can be reasoned by the available logicinference engines. Systems with the ability to reasonabout context can detect and resolve inconsistent contextknowledge that often result from imperfect sensing.

• The Semantic Web languages can be used as meta-languages to define other special purpose languages suchas communication languages for knowledge sharing, pol-icy languages for privacy and security [12]. A key advan-tage of this approach is better interoperability. Tools forlangages that share a common root of constructs can bet-ter interoperate than tools for languages that have diverseroots of constructs.

4. CONTEXT BROKER ARCHITECTUREThe use of Semantic Web languages and tools are key fea-tures in our Context Broker Architecture. In CoBrA, theOWL language is used to define ontologies for modelingcontext, providing common vocabaries for knowledge shar-ing, reasoning about the relation between the context andthe domain heuristic knowledge, and expressing user definedpolicies. The core of our architecture is a specialized serverentity calledcontext broker.

In a smart space a context broker has the following respon-sibilities: (i) provide a centralized model of context that canbe shared by all devices, services, and agents in the space,(ii) acquire contextual information from sources that are un-reachable by the resource-limited devices, (iii) reason aboutcontextual information that cannot be directly acquired fromthe sensors (e.g., intentions, roles, temporal and spatial re-lations), (iv) detect and resolve inconsistent knowledge thatis stored in the shared model of context, and (v) protect userprivacy by enforcing policies that the users have defined tocontrol the sharing and the use of their contextual informa-tion.

4.1 An Intelligent Meeting Room ScenarioThe design of CoBrA is aimed to support context-aware sys-tems in smart spaces. The following is a typical use casescenario of CoBrA in an intelligent meeting room system:

R210 is an intelligent meeting room with RFID sensors1 em-bedded in the walls and furniture for detecting the presenceof the users’ devices and clothing. As Alice enters the room,these sensors inform the R210 broker that a cell phone be-longing to her is present and the broker adds this fact in itsknowledge base.

As she sits, the agent on Alice’s Bluetooth enabled cellphone discovers R210’s broker and engages in a “handshake” protocol (e.g. authenticates agent identities and es-tablishes trust [12]) after which it informs the broker of Al-ice’s privacy policy. This policy represents Alice’s desiresabout what the broker should do and includes (i) the con-text information about Alice that the broker is permitted orprohibited from storing and using (e.g., yes to her locationand roles, no to the phone numbers she calls), (ii) otheragents that the broker should inform about changes in hercontextual information (e.g., keeping Alice’s personal agentat home informed about her location contexts), and (iii) thepermissions for other agents to access Alice’s context infor-mation (e.g., all agents in the meeting room can access Al-ice’s contexts while she is in the room).

After receiving Alice’s privacy policy, the broker creates aprofile for Alice that defines rules and constraints the brokerwill follow when handling any context knowledge related toAlice. For example, given the above policy, the profile forAlice would direct the broker (i) to acquire and reason aboutAlice’s location and activity contexts, (ii) to inform Alice’spersonal agent at home when Alice’s contexts change, and(iii) to share her contexts with agents in the meeting room.

Knowing Alice’s cell phone is currently in R210 and hav-ing no evidence to the contrary, the broker concludes Aliceis also there. Additionally, because R210 is a part of theEngineering building, which in turn is a part of the UMBCcampus, the broker concludes Alice is located in Engineer-ing building and on campus. These conclusions are assertedinto broker’s knowledge base.

Following the rules defined in the profile, the broker informsAlice’s personal agent of her whereabouts. On receiving this

1RFID stands for Radio Frequency Identification (see alsohttp://www.rfid.org )

Figure 2: A context broker acquires contextual informa-tion from heterogeneous sources and fuses it into a co-herent model that is then shared with computing entitiesin the space.

information about Alice, her personal agent attempts to de-termine why Alice is there. Her Outlook calendar has an en-try indicating that she is to give a presentation on the UMBCcampus about now, so the personal agent concludes that Al-ice is in R210 to give her talk and informs the R210 brokerof it’s belief.

On receiving information about Alice’s intention, the R210broker shares this information with the projector agent andthe lighting control agent in the ECS 210. Few minutes later,the projector agent downloads the slides from Alice’s per-sonal agent and sets up the projector, the lighting controlagent dims the room lights.

4.2 Context BrokerFigure 2 shows the design of a context broker. In smartspaces, context brokers are assumed to be running onresource-rich stationary computers that are embedded in theenvironment (e.g., Mocha PC2). In our preliminary work, allcomputing entities in a smart space are presumed to havepriori knowledge about the presence of a context broker. Inthe future design, we will attempt to use one of the avail-able service discovery infrastructure (e.g., Jini, UPnP) toimprove system flexibility. Our centralized design of thecontext broker is motivated by the need to support smalldevices that have relatively limited resources available forcontext acquisition and reasoning. With the presence of abroker, small devices such as cellphones, PDA and watchescan offload their burdens of managing context knowledgeonto a resource rich context broker, including reasoning withcontext, detecting and resolving inconsistent context knowl-edge. Furthermore, in an open and dynamic environment,users may desire their personal contextual information to bekept in private. A centralized management of context knowl-edge makes easy to implement privacy protection and infor-mation security.

A centralized broker can be the “bottle-neck” in a distributedsystem, creating a single point of failure in the system. To

2http://www.cappuccinopc.com/mochap4.asp

address this problem, we plan to investigate and developa fault-tolerance approach based on the Persistent BrokerTeam [14] approach. Our idea is to introduce a team of bro-kers in that each member has the responsibility to ensureat least one broker is available to provide services. In thecase when the number of available team members falls be-low a predefined threshold (e.g., some broker becomes un-reachable due to network failures), the remaining active teammembers will attempt to recruit or instantiate new brokers.In a broker team, the Joint Intention protocol [19] is used tobring about the mutual beliefs of the team states and teamcommitments.

A context broker has the following four functional compo-nents:

1. Context Knowledge Base: a persistent storage of thecontext knowledge. It provides a set of API’s for othercomponents in a broker to access the stored knowledge.It also contains the ontologies of a specific smart space(e.g., the ontologies of an intelligent meeting room) andsome heuristic knowledge associated with the space (e.g.,a company’s daily operation hours are between 9:00 AMto 5:00 PM; no person can be physically present at twodifferent meeting locations during the same time inter-val).

2. Context Reasoning Engine: a reactive inference enginethat reasons over the stored context knowledge. Twotypes of inferences can take place in this engine: (i) infer-ences that use ontologies to deduce context knowledge,and (ii) inferences that use heuristic knowledge to detectand resolve inconsistent knowledge.

3. Context Acquisition Module: a library of proceduresthat forms a middle-ware abstraction for context acqui-sition. The role of this component is similar to the role ofthe Context Widgets in the Context Toolkit [8], which isto shield the low-level sensing implementations from thehigh-level applications.

4. Policy Management Module: a set of inference rulesthat deduce instructions for enforing user policies. Somerules are defined for deciding the right permissions fordifferent computing entities to share a particular piece ofcontext information, and some rules are defined for se-lecting the recipients to receive notifications of contextchanges.

5. PROTOTYPING AN INTELLIGENT MEETING ROOMTo demonstrate the feasibility of our Context Broker Ar-chitecture, we are using CoBrA to prototype an intelligentmeeting room system calledEasyMeeting, which providesassistants to meeting speakers, audiences, and organizersbased on their situational needs. EasyMeeting is an exten-sion to Vigil, a smart space system that we have previouslydeveloped [21]. Security is the main focus in Vigil. A rolebased access control mechanism is implemented in Vigil toallow users control to the permissions to access different ser-vices using policies. Vigil differs from other frameworks inusing logic inference rules to reason about the rights of dif-ferent users.

Vigil has shown great promises in building flexible and se-cure smart spaces [21]. However, it lacks the necessary sup-port for context-aware systems. To improve upon Vigil, inEasyMeeting we use OWL to represent context ontologies,and we exploit a context broker to support context reasoning.

In the rest of this section, first, we overview the ontologiesthat we have developed to support EasyMeeting and their po-tential role in the context reasoning, and second, we describea prototype implementation of the context broker.

5.1 OntologiesWe have developed a set of ontologies for modeling contextin an intelligent meeting room. This set of ontologies calledCOBRA-ONT defines typical concepts and relations for de-scribing physical locations, time, people, software agents,mobile devices, meeting events.

5.1.1 Reasoning with the Physical Location OntologiesUnderstanding the context associated with physical loca-tions is extremely important in context-aware systems. Anontology of physical locations in COBRA-ONT includes thedescriptions of places with identifiable geographic bound-aries (e.g., rooms, buildings), places with spatial properties(e.g., atomic places, compound places), and places with tem-poral properties (e.g., meeting rooms during the workinghours, offices on a public holiday). An ontology of the phys-ical location context include geographic attributes, typicalsocial norms of a particular place, objects that occupy or arecontained in a particular space, and events that occur at aparticular place.

In our ontology the classPlace is the parent class ofall represented place classes. Subclasses ofPlace areCampus, Building , Room, Hallway , Parkinglot ,Restroom , andConferenceRoom , which are conceptsof places with identifiable geographic boundaries.

COBRA-ONT divids subclasses ofPlace into types ofeither atomic place or compound place, which are con-cepts of places with spatial properties. Atomic places (e.g.,ConferenceRoom , Hallway ) are places that cannot bedefined to spatially subsume other places. Compound places(e.g., Campus, Building ) are places that can spatiallysubsume other atomic or compound places3.

Spatial containment inference is a type of reasoning with lo-cation context. Let us consider the scenario described in Sec-tion 4.1. As Alice enters the conference room, informationacquired from the sensors in the room may lead the con-text broker to conclude that Alice is in the room R230. Be-cause the broker has an ontology of the associated location(e.g., the Engineering building spatially subsumes the roomR230, and the UMBC main campus spatially subsumes theEngineering building), the broker can draw new conclusionsabout Alice’s location context, e.g., Alice is located in theEngineering building, Alice is located on the UMBC maincampus.

3Note that present ontology do permit the definition of some illog-ical statements, e.g., a building spatially subsumes a campus (sincethey both are type of compound place). We are developing solu-tions to resolve this problem in the next version of the ontology

Reasoning with the spatial containment relation can alsohelp the broker to detect errors in sensing. Let us assume inaddition to the location ontology, the broker also has someheuristic knowledge about the associated location, for exam-ple, ”no person can be physically present at more than oneatomic place during the same time interval”. When cou-pled with the location ontology, this knowledge can help thebroker to detect if there is any inconsistency about a user’slocation context. Imagine that due to sensing errors, somesensors falsely detect the present of Alice and informs thebroker that she is located in the parking lot A. Since Aliceis known to be located in the room R230, and both the park-ing lot A and the room R230 are atomic places, the brokercan immediately conclude the location context of Alice isinconsistent with the known heuristic knowledge.

5.1.2 Reasoning with the Device OntologiesIn a pervasive computing environment, devices in the imme-diate vicinity of a user are also part of the user’s context.Device context can include basic knowledge about the de-vice profiles (e.g., does a particular device support color dis-play?), the device ownership relation (e.g., who is the ownerof a particular device?), temporal properties associated witha device (e.g., when was the last time a particular device hasbeen used?), and spatial properties associated with a device(e.g., what is the distance between a particular device andthe room in which its owner is currently in?).

To support reasoning with device profiles, COBRA-ONT in-cludes an ontology of device hardware and software profiles.Parts of this ontology are adopted from the FIPA device on-tology specification [9]. The hardware profile ontology in-cludes concepts of screen displays (e.g., screen width andlength, display color profile), device memory (e.g., amountof memory, memory size unit, and memory usage type),device network capability (e.g., support for wireless/wiredcommunications, supported network interfaces). The soft-ware profile ontology includes concepts of device operatingsystems and supported computing platforms.

By extending the device profile ontology, COBRA-ONTprovides an ontology of mobile devices. The goal is to de-fine specific ontology classes that represent different types ofmobile devices and properties that are associated with thesedevices. Represented types of mobile devices are SonyEr-icsson T68i, SonyEricsson T800, and Palm TungstenT. De-fined properties include the hardware and software profilesof these devices and additional relations that associate thedevices with people. For example, theownedBy propertyexpresses the relation between a device and its owner, andthe usedBy property expresses the relation between a de-vice and its user. Both of these properties have inverse prop-erties (i.e., theowns anduses properties).

To illustrate how reasoning with device ontologies can playa role in context-aware systems, let us consider the follow-ing use case: after Alice enters the meeting room R230, hercellphone presents Alice’s policy to the context broker in theroom. Assuming the context broker has an ontology of thedevice that sends the policy, it reasons about the profile of thedevice, e.g., the sender is a type of SonyEricssonT68i cell-phone, and its Bluetooth communication supports the OBEX

object push service for exchanging vCard contacts. Know-ing the device profile, the context broker informs all meetingservices that could take advantage of this information, e.g.,a contact exchange service that can automatically push newcontact information into the mobile devices that a meetingparticipant carries. Additionally, the context broker reasonsabout the person who owns and uses the device (e.g., the per-son Alice is the owner of this device, and no evidence showsthe device is used by other people). Since Alice’s SonyEr-icsson T68i cellphone is the room R230 and no evidence tothe contrary, the context broker concludes Alice is also in theroom R230.

5.1.3 Reasoning with the Temporal OntologiesAspects of context can also include temporal relations.To support reasoning with time and temporal relations,COBRA-ONT adopts the DAML-time ontology, which isa temporal ontology for expressing temporal aspects of thecontents of web resource and for express time-related prop-erties of web services [11]. The DAML-time ontology inCOBRA-ONT is an OWL version of the original DAML-time ontology that is expressed in the DAML+OIL lan-guage4.

The DAML-time ontology builds around a set of abstracttemporal entities and temporal relation axioms. Our OWLrepresentation of the ontology defines the vocabularies ofthe abstract temporal entities. However, it does not includea representation of the temporal relation axioms because thepresent OWL language does not have direct support for ex-pressing axiomatic rules. Research in developing languageconstructs for representing rules in Semantic Web languagesis underway [10].

In DAML-time the abstract temporal entity classes areInstant and Interval . Both are subclasses of theTemporalEntity class. A member of theInstantclass represents an instant of time, which has associated tem-poral description properties that represent the concepts ofsecond, minute, hour, day, month, year, and time zone. Amember of theInterval class represents a time intervalbetween two different time instants. Properties of this classincludebeginOf andendOf , which define the beginningtime (a time instant) and the ending time (a time instant) ofa time interval.

A type of relation between the individuals of theTemporalEntity class is temporal ordering. The tem-poral ordering relation can be expressed in thebefore andthe after properties, i.e., an individual of theInstantor Interval class can have abefore or after prop-erty value of another individual ofInstant or Intervalclass. The temporal ordering relation can also be expressedusing theinside andtime-between properties, whichdescribes a time instant isinside of a particular time in-terval, and a time interval is inbetween of two differenttime instants, respectively.

4To convert DAML-time from DAML+OIL to OWL, we have usedthe OWL Coverter, a tool for automating ontology conversion fromDAML+OIL to OWL ( http://www.mindswap.org/2002/owl.html )

The DAML-time ontology defines a number of predicates(properties) for linking time entities to events in the realworld5, which includeatTime , expressing an event occursat a particular time instant,during , express an event occursduring a particular time interval, andholds , expressing anevent holds at a particular time instant or during a particulartime interval.

To illustrate the use of temporal ontology, let us considerthe following the use case: while Alice is in the room R230,different sensors notify the context broker of her presence.Each notification is linked to a particular time instant, e.g.,an RFID sensor reportsatTime(locatedIn(Alice,R230), clockTime("13:04")) and a facial recog-nition sensor reportsatTime(locatedIn(Alice,R230), clockTime("13:45")) . As the pred-icate clockTime represents a time instant, thecontext broker can deduce the temporal ordering ofthe time during which Alice is located in the roomR230, e.g., during(locatedIn(Alice, R230),timeInterval("13:04-13:45")) .

Knowing Alice is in the room R230 during a partic-ular interval, the context broker can reason about herrelation to the events in the room. For example, atclockTime("13:55") , the context broker learns thatthe room R230 is hosting a meeting which begins atclockTime("13:00") . From its knowledge aboutAlice’s location (i.e., during(locatedIn(Alice,R230), timeInterval("13:04-13:45")) ), thebroker concludes that Alice is probably attending themeeting becausetimeInterval("13:04-13:45") isin between of the time instantsclockTime("13:00")andclockTime("13:55") .

5.2 A Context Broker PrototypeWe have implemented a context broker prototype to demon-strate its role in the EasyMeeting system. Our objective isto show the Semantic Web languages are adequate for dy-namically constructing representations of context informa-tion acquired from sensors, and how this information thencan be used to infer additional context knowledge. In ourpresent implementation, a context broker can reason aboutthe presence of people and device in an intelligent meetingroom.

Figure 3 shows the design layout of our prototype system.Central to the system is a context broker. This broker is im-plemented as a FIPA compliant agent that runs on the JADEplatform (a Java library for building FIPA compliant agents)[2]. The broker uses the Jena Semantic Web Toolkit6 formanaging and manipulating ontologies (e.g., dynamicallyconstructing OWL ontology statements for agent communi-cations, manipulating ontology knowledge that is stored in apersistent knowledge base).

RDQL (RDF Data Query Language) is used in the broker’sreasoning engine to access the stored ontology knowledge.Using RDQL, the reasoning engine periodically queries the

5Descriptions of events are assumed to be defined by ontologiesthat are outside of the DAML-time ontology6http://www.hpl.hp.com/semweb/jena.htm

Figure 3: In our prototype system, the broker attemptsto infer the location context of devices and users. An usermodel is dynamically acquired from an URL specified inthe received user policy.

knowledge base for the presence of certain context knowl-edge (e.g., has any device been detected in the room, whois the owner of a particular device?). When queries returnmatched results, the broker automatically inserts new asser-tions about the local context into its knowledge base. Forexample, if queries return information about the presence ofa new device and the person who owns the device, then thebroker asserts the owner of the device is also present in theroom.

For context sensing, the context broker delegates the tasks toother sensing agents in the environment. When the brokerstarts on a hosting JADE platform, it finds all sensing agentsthat are registered with the local yellow page service (FIPADirectory Facilitator) and sends a FIPA subscribe message tothese agents, requesting to be notified about context changes.In our prototype system, we have implemented a sensingagent called BT Sensor, which is responsible for detectingBluetooth OBEX object push events that are initiated by themobile devices. As a mobile device sends an OBEX ob-ject to the BT Sensor (e.g., a SonyEricsson T68i cellphonesends a vNote object to the BT Sensor), the BT Sensor agentconcludes the presence of the device and notifies the contextbroker.

Messages sent from a Bluetooth device to the BT Sensoragent contains a FIPA ACL message that informs the contextbroker of a user’s background information (or user model).A user model includes a privacy policy that a user definesto control the use and the sharing of his/her context infor-mation. Due to the message size limitations in our Blue-tooth devices, messages sent by the devices contain the URLof the web documents that have complete descriptions ofthe user models. The representation of this URL informa-tion is expressed in a RDF statement which is encoded inN3 [3], for example,"agt:HarryChen agt:aboutMehttp://umbc.edu/hchen4/aboutMe." . The firsttermagt:HarryChen is a subject RDF resource that de-fines this statement is about the user Harry Chen. The sec-ond termagt:aboutMe is a property of the subject. Thelast term is the value of the property, which is an URLfrom which the user model ofagt:HarryChen can be re-trieved.

To show the underlying ontology reasoning in the broker,we have developed a web application, backed by the ApacheTomcat Server, for viewing the internal knowledge base ofthe context broker. In future, this web application will in-clude administrator functions for manging a context broker(start, shutdown etc.).

6. RELATED WORKIn the past, a number of system architectures have been de-veloped to support pervasive computing such as the Con-text Toolkit framework [17], Schilit’s context-aware archi-tecture [18], Cooltown [13], and Intelligent Room [7]. Thesesystems have made progress in various aspects of pervasivecomputing but are weak in supporting knowledge sharingand context reasoning. A significant source of this weak-ness is their lack a common ontology with explicit semanticrepresentation [6, 5].

Key differences between our architecture and the previoussystems are the following:

• We use Semantic Web languages (i.e., RDF and OWL) todefine ontologies of contexts, providing an explicit repre-sentation of contexts for reasoning and knowledge shar-ing. In the previous systems, contexts are often imple-mented as programming objects (e.g., Java class objects)or informally described in documentations.

• In CoBrA a resource-rich agent (i.e., the context broker)is provided to manage and maintain a shared model ofcontext for all devices, services and agents in an associ-ated space. In the previous systems, individual entitiesare required to manage and maintain their own contextknowledge.

• The context reasoning in CoBrA gives context brokersthe ability to infer new context knowledge (e.g., spatialrelations, device profiles) that cannot be easily acquiredfrom the physical sensors. In the previous systems, con-texts acquired from sensors are presumed to be accurateand consistent.

• The use of policies in CoBrA allow users to control theircontextual information, specifying the granularity of in-formation that is shared by the systems and choosing re-cipients to receive notifications of their context changes.In preivous systems, acquired contextual information isallowed to be freely share by all computing entities in theenvironment, which could potentially jeopardize user pri-vacy.

7. CONCLUSION & FUTURE WORKThe use of ontology is a key requirement for realizing perva-sive context-aware systems. Our preliminary research in theContext Broker Architecture shows the Web Ontology Lan-guage OWL is adequate for defining ontologies for support-ing context reasoning and knowledge sharing. As SemanticWeb technologies and tools (i.e., programming libraries formanipulating ontologies and logic inference engines for on-tology reasoning), we believe the Semantic Web will createnew research opportunities for building pervasive context-aware systems.

At present the development of CoBrA and the EasyMeetingsystem is still in the early stage of research. Our short-termobjective is to define an ontology for expressing privacy pol-icy and to enhance a broker’s reasoning with users and ac-tivities by including temporal and spatial relations. A part ofour long-term objective is to deploy an intelligent meetingroom in the newly constructed Information Technology andEngineering Building on the UMBC main campus.

REFERENCES[1] R. Scott Cost andTim Finin andAnupam Joshi, Yun

Peng, Charles Nicholas andHarry Chen, Lalana Kagal,Filip Perich andYouyong Zou andSovrin Tolia, andIan Soboroff. Ittalks: A case study in the semanticweb and daml. Inproceedings of the InternationalSemantic Web Working Symposium, July 2002.

[2] Fabio Bellifemine, Agostino Poggi, and GiovanniRimassa. Developing multi agent systems with afipa-compliant agent framework.Software - PracticeAnd Experience, 31(2):103–128, 2001.

[3] Tim Berners-Lee.Primer: Getting into RDF &Semantic Web using N3, 2003.

[4] Tim Berners-Lee, James Hendler, and Ora Lassila.The semantic web.Scientific American, may 2001.

[5] Harry Chen. An intelligent broker architecture forcontext-aware systems. PhD. dissertation proposal.Seehttp://users.ebiquity.org/˜hchen4/phd/hcthsisp.pdf , 2003.

[6] Harry Chen, Sovrin Tolia, Craig Sayers, Tim Finin,and Anupam Joshi. Creating context-aware softwareagents. InProceedings of the First GSFC/JPLWorkshop on Radical Agent Concepts, 2001.

[7] Michael H. Coen. Design principles for intelligentenvironments. InAAAI/IAAI, pages 547–554, 1998.

[8] Anind K. Dey.Providing Architectural Support forBuilding Context-Aware Applications. PhD thesis,Georgia Institute of Technology, 2000.

[9] Foundation for Intelligent Physical Agent.FIPADevice Ontology Specification, pc00091a edition,2001.

[10] Benjamin N. Grosof, Ian Horrocks, Raphael Volz, andStefan Decker. Description logic programs:Combining logic programs with description logic. In12th International Conference on the World Wide Web,2002.

[11] Jerry R. Hobbs. A daml ontology of time.http://www.cs.rochester.edu/˜ferguson/daml/daml-time-20020830.txt , 2002.

[12] Lalana Kagal, Tim Finin, and Anupam Joshi. A policylanguage for a pervasive computing environment. InIEEE 4th International Workshop on Policies forDistributed Systems and Networks, 2003.

[13] Tim Kindberg and John Barton. A Web-based nomadiccomputing system.Computer Networks (Amsterdam,Netherlands: 1999), 35(4):443–456, 2001.

[14] Sanjeev Kumar, Philip R. Cohen, and Hector J.Levesque. The adaptive agent architecture: Achievingfault-tolerance using persistent broker teams. InProceedings of the Fourth International Conferenceon Multi-Agent Systems, pages 159–166, 2000.

[15] Deborah L. McGuinness and Frank van Harmelen.Owl web ontology language overview.http://www.w3.org/TR/owl-features/ ,2003.

[16] Nissanka B. Priyantha, Anit Chakraborty, and HariBalakrishnan. The cricket location-support system. InMobile Computing and Networking, pages 32–43,2000.

[17] Daniel Salber, Anind K. Dey, and Gregory D. Abowd.The context toolkit: Aiding the development ofcontext-enabled applications. InCHI, pages 434–441,1999.

[18] Bill Schilit, Norman Adams, and Roy Want.Context-aware computing applications. InIEEEWorkshop on Mobile Computing Systems andApplications, Santa Cruz, CA, US, 1994.

[19] Ira A. Smith and Philip R. Cohen. Toward a semanticsfor an agent communication language based on speechacts. In Howard Shrobe and Ted Senator, editors,Proceedings of the Thirteenth National Conference onArtificial Intelligence and the Eighth InnovativeApplications of Artificial Intelligence Conference, Vol.2, pages 24–31, Menlo Park, California, 1996. AAAIPress.

[20] Michael K. Smith, Chris Welty, and DeborahMcGuinness. Owl web ontology language guide.http://www.w3.org/TR/owl-guide/ , 2003.

[21] Jeffrey Undercoffer, Filip Perich, Andrej Cedilnik,Lalana Kagal, Anupam Joshi, and Tim Finin. A secureinfrastructure for service discovery and managementin pervasive computing.The Journal of Special Issueson Mobility of Systems, Users, Data and Computing,2003.

[22] Frank van Harmelen, Jim Hendler, Ian Horrocks,Deborah L. McGuinness, Peter F. Patel-Schneider, andLynn Andrea Stein. Owl web ontology languagereference.http://www.w3.org/TR/owl-ref/) , 2002.

[23] Roy Want, Andy Hopper, Veronica Falcao, and JonGibbons. The active badge location system. TechnicalReport 92.1, Olivetti Research Ltd., ORL, 24aTrumpington Street, Cambridge CB2 1QA, 1992.