Towards A General Approach for Reasoning about Context, Situations and Uncertainty in Ubiquitous Sensing: Putting Geometrical Intuitions to Work

Text-only Preview

Padovitz, A., Loke, S.W., Zaslavsky, A., Burg, B. "Towards a General Approach for Reasoning about Context,
Situations and Uncertainty in Ubiquitous Sensing: Putting Geometrical Intuitions to Work", 2nd International
Symposium on Ubiquitous Computing Systems (UCS'04), Tokyo , Japan , November, 2004.
Towards A General Approach for Reasoning about Context, Situations and
Uncertainty in Ubiquitous Sensing: Putting Geometrical Intuitions to Work 1

Amir Padovitz², Seng Wai Loke², Arkady Zaslavsky² and Bernard Burg³
²School of Computer Science and Software Engineering, Monash University, Australia
{amirp,swloke,[email protected]},
³HP Labs, Palo-Alto, [email protected]

unambiguous and well known situations but face
Context uncertainty and the incurred complexity of
difficulties to adapt to or resolve more intricate or
reasoning about context necessitate investigation of
uncertain situations.
context awareness that would provide feasible solutions
Software engineering of this breed of systems is
by means of models, architectures and algorithms.
needed in order to facilitate design and development of
In this paper we discuss our approach for reasoning
more adaptable, reasoning-capable and powerful context-
about context under uncertain conditions in pervasive
aware systems. Engineering such systems is not only a
environments and explore the theory, design and
question of toolkits and ontologies but also of approach
implementation of a reasoning engine, which makes use
and methodology, as well as abstractions and concepts [7,
of a novel modeling approach for describing and
6, 13]. In this paper we discuss our approach for
reasoning about context. We discuss both a theory, which
reasoning about context under uncertain conditions in
is the basis for the reasoning processes as well as analyze
pervasive environments and explore the theory, design
the functional activity of the reasoning engine during
and implementation of a reasoning engine, which makes
use of a novel modeling approach for describing and

reasoning about context. In Section 2 we start by
1. Introduction
providing a general overview of the functional stages
The advent of the pervasive computing paradigm has
used during the reasoning process. We follow in Section
created an emerging necessity for adaptability and
3 with a discussion of the theory behind the general
automation of systems [12, 4]. Coupled with a desire to
functional stages, and provide selected parts of our
enrich user experiences, an investigation of the context in
context modeling approach, concerning fundamental
which systems operate and need to adapt to, and the
modeling concepts and algebraic operations. We refer to
awareness of such systems to changes in this context has
this model as the Context Spaces model. The concepts of
our modeling approach provide the foundations of the
The complexity associated with pervasive engine’s reasoning processes and are used in Section 4 to
environments and the diversity of possible situations that
explain actual functional activities taking place during the
may affect context-aware applications’ behavior and their
experimentation phase. In this section we discuss
incurred reasoning complexity, necessitate extensive
implementation details and provide results and analysis of
investigation and research in the field of context-
selected experimental runs that exhibit the uncertain
awareness. Such research would need to provide feasible
nature of reasoning about context. We conclude in
solutions by means of models, architectures and
Section 5.

Consequently, emerging research has begun to look at
2. General Overview of the Reasoning Engine
context-aware systems more generally, independently of
We explore a single component within an overall
specific applications, and in recent years, has focused on
architecture for context-aware computing system, namely,
various aspects concerning context, including
a reasoning engine, termed ReaGine, its design principles
middleware and toolkits [2, 5, 1] that abstract concepts
and theoretical foundations, which are based on a novel
and assist in gathering information for reasoning about
context modeling approach. We start by providing a
context, and ontologies that provide vocabularies to
general overview of the functional stages that are used
describe context [2, 3]. While middleware and toolkits
during the engine’s reasoning processes.
assist in the acquisition of contextual data (e.g. [14]) and
Figure 1 illustrates five basic functional steps taken by
its dissemination across the context-aware platform, they
ReaGine during the reasoning process. Reasoning starts
do not handle the complexities associated with the
when information arrives to the reasoning engine either as
inconsistent and uncertain nature of context. By obtaining
raw data or as basic reasoned context, often as a result of
and possibly fusing together data, either physical or
data fusion, preformed elsewhere. It is then checked for
virtual, systems are mostly capable of dealing with
low-level discrepancies (e.g. contradicting evidence

1 We thank HP Labs for collaboration and financial sponsorship of this work

between sensors). During this stage more elaborate
3. A Model of Context Spaces
verification techniques are also employed, resulting in
recommended alternate values for suspicious sensor
Having broadly discussed the functional stages of the
readings. At the next stage, the data is synthesized
reasoning processes taken by ReaGine, we now explore
according to concepts drawn from the Context Spaces
the theoretical foundation for our reasoning approach. We
model and inferred as a collection of what we call basic
will examine selected parts of the entire model,
situations. These inferred situations are uncertain,
containing a sample of basic concepts and sub-concepts,
however, as we deal with only a partial view of the model
which we will use in a later stage when we discuss
due to the degree of uncertainty associated with context.
implementation and analysis of the reasoning
The functional stage of merging contextual information
performance in experimental runs.
does not consider the uncertain nature of context,
There are many dimensions of context. Context can be
manifested through context inconsistencies between
hierarchically structured [13] and/or categorized into
seemingly parallel situations. The reasoning process
different domains (e.g. social, location based,
considers factors related to context uncertainty, such as
physiological, historical etc. [8, 12]) and can denote
(1) insufficient data to infer context, which may be the
different levels of abstraction, depending on the desired
result of cost efficiency considerations, (2) inherent
situation to be modeled and the types of available
inaccuracy of sensors, (3) the use of not up-to-date
information. Models that attempt to capture and express
information (also affected by the system design and push-
context details often investigate concepts and abstractions
pull sensor technology), (4) context ambiguity, which is
that are closely related to the application level. An
often the result of limitations in the deployment and types
example of common abstractions of this sort for entities
of sensors, (5) unknown contextual situations, which are
in a pervasive system is those of persons, places and
true situations (possibly relevant to the system) that the
things [9]. These kinds of modeling are important in
system is unable to infer, and (6) conflicting or
identifying key abstractions that are central in many
contradicting low-level data information.
applications but which are nevertheless still application-
The engine then attempts to discover conflicts (e.g.
oriented. It has been suggested in [13] that many other
ambiguous situations or situations that cannot co-exist) at
information sources other than location and places (and in
the conceptual level, between these basic situations by
this manner other key abstractions) often play important
performing analytical procedures, using operations that
roles in context-aware applications.
are defined in Context Spaces algebra, and implemented
as a set of operations in a separate library. Conflicting
Our approach uses a more fundamental perspective
situations are dealt with in an additional verification
over context than the above mentioned models, by
phase, which attempts to resolve or verify the true
characterizing context and its behavior from the context
situation’s nature. Finally, situations that were not
attributes level and proposing concepts to model and
disqualified during the previous stages are composed into
examine basic elements that make up context. This results
more complex situations and compared with policies
in the ability to develop generic reasoning capabilities
predefined by the system designers. These final complex
about context. We then examine concepts and practices
situations need not be predefined but are the result of the
that map these ideas into the real-world of application
five reasoning stages discussed above.
domains. Finally, we use a set of software engineering
abstractions similar to other conceptual models, which we

make use of according to specific application needs. We
Situation Composition

defer a short discussion on the latter to the
implementation section.

3.1 Basic Terminology and concepts

A fundamental aspect in our modeling approach is the

treatment of context as a system, where we distinguish
Conflict Analysis

between the current application state in regard to some
context and the broader definition of that context and to

which the current state belongs. We use the following
Knowledge Synthesis
definitions for the basic concepts in the model:

Context state
Low-Level Discrepancies Discovery
We term the application current state in relation to chosen

context as context state and model it with a vector Si as a
collection of context attributes’ values that are used to

Data Fusion
represent a specific state of the system at time t.

Raw Data
We assume a deliberate choice of context attributes by the
context-aware system that enables the mapping of their
Fig. 1 – Reasoning engine functional stages
values to a context state and therefore presuppose the

ability to infer the current situation for any set of attribute
subspace. The notion of a context state being outside or
within a situation subspace is illustrated in figure2.
Let S = (a , a ,..., a )
Where S denotes a vector defined over a collection of N
attribute-values, where each value a corresponds to an
attribute a value at time t, representing the true context
state i at time t.

A context attribute is defined as any data that is used to
describe element/s that can be used in the process of
Risituation subspace
inferring situations. A context attribute is often associated
Ci - context state, inside subspace
with sensors, either virtual or physical, having the value

Cj - context state, outside subspace
of the sensor readings denote the context attribute value.

Let a denote an attribute i’s value at time t.
Fig. 2 - Visualization of situation subspace and context
a is a specific attribute, which often denotes a specific

sensor. When adding time subscript tagging we denote
Situation types
the value of the attribute at specific times.
We categorize situations into three types: (1) basic

situation, which is the result of a simple reasoning
Situation subspace
process, by which a context state is proved to be
We conceive of a vector space R = (a , a ,..., a ) as
contained in some situation subspace, (2) refined
a situation subspace i, consisting of N acceptable regions
situation, which is the result of consistency checks and
for these attributes. A situation subspace represents a
verification processes, after which a context state is
static definition for regions of attribute values
associated with specific non-conflicting situations, and
corresponding to some predefined situation.
(3) complex situation, which is the result of merging
together or intersecting existing (basic or refined)
An accepted region a is defined as a set of elements V
situation subspaces.
that satisfies a predicate P, i.e. a = {V |P(V)}. For

example, in numerical form the accepted region would
3.2 Algebraic Operations
often describe a domain of permitted real values for an
Having defined basic concepts that capture
attribute a .
multidimensional aspects of the contextual situations in
While R defines permissible values for attributes, it does
terms of state and space, we now specify a set of
operations that examine relationships between these
not automatically associates a context state with a specific
concepts and can be used in the process of modeling and
situation subspace. Rather, it negates the possibility of
reasoning about context. In the context of this work we
being in other subspaces that do not contain the state. The
will only discuss two operations; for more detailed
reason for this is the possibility of having subspaces
discussions on the algebra and Context Spaces model, the
intersect, having the possibility of the state corresponding
reader is referred to [10, 11].
to more than one situation. We therefore say that a
context state belongs to some situation iff some function
Space Intersection
associates the state to some situation defined by R . An
The intersection operator results in a new situation
example of such function would be a verification process,
subspace that contains shared regions of values of the
after which a context state is resolved to belong to a
same attributes between two comparable situation
particular situation, or a conflict discovery process that
approves the consistency of that situation subspace.
In order to define the intersection of two situation
We can represent the relationships between context
subspaces, we first define the intersection of two accepted
states and situation subspaces graphically, where specific
regions as follows.
context states (either historical or current) can be
Given accepted regions A = {V |P(V)} ⊆ T and B = {W
visualized within (corresponding to the context
|Q(W)} ⊆ T , where T is some universal set of values
description) or outside (contradicting the context
(i.e., A and B are subsets of the same set, effectively of
description) the situation subspaces. A system’s context
the same type), then the intersection of A and B, denoted
state would most often be visualized as a
by is defined as follows:
multidimensional single point in space, contained within

the tolerable region of acceptable values of some situation
B e
( A
B) iff P(e)
Q(e) .

Basically, the intersection of two accepted regions is the
Heart rate
Respiratory Body Temp.
set of elements that satisfies predicates P and Q.
The intersection of two context spaces

R = ( R
a , R
a ,..., R
a )
S = (b , b ,..., b ) is

Walking 100 - 160
20 - 28
denoted by R S (where we rely on context to
Running 150 - 200
26 - 40
distinguish from intersection of accepted regions) and is
150 - 160
26 - 28
36.61 – 36.62
defined as follows:
R S = ( R
c , R
c ,..., R
c , R
,..., R
a , R
,..., R
b )
K 1
K 1
where we assume that the first K (<= min (N,M))
attributes are the same (without loss of generality) though
their accepted regions might not be, i.e.
c = a = b ,..., c = a = b ,
and c = a b ,..., c
= a b (the accepted
regions for the common attributes are formed by
intersecting the accepted regions of the respective
attributes from the two context spaces).
We can use the intersection operator to produce new
situations that are the product of two or more situations.
The contribution of intersecting situations is the

introduction of new situations that are unfamiliar to the
Fig. 3 - definition and visualization of ‘Walking’ and
context-aware system (e.g. complex situations), which we
‘Running’ situation subspaces
regard as an initial step towards intelligent adaptability

and discovery of unfamiliar, not pre-defined situations, by
the system.
Let a and a denote values of corresponding attributes
As an example, we can model situation subspaces for
of the same type for the context state and situation
‘subject is running’ and ‘subject is walking’ situations
subspace, respectively.
with the following attributes: Heart Rate, Respiratory
Let aˆ
a define an attribute value that is contained in
Rate and Body Temperature. The accepted region of
values of these attributes for the two situations and their
the set a , which has the most similar value to a ,
visualization are given in figure 3. A new situation
where similarity between two identical attribute values is
subspace, which is the result of the intersection of the
defined by the application designers and reflected with
basic situations, can be visualized as the shared area
positive numerical values, such that the smaller the value
between the two spaces.
the more similar are the two attribute values.
The intersection operator is useful for identifying
Let aˆ reflect a numerical value, denoting the acceptable
ambiguous or conflicting situations, in which a system
needs to determine the correct situation or situations,
region’s absolute size, such that ˆ
= a a | ,
when some of these situations cannot co-exist. In the
example above when a context state is situated within the
where a and a denote minimum and maximum
intersection space of ‘running’ and ‘walking’ and
assuming a subject cannot be both running and walking at
values of the accepted region a , and where for
the same time, a system needs to decide whether the
subject is a very fit runner or actually not very fit (and is
simplicity, we assume a continuous region of acceptable
actually walking).

We then define the State-Space Difference operator as:
State-Space Difference
| a r
aˆ |
One of the operators that examine the degree of
State-Space Difference =

similarity between context state and situation subspace is
the State-Space Difference operator, with which we
This operator is useful for assisting in the adaptation
measure similarities between situation subspaces and
process for unknown situations, where the application can
context states.
reveal the similarity of a current context state to
The following operator holds only for quantifiable
predefined situation subspaces. The definition also
attributes where such values exist. We make use of other
accounts for normalization needs when comparing
operators, which are described in [11], which account for
different types of attributes with inherently different sizes
non-numerical attribute values.
of regions.

As an example, consider the scenario of ‘running’ and
‘walking’ situations in the earlier subsection. Suppose the

system encounters sensor readings corresponding to the
situations, their direction and reasonable time limits of
following state: S = (210BpM, 30BrpM, 36.62dc). As
transition between these situations.
The use of this semantic description is illustrated in figure
this state does not belong to any of the known situation
4a and 4b, where we describe possible situations inferred
subspaces, the system tries to adapt and treat the
by the system according to two physiological context
unknown state by finding the most similar context space.
attributes. In this example, the current context state is
The calculation yields a much lesser difference to the
situated in the intersection of the ‘Running’ and ‘Sick’
‘running’ situation subspace (0.2) than to the ‘walking’
situation subspaces. We assume that a subject can be both
situation subspace (1.083). The system adapts by
sick and running, since these two situations are defined as
inferring the ‘running’ situation and performs appropriate
compatible elsewhere. The reasoning problem that arises
actions, accordingly. The decision to perform this
calculation, the allowed difference from which adaptation
here is whether the subject is only running ( S
to a specific situation is performed and whether at all
‘Running’)? Or only being sick ( S ∈’Sick’)? Or is
adaptation is sensible, is application specific.

actually both running and being sick at the same time
( S ∈‘Running’ ∩ ‘Sick’)?
3.3 The Semantic Layer – bridging the
application domain gap
Figure 4b provides an illustration of possible conceptual
natural flows between defined situations. We also assume
We have so far discussed basic concepts in the model
that reasonable transition periods between these situations
and have illustrated the use of operations over these
are defined. We can use such knowledge to assist in
concepts. A problem that needs to be addressed though, is
inferring the correct situation, as follows. A verification
the applicability of the general model to different
procedure searches the knowledge-base for previous
application oriented scenarios and environments. In other
inferred situations and discovers that at time t − λ (say
words, ideas, operations and techniques derived from the
10 seconds ago) the subject was in the ‘Walking’
model are applicable as long as they make sense to the
t −λ
situation ( S
∈’Walking’). It then reveals that at time
application at hand.
The result of a Space Intersection operation for example,
t − λ the subject was not in the ‘Sick’ situation
may have different meanings and consequences for
t −λ
( S
∉’Sick’). It then infers that it is more probable for
different applications that operate in different domains. It
is therefore important to model the nature of possible
the subject to be currently running (e.g. If
t −λ
t −λ
interactions and applicability of various elements in the
∈‘Walking’ AND S
∉’Sick’ then infer the
model so that we can translate the general theory into
‘Running’ situation).
practical uses.
We conceive of a second, higher level of semantic
concepts on top of the general model (as described up to

this point), which we make use of to map the model into

specific application domains. Within this layer we

provide information regarding the nature of semantic

entities in the model (e.g. situations), such as their
compatibility (e.g. can they co-exist?) or provide

information regarding mapping of attributes semantic

values into numerical ones. While some attributes types
can be expressed more naturally semantically, it is

Respiratory Rate
possible to represent them numerically as well. We have
Fig. 4a – situation co-existence problem
addressed this issue in [11] where we discussed a
technique that enables us to quantitatively specify values

and domain of values that correspond to a variety of

attributes, including semantic ones. The ability to model
context numerically enables us to apply useful techniques

over context that require values quantification.

As an example, we will now describe a representation
technique that can be used for reasoning and conflict


Situation Natural Flow
Fig. 4b – situations natural flow
An important aspect we model in the semantic layer of
the model is characteristics of situation subspaces. An
4. Implementation and Experimental Evaluation
example of such characteristic is situation natural flows. -
The reasoning engine implementation follows the
by this, we refer to possible logical evolution of
steps illustrated in the functional analysis diagram at

section 2, and was developed to provide reasoning
possible contradicting situations. Consequently, we
capabilities that partly overcome uncertainty problems
expected the system to adapt or verify the true nature of
associated with context, by leveraging on general
the situation through the use of the reasoning capabilities.
techniques based on the Context-Spaces model. A

separation of the application semantics from the
4.1 Sensor inaccuracies
reasoning procedures and techniques that are built on a
In the first example, situation subspaces and semantic
generic model that represent context enables easy
configurations were defined to capture context details
deployment and use of the engine in a variety of different
corresponding to three types of situation abstractions,
namely, (1) User related situations, which are situations
To illustrate feasibility and advantages of our approach
specifically associated with a user and inferred for a user.
we demonstrate the engine’s reasoning for a simulation of
(2) Location related situations, which denote situations
an office environment use case, and provide walk-through
associated with specific locations. And (3) General
and analysis of its behavior.
situations, which are situation that can take place in
In this set of experiments we deployed several
several places involving different users at the same time.
Monitor services, physically distributed over the network.
We configured the system to denote typical office
Each such Monitor service communicated with processes,
situations such as meetings, presentations, users of the
simulating independent sensors, during which it either
system and meaningful locations in the networked
actively acquires raw data or passively waits for data to
environment. We will examine simulated sensor readings,
be push by the sensors, according to the sensor type. Each
corresponding to the general situation of a meeting (that
sensor is individually configured to follow specified
can take place in any employee’s office as well as in the
pattern of behavior that is characterized by value and type
meeting room and presentation theatre) and a user ‘John’
of data it produces, how often new data is produced,
who participates in this meeting at his office.
inherent inaccuracy associated with the sensor (reflected
In this initial stage of the experimental run the reasoning
by random errors values added to the basic value with
engine successfully inferred the general meeting situation
specified variation over time) and type of access available
and associated the user with the meeting and with a
by the sensor (push or pull).
meaningful location. Figure 6 presents the reasoning
Raw data collected by a Monitor service is pushed via
engine’s results for this run.
distributed communication (and message queuing

technology for scaling purposes) to a centralized
knowledge-base, which is the source of information for
the reasoning engine in this experiment. The reasoning
engine itself can both be triggered by events originating
from remote Monitor services as well as periodically
performing reasoning actions. Figure 5 provides the
deployment architecture used during the experimentation.

<raise process>
Data As
Data A si
ssi m

Data Assimilator

Load Monitor


Algorithms Library
Data Inserter
<raise process>
Data Inserter
Data Inserter

Reasoning Engine

Stability Analyzer


Fig. 6 – Basic experimental run

The form in figure 6 is designed to denote three levels of

reasoning: (1) inferred Basic Situations that are the result
Fig. 5 – The general architecture in which ReaGine
of the knowledge synthesis phase. (2) Reasoned
Situations, which are situations that were produced after
In this set of experiments we were interested not only in
more elaborate reasoning and/or verification processes
performing basic reasoning but also in reasoning about
(initiated when discrepancies or conflicts are revealed).
situations that were not obvious to the system, either by
(3) Complex Situations, which are the result of
not fully corresponding to existing definitions, exhibiting
composing together compatible Reasoned Situations.
conflicting information or displaying ambiguities between

We then altered the experiment settings and changed
relationship between the context state and situation
some of the sensors typical behavior, such that while still
subspaces. In this example a ‘meeting’ situation subspace
having a meeting situation, sensors values are distorted to
and ‘user working in office’ situation subspace are
emulate high inherent inaccuracies and sporadically
defined and inferred by three sensor types:
reflect data that does not correspond either to any known
(1) Light intensity in location, (2) number of people in
situation or the meeting situation. Examples of this are
location and (3) noise level in location. We use the axes
changes to the sensed noise level and light intensity in the
in the diagram to denote the dimensions (i.e. the context
meeting area. Figure 7 presents the reasoning engine’s
attributes) of the subspace, and fill the subspace’s region
results for such experimental run.
of values area in blue. A separate red triangle connecting
Note that, with the emulated errors in sensor values,
a specific single value from each context attribute denotes
the system now fails to infer the meeting as a basic
the context state. The identical context state does not fully
situation. However, the reasoning process identifies the
match any of the situations but exhibits much greater
meeting in its next functional stage when it performs
similarity with the ‘meeting’ subspace, in which the light
adaptation to possible situations for the context-state,
intensity readings only slightly deviate from the subspace
assuming possible inaccuracies in sensor readings.
definition. The state-space difference operation results in
Finally, it composes together all reasoned situations,
a very low difference between the state and the ‘meeting’
resulting in inference identical to that in the initial
subspace, thereby inferring its existence.
scenario. The system has therefore succeeded in handling

inaccurate sensor readings and correctly inferring the
associated situations (as though there were no errors in

sensor readings).

Fig. 8a – A meeting.
Fig. 8b – User in office.
Figure 9 provides the process’s functional flow





For each
Subspace {
Split context-state into
matching sub-state

Compute sub-state and Compute state-space

subspace difference

Check if match

predefined threshold
Fig. 7 – Uncertain information run


Add new situations

with attached
The actual adaptation-oriented reasoning process is the
following. After basic synthesis, the engine splits the

Synchronize results
with Compositor
situations with
current context-state into sub-states that match situation

new situations
subspaces definitions.

It then computes the state-space difference between the
Fig.9 – Functional flow of adapting inaccurate readings
context sub-state and a selected situation subspace, using

the algebra operations library as described in section 3.2. If
5. Conclusion
the revealed difference between the context state and
We have provided a partial view of the Context
situation subspace is below a certain threshold specific for
Spaces model and illustrated how various aspects of the
that situation subspace definition (configurable by the
model can be used for reasoning about context in
application designers) it deduces the existence of such a
different levels of uncertainty. An important feature of the
model, but which is not the main focus of this work, is the
Figure 8a and 8b visually demonstrates the state-
dynamic aspects of context, which are naturally captured
space difference operator activity illustrating the
in the state-space representation approach on which the

model is based. Once we have treated context in terms of
[3] Chen H., Finin T., Anupam J. An Ontology for Context-
state and space, other concepts concerning context, such
Aware Pervasive Computing Environments, Workshop on
as historical context trajectory, and system stability with
Ontologies and Distributed Systems, IJCAI-2003, Acapulco,
regard to specific context as well as various techniques
Mexico, August 2003.
[4] Cheng S. W., Garlan D., Schmerl B., Sousa J. P., Spitznagel
for context prediction and reasoning have been developed
B., Steenkiste P., and Hu N., Software Architecture-based
and included in the Context Spaces model. For detailed
Adaptation for Pervasive Systems, , Conference on Architecture
discussions on these features, the reader is referred to [10,
of Computing Systems (ARCS'02): Trends in Network and
Pervasive Computing, April 8-11, 2002.
[5] Dey A. K., Salber D., Abowd G. D., A conceptual
The different features of the models are presented in the
framework and a toolkit for supporting the rapid prototyping of
reasoning engine, which is built on a modular approach
context-aware applications, Human Computer Interaction, 16(2-
and which makes use of separate libraries that provide
4):97-166, 2001.
operations based on the Context Spaces algebra (as well
[6] Dey A. K., Abowd G. D., Towards a Better Understanding
as algorithms for context reasoning and prediction). The
of Context and Context-Awareness, GVU Technical Report
functional stages discussed in section 2 offer useful
GIT-GVU-99-22, June 1999,
modularity and efficiency in the reasoning process, by
which only uncertain or inconsistent situations are dealt
[7] Huadong W., Mel S., Sevim A. Sensor Fusion for Context
with in advanced stages.
Understanding, IEEE Instrumentation and Measurement,
Technology Conference, Anchorage USA, May 2002.
A fundamental design principle, which we apply to
[8] Huadong W., Mel S., Sevim A. Sensor Fusion for Context
the various reasoning mechanisms and the overall system,
Understanding, IEEE Instrumentation and Measurement,
is the decoupling of the application semantics from the
Technology Conference, Anchorage USA, May 2002.
implementation. We store the semantic part of the model,
[9] Kindberg, T., et al.: People, places, things: Web presence for
which in part is defined by the application designers,
the real world. Technical Report HPL-2000-16, Hewlett-
separately. By following this rule our goal is to achieve a
Packard Labs (2000).
model which is reusable and exportable through the
[10] Padovitz A., Zaslavsky A., Loke S. W., Burg B., Stability
in Context-Aware Pervasive Systems: A State-Space Modelling
semantics. The semantic repository describes elements of
Approach, Workshop on Ubiquitous Computing (IWUC'04), at
the system, policies based on context, elements and
ICEIS 2004, Porto, Portugal.
operations of the Context Spaces model, and a set of
[11] Padovitz A., Loke S. W., Zaslavsky A., Towards a Theory
concepts that describe various behaviors and
of Context Spaces, Workshop on Context Modeling and
characteristics of situation subspaces (e.g. possible
Reasoning (CoMoRea), at PerCom 2004, Orlando, Florida,
natural flows between situations, situation compatibility,
March 2004.
etc.). The use of the Context Spaces model, which is a
[12] Satyanarayanan M., Pervasive Computing: Vision and
general model for capturing and reasoning about context,
Challenges, IEEE PCM August 2001, pp. 10-17.
[13] Schmidt A., Beigl M., Gellersen H. W., There is More to
as the underlying model of the algorithms and the
Context than Location, Proceeding of the International
separation of the application semantics from the
Workshop on Interactive Applications of Mobile Computing,
functional components, enables the development of
Rostock, Germany, November 1998.
reasoning techniques that are generic and can be used in a
[14] Schmidt A., Strohbach M., van Laerhoven K., Friday A.,
variety of settings and application types. Algorithms that
Gellersen H. W., Context Acquisition Based on Load Sensing,
make use of the context spaces model treat any kind of
UbiComp 2002: Ubiquitous Computing, Gteborg, Sweden.
context uniformly and acquire the semantic information,

specific to the application at hand, from a higher level,
external to the algorithms. By following this approach we
seek to create an infrastructure for context-aware
computing at the reasoning level that is able to perform
complex reasoning for different applications once
specialized with application semantics.
In future work we intend to combine the centralized
reasoning engine with distributed and mobile software
components, creating hybrid architecture that work
together in sensing the environment and reasoning about
relevant context.
[1] Campbell R. H., Ranganathan A., A middleware for
Context-Aware Agents in Ubiquitous Computing Environments,
ACM/IFIP/USENIX International Middleware Conference, Rio
de Janeiro, Brazil, June 2003.
[2] Chen H., Finin T., Anupam J., An Intelligent Broker for
Context-Aware Systems, Ubicomp 2003, October 2003.