∗

Semantic Web in a Pervasive Context-Aware Architecture

Harry Chen Tim Finin Anupam Joshi
University of Maryland University of Maryland University of Maryland
Baltimore County Baltimore County Baltimore County
[email protected] [email protected] [email protected]

ABSTRACT agent-oriented architecture called Context Broker Architec-

This document describes a new approach that explores the ture that exploits Semantic Web languages to model ontolo-
use of Semantic Web languages in building an architec- gies of context, reason with context in a smart space, and
ture for supporting context-aware systems. This new archi- define a policy language for users to control their context
tecture called Context Broker Architecture (CoBrA) differs information.
from other architectures in using the Web Ontlogy Language
The rest of this document is organized as the following: Sec-
OWL for modeling ontologies of context and for supporting
tion 2 gives a brief overview of the Semantic Web and the
context reasoning. Central to our architecture is a broker
Web Ontology Language OWL. In Section 3 we describe
agent that maintains a shared model of context for all com-
the rationale behind our Semantic Web approach to build-
puting entities in the space and enforces the privacy policies
ing a new architecture for context-aware systems. Section
defined by the users. We also describe the use of CoBrA and
4 presents the design of CoBrA and its use case scenario in
its associated ontologies in prototyping an intelligent meet-
an intelligent meeting room. Section 5 describes our pre-
ing room.
liminary work on prototyping EasyMeeting, an intelligent
meeting room system that builds on the design of CoBrA.
1. INTRODUCTION
Discussions of the related work and concluding remarks are
The Semantic Web, described by Tim Berners-Lee et. al.[4], given in Section 6 and Section 7, respectively.
is an extension of the current web in which information is
given well-defined meaning, better enabling computers and 2. AN OVERVIEW OF THE SEMANTIC WEB
people to work in cooperation . A key difference between The Semantic Web is a vision in which web pages are aug-
the Semantic Web and the present Web lies in the repre- mented with information and data that is expressed in a way
sentation of information. In the present Web, the repre- that facilitates its understanding by computing machines
sentation is meant for machines to process information at [1]. The current human-centered web is largely encoded in
the syntax level. In the future Semantic Web, however, HTML, which focuses largely on how text and images would
the representation allows machines to process and reason be rendered for human viewing. Over the past few years we
about information at the semantic level. In this paper, we have seen a rapid increase in the use of XML as an alter-
describe a new approach that explores the use of Seman- native encoding, one that is intended primarily for machine
tic Web technologies (i.e., languages, logic inferences, and processing. The machine which process XML documents
programming tools) in building an architecture for support- can be the end consumers of the information or they can be
ing context-aware systems in smart spaces (e.g., intelligent used to transform the information into a form appropriate
meeting rooms, smart vehicles, and smart houses). for human understand (e.g., as HTML, graphics, and syn-
Context is any information that can be used to characterize thesized speech). As a representation language, XML pro-
the situation of a person or a computing entity [8]. Previ- vides essentially a mechanism to declare and use simple data
ous research [16, 23] have viewed location information as structures and thus leave much to be desired as a language
an important aspect of context. We believe in addition to in which to express complex knowledge. Enhancements to
the location information, an understanding of context should basic XML, such XML Scheme, address some of the short-
also include information that describes system capabilities, comings, but still do not result in an adequate language for
services offered and sought, the activities and tasks in which representing and reasoning about the kind of knowledge es-
people and computing entities are engaged, and their situa- sential to realizing the Semantic Web vision.
tional roles, beliefs, desires, and intentions. A goal of the Semantic Web initiatives sponsored by the
The dynamic nature of a smart space environment creates World Wide Web Consortium (W3C) is to develop languages
great challenges for developing context-aware systems. We that are adequate for representing and reasoning about the
believe some of the critical research issues are context mod- semantics of information on the Web. The Web Ontology
eling, context reasoning, knowledge sharing, and user pri- Language OWL is the latest standard proposed by the Web-
vacy protection. To address these issues, we propose an Ontology Working Group. The OWL language builds on
XML’s ability to define customized taggging schemes and
∗This work was partially supported by DARPA contract F30602- RDF’s flexible approach to representing data [15]. Due to
97-1-0215, Hewlett Packard, NSF award 9875433, and NSF award space limitation, in this section we describe some of the
0209001. OWL language constructs and show how they are used to
 second part is a set of class individuals that represent specific
people and devices in some imaginary domain discourse.
The beginning of our ontology defines a set of XML names-
paces declarations, enclosed in an opening rdf:RDF tag,
that indicate what specific vocabularies are being used. The
first two declarations identify the namespace associated with
this 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 prefix exd:.
The third namespace declaration says that in this document,
elements prefixed with owl: 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, and
XML Schema datatypes. In our example, the rdf: prefix
refers to things drawn from the namespace called http://
www.w3.org/1999/02/22-rdf-syntax-ns#. The
next two namespace declarations make similar statements
about the RDF Schema (rdfs:) and XML Schema
datatype (xsd:) namespaces.
After the namespace declarations, a collection of assertions
about the ontology is grouped under the owl:Ontology
tag. These assertations define the meta-data for the exam-
ple ontology document. The rdfs:comment tag encloses
a short comment about this document. The rdfs:label
tag encloses a string that is meant to be a human-readable
version of the ontology label.
The class definition in our example begins with the concept
Person and Device. A class represents a set of individu-
als in the domain (i.e., Person represents a set of individual
person, Device represents a set of individual device). PDA
and Cellphone are two other classes that represent a set
of individual PDA and cellphones in our domain. They are
both subclasses of the class Device. Note that, by default,
every individual in the OWL world is a member of the class
owl:Thing. Thus, all of our defined classes are implicitly
subclasses of owl:Thing.
Figure 1: An example of OWL classes and properties of
a simple ontology. Properties in OWL lets us assert general facts about the
members of classes and specific facts about individuals [22].
A property is a binary relation. Two types of properties
define ontologies. are distinguished: datatype properties and object proper-
ties. The former is relations between instances of classes
OWL is a language for defining and instantiating ontologies. and RDF literals and XML Schema datatypes. The latter is
An ontology is a formal explicit description of concepts in relations between instances of two classes.
a domain of discourse (or classes), properties of each class
describing various features and attributes of the class, and re- When defining a property, its domain and range can be spec-
strictions on properties [20]. The normative OWL exchange ified. Specifying the domain of a property asserts that the
syntax is RDF/XML. OWL ontologies are usually placed on domain value of the property must belong to a specified
web servers as web documents, which can be referenced by class. Specifying the range of a property asserts that the
other ontologies and downloaded by applications that use range value of the property must belong to a specified class
ontologies. Figure 1 shows an example of an OWL ontol- or to a specified data type.
ogy encoded in RDF/XML. In our example, the name property is defined as a type
The definition in our example ontology has two parts. The of the datatype property. It has domain owl:Thing
first part is a set of classes and properties that describe peo- and range http://www.w3.org/2001/XMLSchema#
ple, devices, and the ownership relation between them. The string. This asserts that any individual member of the
owl:Thing class can have a name property with some In a smart space a context broker has the following respon-
string value. For example, the individual P1 is instantiated sibilities: (i) provide a centralized model of context that can
with the name stirng “Harry Chen”, and individual D1 is in- be shared by all devices, services, and agents in the space,
stantiated with the name string “Harry’s Blue Phone”. (ii) acquire contextual information from sources that are un-
reachable by the resource-limited devices, (iii) reason about
There are two object properties in our ontologies. First, contextual information that cannot be directly acquired from
the ownedBy property has domain Device and range
the sensors (e.g., intentions, roles, temporal and spatial re-
Person. This asserts that the ownedBy property can re-
lations), (iv) detect and resolve inconsistent knowledge that
late a device to its owner (e.g., the device D2 is owned by is stored in the shared model of context, and (v) protect user
the person P2). The owns property is defined as an in- privacy by enforcing policies that the users have defined to
verse of the ownedBy property. This asserts that for every control the sharing and the use of their contextual informa-
triple (X, ownedBy, Y), there is a triple (Y, owns, X) and tion.
vice versa (since the inverse relation is symmetric). Thus,
from the example, since we know (P1, owns, D1), we
4.1 An Intelligent Meeting Room Scenario
can conclude (D1, ownedBy, P1), and similiarly since
we know (D2, ownedBy, P2), we can conclude (P2, The design of CoBrA is aimed to support context-aware sys-
owns, D2) also holds. tems in smart spaces. The following is a typical use case
scenario of CoBrA in an intelligent meeting room system:
3. WHY SEMANTIC WEB R210 is an intelligent meeting room with RFID sensors1 em-
A key requirement for realizing context-aware systems is to bedded in the walls and furniture for detecting the presence
give computer systems the ability to understand their situ- of the users’ devices and clothing. As Alice enters the room,
ational conditions. To achieve this, it requires contextual these sensors inform the R210 broker that a cell phone be-
information to be represented in ways that are adequate for longing to her is present and the broker adds this fact in its
machine processing and reasoning. We believe the Seman- knowledge base.
tic Web languages are well suited for this purpose for the
following reasons: As she sits, the agent on Alice’s Bluetooth enabled cell
phone discovers R210’s broker and engages in a “hand
• Ontologies expressed in the Semantic Web languages shake” protocol (e.g. authenticates agent identities and es-
provide a means for independently developed context- tablishes trust [12]) after which it informs the broker of Al-
aware systems to share context knowledge, minimizing ice’s privacy policy. This policy represents Alice’s desires
the cost of and redundancy in sensing. about what the broker should do and includes (i) the con-
text information about Alice that the broker is permitted or
• RDF and OWL are knowledge representation languages prohibited from storing and using (e.g., yes to her location
with rich expressive power that are adequate for modeling and roles, no to the phone numbers she calls), (ii) other
various types of contextual information, e.g., information agents that the broker should inform about changes in her
associated with people, events, devices, places, time, and contextual information (e.g., keeping Alice’s personal agent
space. at home informed about her location contexts), and (iii) the
permissions for other agents to access Alice’s context infor-
• Because context ontologies have explicit representations mation (e.g., all agents in the meeting room can access Al-
of semantics, they can be reasoned by the available logic ice’s contexts while she is in the room).
inference engines. Systems with the ability to reason
about context can detect and resolve inconsistent context After receiving Alice’s privacy policy, the broker creates a
knowledge that often result from imperfect sensing. profile for Alice that defines rules and constraints the broker
will follow when handling any context knowledge related to
• The Semantic Web languages can be used as meta- Alice. For example, given the above policy, the profile for
languages to define other special purpose languages such Alice would direct the broker (i) to acquire and reason about
as communication languages for knowledge sharing, pol- Alice’s location and activity contexts, (ii) to inform Alice’s
icy languages for privacy and security [12]. A key advan- personal agent at home when Alice’s contexts change, and
tage of this approach is better interoperability. Tools for (iii) to share her contexts with agents in the meeting room.
langages that share a common root of constructs can bet-
ter interoperate than tools for languages that have diverse Knowing Alice’s cell phone is currently in R210 and hav-
roots of constructs. ing no evidence to the contrary, the broker concludes Alice
is also there. Additionally, because R210 is a part of the
4. CONTEXT BROKER ARCHITECTURE Engineering building, which in turn is a part of the UMBC
The use of Semantic Web languages and tools are key fea- campus, the broker concludes Alice is located in Engineer-
tures in our Context Broker Architecture. In CoBrA, the ing building and on campus. These conclusions are asserted
OWL language is used to define ontologies for modeling into broker’s knowledge base.
context, providing common vocabaries for knowledge shar- Following the rules defined in the profile, the broker informs
ing, reasoning about the relation between the context and Alice’s personal agent of her whereabouts. On receiving this
the domain heuristic knowledge, and expressing user defined
policies. The core of our architecture is a specialized server 1
RFID stands for Radio Frequency Identification (see also http:
entity called context broker. //www.rfid.org)
 address this problem, we plan to investigate and develop
a fault-tolerance approach based on the Persistent Broker
Team [14] approach. Our idea is to introduce a team of bro-
kers in that each member has the responsibility to ensure
at least one broker is available to provide services. In the
case 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 team
members will attempt to recruit or instantiate new brokers.
In a broker team, the Joint Intention protocol [19] is used to
bring about the mutual beliefs of the team states and team
commitments.
A context broker has the following four functional compo-
nents:
Figure 2: A context broker acquires contextual informa- 1. Context Knowledge Base: a persistent storage of the
tion from heterogeneous sources and fuses it into a co- context knowledge. It provides a set of API’s for other
herent model that is then shared with computing entities components in a broker to access the stored knowledge.
in the space. It also contains the ontologies of a specific smart space
(e.g., the ontologies of an intelligent meeting room) and
some heuristic knowledge associated with the space (e.g.,
information about Alice, her personal agent attempts to de- a company’s daily operation hours are between 9:00 AM
termine why Alice is there. Her Outlook calendar has an en- to 5:00 PM; no person can be physically present at two
try indicating that she is to give a presentation on the UMBC different meeting locations during the same time inter-
campus about now, so the personal agent concludes that Al- val).
ice is in R210 to give her talk and informs the R210 broker
of it’s belief. 2. Context Reasoning Engine: a reactive inference engine
that reasons over the stored context knowledge. Two
On receiving information about Alice’s intention, the R210
types of inferences can take place in this engine: (i) infer-
broker shares this information with the projector agent and
ences that use ontologies to deduce context knowledge,
the lighting control agent in the ECS 210. Few minutes later,
and (ii) inferences that use heuristic knowledge to detect
the projector agent downloads the slides from Alice’s per-
and resolve inconsistent knowledge.
sonal agent and sets up the projector, the lighting control
agent dims the room lights. 3. Context Acquisition Module: a library of procedures
that forms a middle-ware abstraction for context acqui-
4.2 Context Broker
sition. The role of this component is similar to the role of
Figure 2 shows the design of a context broker. In smart the Context Widgets in the Context Toolkit [8], which is
spaces, context brokers are assumed to be running on to shield the low-level sensing implementations from the
resource-rich stationary computers that are embedded in the high-level applications.
environment (e.g., Mocha PC2 ). In our preliminary work, all
computing entities in a smart space are presumed to have 4. Policy Management Module: a set of inference rules
priori knowledge about the presence of a context broker. In that deduce instructions for enforing user policies. Some
the future design, we will attempt to use one of the avail- rules are defined for deciding the right permissions for
able service discovery infrastructure (e.g., Jini, UPnP) to different computing entities to share a particular piece of
improve system flexibility. Our centralized design of the context information, and some rules are defined for se-
context broker is motivated by the need to support small lecting the recipients to receive notifications of context
devices that have relatively limited resources available for changes.
context acquisition and reasoning. With the presence of a
broker, small devices such as cellphones, PDA and watches 5. PROTOTYPING AN INTELLIGENT MEETING ROOM
can offload their burdens of managing context knowledge To demonstrate the feasibility of our Context Broker Ar-
onto a resource rich context broker, including reasoning with chitecture, we are using CoBrA to prototype an intelligent
context, detecting and resolving inconsistent context knowl- meeting room system called EasyMeeting, which provides
edge. Furthermore, in an open and dynamic environment, assistants to meeting speakers, audiences, and organizers
users may desire their personal contextual information to be based on their situational needs. EasyMeeting is an exten-
kept in private. A centralized management of context knowl- sion to Vigil, a smart space system that we have previously
edge makes easy to implement privacy protection and infor- developed [21]. Security is the main focus in Vigil. A role
mation security. based access control mechanism is implemented in Vigil to
A centralized broker can be the “bottle-neck” in a distributed allow users control to the permissions to access different ser-
system, creating a single point of failure in the system. To vices using policies. Vigil differs from other frameworks in
using logic inference rules to reason about the rights of dif-
2
http://www.cappuccinopc.com/mochap4.asp ferent users.
Vigil has shown great promises in building flexible and se- Reasoning with the spatial containment relation can also
cure smart spaces [21]. However, it lacks the necessary sup- help the broker to detect errors in sensing. Let us assume in
port for context-aware systems. To improve upon Vigil, in addition to the location ontology, the broker also has some
EasyMeeting we use OWL to represent context ontologies, heuristic knowledge about the associated location, for exam-
and we exploit a context broker to support context reasoning. ple, ”no person can be physically present at more than one
atomic place during the same time interval”. When cou-
In the rest of this section, first, we overview the ontologies
pled with the location ontology, this knowledge can help the
that we have developed to support EasyMeeting and their po-
broker to detect if there is any inconsistency about a user’s
tential role in the context reasoning, and second, we describe
location context. Imagine that due to sensing errors, some
a prototype implementation of the context broker. sensors falsely detect the present of Alice and informs the
broker that she is located in the parking lot A. Since Alice
5.1 Ontologies
is known to be located in the room R230, and both the park-
We have developed a set of ontologies for modeling context ing lot A and the room R230 are atomic places, the broker
in an intelligent meeting room. This set of ontologies called can immediately conclude the location context of Alice is
COBRA-ONT defines typical concepts and relations for de- inconsistent with the known heuristic knowledge.
scribing physical locations, time, people, software agents,
mobile devices, meeting events. 5.1.2 Reasoning with the Device Ontologies
In a pervasive computing environment, devices in the imme-
5.1.1 Reasoning with the Physical Location Ontologies diate vicinity of a user are also part of the user’s context.
Understanding the context associated with physical loca- Device context can include basic knowledge about the de-
tions is extremely important in context-aware systems. An vice profiles (e.g., does a particular device support color dis-
ontology of physical locations in COBRA-ONT includes the play?), the device ownership relation (e.g., who is the owner
descriptions of places with identifiable geographic bound- of a particular device?), temporal properties associated with
aries (e.g., rooms, buildings), places with spatial properties a device (e.g., when was the last time a particular device has
(e.g., atomic places, compound places), and places with tem- been used?), and spatial properties associated with a device
poral properties (e.g., meeting rooms during the working (e.g., what is the distance between a particular device and
hours, offices on a public holiday). An ontology of the phys- the room in which its owner is currently in?).
ical location context include geographic attributes, typical
social norms of a particular place, objects that occupy or are To support reasoning with device profiles, COBRA-ONT in-
contained in a particular space, and events that occur at a cludes an ontology of device hardware and software profiles.
particular place. Parts of this ontology are adopted from the FIPA device on-
tology specification [9]. The hardware profile ontology in-
In our ontology the class Place is the parent class of cludes concepts of screen displays (e.g., screen width and
all represented place classes. Subclasses of Place are length, display color profile), device memory (e.g., amount
Campus, Building, Room, Hallway, Parkinglot, of memory, memory size unit, and memory usage type),
Restroom, and ConferenceRoom, which are concepts device network capability (e.g., support for wireless/wired
of places with identifiable geographic boundaries. communications, supported network interfaces). The soft-
COBRA-ONT divids subclasses of Place into types of ware profile ontology includes concepts of device operating
either atomic place or compound place, which are con- systems and supported computing platforms.
cepts of places with spatial properties. Atomic places (e.g., By extending the device profile ontology, COBRA-ONT
ConferenceRoom, Hallway) are places that cannot be provides an ontology of mobile devices. The goal is to de-
defined to spatially subsume other places. Compound places fine specific ontology classes that represent different types of
(e.g., Campus, Building) are places that can spatially mobile devices and properties that are associated with these
subsume other atomic or compound places3 . devices. Represented types of mobile devices are SonyEr-
Spatial containment inference is a type of reasoning with lo- icsson T68i, SonyEricsson T800, and Palm TungstenT. De-
cation context. Let us consider the scenario described in Sec- fined properties include the hardware and software profiles
tion 4.1. As Alice enters the conference room, information of these devices and additional relations that associate the
acquired from the sensors in the room may lead the con- devices with people. For example, the ownedBy property
text broker to conclude that Alice is in the room R230. Be- expresses the relation between a device and its owner, and
cause the broker has an ontology of the associated location the usedBy property expresses the relation between a de-
(e.g., the Engineering building spatially subsumes the room vice and its user. Both of these properties have inverse prop-
R230, and the UMBC main campus spatially subsumes the erties (i.e., the owns and uses properties).
Engineering building), the broker can draw new conclusions To illustrate how reasoning with device ontologies can play
about Alice’s location context, e.g., Alice is located in the a role in context-aware systems, let us consider the follow-
Engineering building, Alice is located on the UMBC main ing use case: after Alice enters the meeting room R230, her
campus. cellphone presents Alice’s policy to the context broker in the
3 room. Assuming the context broker has an ontology of the
Note that present ontology do permit the definition of some illog-
ical statements, e.g., a building spatially subsumes a campus (since device that sends the policy, it reasons about the profile of the
they both are type of compound place). We are developing solu- device, e.g., the sender is a type of SonyEricssonT68i cell-
tions to resolve this problem in the next version of the ontology phone, and its Bluetooth communication supports the OBEX
object push service for exchanging vCard contacts. Know- The DAML-time ontology defines a number of predicates
ing the device profile, the context broker informs all meeting (properties) for linking time entities to events in the real
services that could take advantage of this information, e.g., world5 , which include atTime, expressing an event occurs
a contact exchange service that can automatically push new at a particular time instant, during, express an event occurs
contact information into the mobile devices that a meeting during a particular time interval, and holds, expressing an
participant carries. Additionally, the context broker reasons event holds at a particular time instant or during a particular
about the person who owns and uses the device (e.g., the per- time interval.
son Alice is the owner of this device, and no evidence shows
To illustrate the use of temporal ontology, let us consider
the device is used by other people). Since Alice’s SonyEr-
icsson T68i cellphone is the room R230 and no evidence to the following the use case: while Alice is in the room R230,
the contrary, the context broker concludes Alice is also in the different sensors notify the context broker of her presence.
room R230. Each notification is linked to a particular time instant, e.g.,
an RFID sensor reports atTime(locatedIn(Alice,
R230), clockTime("13:04")) and a facial recog-
5.1.3 Reasoning with the Temporal Ontologies nition sensor reports atTime(locatedIn(Alice,
Aspects of context can also include temporal relations. R230), clockTime("13:45")). As the pred-
To support reasoning with time and temporal relations, icate clockTime represents a time instant, the
COBRA-ONT adopts the DAML-time ontology, which is context broker can deduce the temporal ordering of
a temporal ontology for expressing temporal aspects of the the time during which Alice is located in the room
contents of web resource and for express time-related prop- R230, e.g., during(locatedIn(Alice, R230),
erties of web services [11]. The DAML-time ontology in timeInterval("13:04-13:45")).
COBRA-ONT is an OWL version of the original DAML-
time ontology that is expressed in the DAML+OIL lan- Knowing Alice is in the room R230 during a partic-
guage4 . ular interval, the context broker can reason about her
relation to the events in the room. For example, at
The DAML-time ontology builds around a set of abstract clockTime("13:55"), the context broker learns that
temporal entities and temporal relation axioms. Our OWL the room R230 is hosting a meeting which begins at
representation of the ontology defines the vocabularies of clockTime("13:00"). From its knowledge about
the abstract temporal entities. However, it does not include Alice’s location (i.e., during(locatedIn(Alice,
a representation of the temporal relation axioms because the R230), timeInterval("13:04-13:45"))), the
present OWL language does not have direct support for ex- broker concludes that Alice is probably attending the
pressing axiomatic rules. Research in developing language meeting because timeInterval("13:04-13:45") is
constructs for representing rules in Semantic Web languages in between of the time instants clockTime("13:00")
is underway [10]. and clockTime("13:55").
In DAML-time the abstract temporal entity classes are
Instant and Interval. Both are subclasses of the 5.2 A Context Broker Prototype
TemporalEntity class. A member of the Instant We have implemented a context broker prototype to demon-
class represents an instant of time, which has associated tem- strate its role in the EasyMeeting system. Our objective is
poral description properties that represent the concepts of to show the Semantic Web languages are adequate for dy-
second, minute, hour, day, month, year, and time zone. A namically constructing representations of context informa-
member of the Interval class represents a time interval tion acquired from sensors, and how this information then
between two different time instants. Properties of this class can be used to infer additional context knowledge. In our
include beginOf and endOf, which define the beginning present implementation, a context broker can reason about
time (a time instant) and the ending time (a time instant) of the presence of people and device in an intelligent meeting
a time interval. room.

A type of relation between the individuals of the Figure 3 shows the design layout of our prototype system.
TemporalEntity class is temporal ordering. The tem- Central to the system is a context broker. This broker is im-
poral ordering relation can be expressed in the before and plemented as a FIPA compliant agent that runs on the JADE
the after properties, i.e., an individual of the Instant platform (a Java library for building FIPA compliant agents)
or Interval class can have a before or after prop- [2]. The broker uses the Jena Semantic Web Toolkit6 for
erty value of another individual of Instant or Interval managing and manipulating ontologies (e.g., dynamically
class. The temporal ordering relation can also be expressed constructing OWL ontology statements for agent communi-
using the inside and time-between properties, which cations, manipulating ontology knowledge that is stored in a
describes a time instant is inside of a particular time in- persistent knowledge base).
terval, and a time interval is in between of two different RDQL (RDF Data Query Language) is used in the broker’s
time instants, respectively. reasoning engine to access the stored ontology knowledge.
Using RDQL, the reasoning engine periodically queries the
4
To convert DAML-time from DAML+OIL to OWL, we have used 5
the OWL Coverter, a tool for automating ontology conversion from Descriptions of events are assumed to be defined by ontologies
DAML+OIL to OWL (http://www.mindswap.org/2002/ that are outside of the DAML-time ontology
6
owl.html) http://www.hpl.hp.com/semweb/jena.htm
 To show the underlying ontology reasoning in the broker,
we have developed a web application, backed by the Apache
Tomcat Server, for viewing the internal knowledge base of
the context broker. In future, this web application will in-
clude administrator functions for manging a context broker
(start, shutdown etc.).

6. RELATED WORK
In 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]. These
Figure 3: In our prototype system, the broker attempts systems have made progress in various aspects of pervasive
to infer the location context of devices and users. An user computing but are weak in supporting knowledge sharing
model is dynamically acquired from an URL specified in and context reasoning. A significant source of this weak-
the received user policy. ness is their lack a common ontology with explicit semantic
representation [6, 5].
Key differences between our architecture and the previous
knowledge base for the presence of certain context knowl- systems are the following:
edge (e.g., has any device been detected in the room, who
• We use Semantic Web languages (i.e., RDF and OWL) to
is the owner of a particular device?). When queries return
define ontologies of contexts, providing an explicit repre-
matched results, the broker automatically inserts new asser-
sentation of contexts for reasoning and knowledge shar-
tions about the local context into its knowledge base. For
ing. In the previous systems, contexts are often imple-
example, if queries return information about the presence of
mented as programming objects (e.g., Java class objects)
a new device and the person who owns the device, then the
or informally described in documentations.
broker asserts the owner of the device is also present in the
room. • In CoBrA a resource-rich agent (i.e., the context broker)
For context sensing, the context broker delegates the tasks to is provided to manage and maintain a shared model of
other sensing agents in the environment. When the broker context for all devices, services and agents in an associ-
starts on a hosting JADE platform, it finds all sensing agents ated space. In the previous systems, individual entities
that are registered with the local yellow page service (FIPA are required to manage and maintain their own context
Directory Facilitator) and sends a FIPA subscribe message to knowledge.
these agents, requesting to be notified about context changes.
In our prototype system, we have implemented a sensing • The context reasoning in CoBrA gives context brokers
agent called BT Sensor, which is responsible for detecting the ability to infer new context knowledge (e.g., spatial
Bluetooth OBEX object push events that are initiated by the relations, device profiles) that cannot be easily acquired
mobile devices. As a mobile device sends an OBEX ob- from the physical sensors. In the previous systems, con-
ject to the BT Sensor (e.g., a SonyEricsson T68i cellphone texts acquired from sensors are presumed to be accurate
sends a vNote object to the BT Sensor), the BT Sensor agent and consistent.
concludes the presence of the device and notifies the context
broker. • The use of policies in CoBrA allow users to control their
contextual information, specifying the granularity of in-
Messages sent from a Bluetooth device to the BT Sensor formation that is shared by the systems and choosing re-
agent contains a FIPA ACL message that informs the context cipients to receive notifications of their context changes.
broker of a user’s background information (or user model). In preivous systems, acquired contextual information is
A user model includes a privacy policy that a user defines allowed to be freely share by all computing entities in the
to control the use and the sharing of his/her context infor- environment, which could potentially jeopardize user pri-
mation. Due to the message size limitations in our Blue- vacy.
tooth devices, messages sent by the devices contain the URL
of the web documents that have complete descriptions of 7. CONCLUSION & FUTURE WORK
the user models. The representation of this URL informa- The use of ontology is a key requirement for realizing perva-
tion is expressed in a RDF statement which is encoded in sive context-aware systems. Our preliminary research in the
N3 [3], for example, "agt:HarryChen agt:aboutMe Context Broker Architecture shows the Web Ontology Lan-
http://umbc.edu/hchen4/aboutMe.". The first guage OWL is adequate for defining ontologies for support-
term agt:HarryChen is a subject RDF resource that de- ing context reasoning and knowledge sharing. As Semantic
fines this statement is about the user Harry Chen. The sec- Web technologies and tools (i.e., programming libraries for
ond term agt:aboutMe is a property of the subject. The manipulating ontologies and logic inference engines for on-
last term is the value of the property, which is an URL tology reasoning), we believe the Semantic Web will create
from which the user model of agt:HarryChen can be re- new research opportunities for building pervasive context-
trieved. aware systems.
At present the development of CoBrA and the EasyMeeting [13] Tim Kindberg and John Barton. A Web-based nomadic
system is still in the early stage of research. Our short-term computing system. Computer Networks (Amsterdam,
objective is to define an ontology for expressing privacy pol- Netherlands: 1999), 35(4):443–456, 2001.
icy and to enhance a broker’s reasoning with users and ac-
tivities by including temporal and spatial relations. A part of [14] Sanjeev Kumar, Philip R. Cohen, and Hector J.
our long-term objective is to deploy an intelligent meeting Levesque. The adaptive agent architecture: Achieving
room in the newly constructed Information Technology and fault-tolerance using persistent broker teams. In
Engineering Building on the UMBC main campus. Proceedings of the Fourth International Conference
on Multi-Agent Systems, pages 159–166, 2000.
REFERENCES
[15] Deborah L. McGuinness and Frank van Harmelen.
[1] R. Scott Cost andTim Finin andAnupam Joshi, Yun Owl web ontology language overview.
Peng, Charles Nicholas andHarry Chen, Lalana Kagal, http://www.w3.org/TR/owl-features/,
Filip Perich andYouyong Zou andSovrin Tolia, and 2003.
Ian Soboroff. Ittalks: A case study in the semantic
web and daml. In proceedings of the International [16] Nissanka B. Priyantha, Anit Chakraborty, and Hari
Semantic Web Working Symposium, July 2002. Balakrishnan. The cricket location-support system. In
Mobile Computing and Networking, pages 32–43,
[2] Fabio Bellifemine, Agostino Poggi, and Giovanni 2000.
Rimassa. Developing multi agent systems with a
fipa-compliant agent framework. Software - Practice [17] Daniel Salber, Anind K. Dey, and Gregory D. Abowd.
And Experience, 31(2):103–128, 2001. The context toolkit: Aiding the development of
context-enabled applications. In CHI, pages 434–441,
[3] Tim Berners-Lee. Primer: Getting into RDF & 1999.
Semantic Web using N3, 2003.
[18] Bill Schilit, Norman Adams, and Roy Want.
[4] Tim Berners-Lee, James Hendler, and Ora Lassila. Context-aware computing applications. In IEEE
The semantic web. Scientific American, may 2001. Workshop on Mobile Computing Systems and
Applications, Santa Cruz, CA, US, 1994.
[5] Harry Chen. An intelligent broker architecture for
context-aware systems. PhD. dissertation proposal. [19] Ira A. Smith and Philip R. Cohen. Toward a semantics
See http://users.ebiquity.org/ for an agent communication language based on speech
˜hchen4/phd/hcthsisp.pdf, 2003. acts. In Howard Shrobe and Ted Senator, editors,
Proceedings of the Thirteenth National Conference on
[6] Harry Chen, Sovrin Tolia, Craig Sayers, Tim Finin, Artificial Intelligence and the Eighth Innovative
and Anupam Joshi. Creating context-aware software Applications of Artificial Intelligence Conference, Vol.
agents. In Proceedings of the First GSFC/JPL 2, pages 24–31, Menlo Park, California, 1996. AAAI
Workshop on Radical Agent Concepts, 2001. Press.
[7] Michael H. Coen. Design principles for intelligent [20] Michael K. Smith, Chris Welty, and Deborah
environments. In AAAI/IAAI, pages 547–554, 1998. McGuinness. Owl web ontology language guide.
http://www.w3.org/TR/owl-guide/, 2003.
[8] Anind K. Dey. Providing Architectural Support for
Building Context-Aware Applications. PhD thesis, [21] Jeffrey Undercoffer, Filip Perich, Andrej Cedilnik,
Georgia Institute of Technology, 2000. Lalana Kagal, Anupam Joshi, and Tim Finin. A secure
infrastructure for service discovery and management
[9] Foundation for Intelligent Physical Agent. FIPA in pervasive computing. The Journal of Special Issues
Device Ontology Specification, pc00091a edition, on Mobility of Systems, Users, Data and Computing,
2001. 2003.
[10] Benjamin N. Grosof, Ian Horrocks, Raphael Volz, and [22] Frank van Harmelen, Jim Hendler, Ian Horrocks,
Stefan Decker. Description logic programs: Deborah L. McGuinness, Peter F. Patel-Schneider, and
Combining logic programs with description logic. In Lynn Andrea Stein. Owl web ontology language
12th International Conference on the World Wide Web, reference.
2002. http://www.w3.org/TR/owl-ref/), 2002.

[11] Jerry R. Hobbs. A daml ontology of time. http: [23] Roy Want, Andy Hopper, Veronica Falcao, and Jon
//www.cs.rochester.edu/˜ferguson/ Gibbons. The active badge location system. Technical
daml/daml-time-20020830.txt, 2002. Report 92.1, Olivetti Research Ltd., ORL, 24a
Trumpington Street, Cambridge CB2 1QA, 1992.
[12] Lalana Kagal, Tim Finin, and Anupam Joshi. A policy
language for a pervasive computing environment. In
IEEE 4th International Workshop on Policies for
Distributed Systems and Networks, 2003.