Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
1
A Context-aware Request Language Framework for Mobile Computing
Alvin T.S. Chan, Peter Y.H. Wong*, Siu-Nam Chuang
Department of Computing,
The Hong Kong Polytechnic University
Hung Hom, SAR of China *Contact email: [email protected]
Abstract – This paper introduces an XML-based generic Context Request Language (CRL), whose construction is
part of a long-term programme to build a web services framework in the domain of mobile context sensing. The
paper describes an implementation of the technique that is in accordance with the formal mathematical
representational model, using first-order temporal language. The language is an attempt to introduce intelligence
into context-aware computing by defining context-sensing elements into logical entities. The use of first-order
calculus and the integration of web service technology in this language definition make it possible for users to utilize
true context aggregation and to embed user control in contextual information. This relaxes the engagement of the
application in context sensing through a complete separation of concerns and provides a set of tools for pre-defining
the composition of contextual information. Moreover, the declaration of contextual knowledge based on situations
and events within the predicate domain allows users to express changes in contextual information and to quantify
these elements among times and durations.
1. Introduction
Context-aware computing is a ubiquitous computing paradigm which can be used to enable applications to discover
and take advantage of contextual information (such as user location, time of day, nearby people and devices, and
user activity). Since having been proposed about a decade ago, many researchers have studied this topic and built
several context-aware applications to demonstrate the usefulness of this new technology. Previous research work
includes the Context Toolkit [3], which provides some comprehensive services such as the encapsulation of sensors,
the abstraction of context data, and the storage of contextual information. In recent years, however, the notion of
context-awareness has been articulated in the domain of mobile computing. This paradigm shift has led to some
extensive research in the hope to provide some dynamic middleware systems on the mobile environment Previous
works have included MobiPADS [1], which is a context-aware middleware and application layer that provides some
level of flexibility in the configuration of resources to optimize the operations of mobile applications; and CoBrA
[10], which leverages on ontology sharing [8,9] and context-aware agents [8] to build a coherent model that achieves
a broker-centric agent architecture for contextual reasoning.
Nevertheless, a review of current context-aware applications [1,3,10] suggests some important areas in
designing context-aware applications still need to be addressed. In particular, often overlooked is the need to
develop an efficient methodology that allows users’ applications to utilize and intelligently reason about contextual
semantics and, at the same time, achieve a complete separation of concerns between applications and contextual
information. We believe this approach is invaluable in making intelligent context-aware applications.
In this paper we describe our attempt to implement a generic rule-based language called Context Request
Language (CRL) that provides a solution for an intelligent technique to context sensing. Our effort focuses on
incorporating temporal predicate calculus, which is used in agent planning [6], with an XML-based syntax for
extensibility [7]. This language allows applications to specify inferences for monitoring and acquiring contextual
information. The use of predicate calculus in this language definition enables users to utilize true context
aggregation and embeds user control in contextual information. CRL forms an integral part of our new Web
Services architecture [14], which supports dynamic reflective reconfiguration, asynchronous communication, and
predefinition of context composition through CRL-rule definitions; and enables easier interoperability. The key
concept of this architecture is that, by a using layered approach, the participation of the application is relaxed and
this achieves a complete separation of concerns while allowing users to express predicate logics into their context
requirements.
1.1 CRL Framework
Figure 1 shows the layered approach that enables the separation of mobile applications and their surrounding
environment.
SOAP over HTTPwith XML
- asynchronous CRL-instancepassing wrapped by SOAP messageenvelope- context sensing rules withembedding logic- real-time reflective CRL re-configuration
Internal environment of context-aware applications
External environment of context-aware applications
Web service requestor (SOAP client, Crbuilder, etc.)
Application Layer(mobile device, remote systems, etc.)- Local functional invocation
Context Layer- context sensors, CRL-inference engine,
CRL-rule repository, CRL Management Module, etc.
Web service provider ( SOAP server, CRParser, etc.)
CRL-rule repository(XML based) Context sensors
ServiceRegistry
(i.e. UDDI)
Publish servicedescription (WSDL)to service registry(UDDI)
Find services
Figure 1: CRL Framework - A layered approach to context-aware computing using CRL and web services
The framework’s key layers and components are briefly described as follows: (the implementations of the
Context Layer, especially the CRL-inference engine and CRL Management Module are discussed in Section 5)
2
3
Application Layer: This describes mobile and remote clients such as PDAs, Pocket PCs, etc. This layer is where
local applications conceptually sit and they can either be dependent or independent of the context environment.
Web service requester: This is a stub that discovers context-aware web services through Universal Description,
Discovery and Integration (UDDI) service registry [12,13]. It also hosts the Context Request Builder (CRBuilder)
for constructing CRL-instances. A CRL-instance is an XML document that can either be a real-time construction of
inference rules for one or more contexts or a specific definition for a particular common environment that is
sometimes referred as smart space [8]. These CRL-instances are then enveloped as Simple Object Access Protocol
(SOAP) [5] messages and transported to the particular web service provider that provides context inference via
HTTP.
Web service provider: This is a mediator between the context requester and the contextual environment. As it
receives an SOAP call from a remote application, it uses the Context Request Parser (CRParser) that validates both
the semantics and the syntax of the CRL-instances against the CRL schema, and transforms it into a set of CRL-
based inference rules before passing it for context sensing.
Context Layer: This layer contains is a set of components that offers context-sensing ability at the hardware level
and context inferences using the CRL-inference engine. There is also a CRL-rule repository that contains common
CRL-rules so that applications are able to refer to pre-defined instances in the repository using key referencing.
CRL-rule Repository: It contains CRL-rules used in smart spaces [8], such as an intelligent meeting room or a smart
vehicle. Since CRL-instances are written based on the CRL XML schema, these rules are intended to be organized
in a tree structure. The process of updating a CRL-instance on the context layer is thus modelled as a specific
algorithm in relation to the addition and deletion of nodes in a tree.
CRL-Management Module: This module is part of the Context Layer and it contains a collection of components
that provides administrative functionalities such as registering context sensors, providing meta-controlling,
processing notification policy.
This layered approach addresses the important issue of application participation. Using SOAP allows
clients’ applications to submit CRL-instances asynchronously, which means that applications are not engaged in
listening to contextual feedback from the Context Layer. This is an important feature which provides the separation
of concerns. The second feature is allowing user to embed predicate logic into each CRL-instance. This enhances the
inference process at the context layer. The notion of reflective reconfiguration, inspired by the unique approach
employed in MobiPADS [1], allows CRL-rules, either parsing through the CRL-inference engine or residing at the
CRL-rule repository, to be updated at real time. A highly transparent framework that does not compromise the
preferred feature of separation of concerns is thus achieved.
1.3 An Overview of CRL
4
CRL plays an important role in CRL Framework, enabling it to reason about context. The complete CRL is a
collection of language grammars expressed in Extensible Markup Language XML for context request definition,
context definition and meta-control definition.
During the construction of the CRL framework we have developed a total of one core inference language (CRL-
instance) and 6 other supplementary languages. They are as follows
CRL-instance: This is the core language component for constructing context request rules. Its grammar is in
accordance with temporal predicate calculus [6]. We have chosen to use temporal predicate calculus as the
underlying logic for the following reasons:
It offers basic proposition logics common to all inference systems
Unlike the logical systems used by other context-aware application, predicate calculus extends the
premature propositional logics in that it provides a mechnanism to express, and reason generically which is
the key advantage of CRL.
Furthemore, temporal predicate calculus extends predicate calulus to provide a mechanism for reasoning
about contextual information and their changes different time intervals.
It offers a set of fundamental control structure to increase the flexibility and the complexibility of CRL-
instance.
It provides a formal mathematical base in context-awareness which is novel in the field of context-aware
mobile computing.
By encapsulating a proven logical system into a standard language such as XML, CRL-instance becomes a truly
generic, platform independent and flexible rule-based language. The aims of CRL-instance are as follows
To provide a language for users/applications to construct context request rules to reason about past and
present contextual information.
To provide a set of control structures for users/applications to condition the enquiry of present and future
contextual information.
To provide a mechanism for users or applications to specify sequential and concurrent sensing of context.
To provide a facility for users or applications to actively interact with the context environment using user-
specific actions.
To provide a well-known syntax for users or applications to construct context inference rules.
The 6 supplementary languages are defined under the CRLsup language group. They are system languages
desigined to enable meta-control, flexible user context feedback and error handling. They are as follows:
CRL-rule: This language is designed to cache common CRL rules in the CRL-rule repository. As discussed in
Section 1, common CRL rules are generally used in smart spaces [8] such as in an intelligent meeting room or a
smart vehicle so that, in many cases, CRL-instances should be able to retrieve these common rules of inference.
5
Since each CRL-instances document is written based on the CRL schema, a CRL-rule document cached in the
repository can easily be appended or inserted into a CRL-instance.
CRL-feedback: This language is used to assist the transitioning of context information back to the Application
Layer. It encapsulates the feedback logic that is specified by the report element in a CRL-instance and the actual
contextual data being collected.
CRL-control: This is a meta-language that controls when and on what conditions CRL rules that have been parsed
should be to disabled and enabled.
CRL-CTree: This language defines the context entities that a CRL-inference engine monitors. Its implementation
conforms to the context hierarchy described in Section 4.2.
CRL-user – This language defines users’ hierarchy. It also includes user-specifc information such as permission
level, etc.
CRL-error – This language is used to assist the CRL framework in error handling during context inference process.
1.4 Integrating CRL into Web Services
The CRL Framework, shown in Figure 1, adopts a layered approach to separating concerns about context from the
application. To implement the CRL definition into this Architecture, every CRL-instance will be captured into a
SOAP message [5]. The construction of a CRL-instance and the enveloping by a SOAP message are carried out at
the Web Service Requester Layer where the CRBuilder resides. Once the message is transmitted to the Web Service
Provider Layer where the CRParser resides, the inference rules encapsulated in the CRL-instance are retrieved and
parsed into formal logical units, and CRL-inference engine will perform inferences on those units.
The rest of this document is organized as follows: in the next section we re-capture the notion of context to
allow this unique way of adding intelligence into context-aware computing. Section 3 gives a brief overview of the
temporal logic that is adopted in context inferences. In Section 4 we present the development and the
implementation of CRL with a case study. In Section 5 we describe the implementation of the CRL Framework, in
particular the Context Layer. Conclusions are presented in Section 6.
6
2. What is Context?
Context is information relating to an environment at a particular period of time within the user’s interests. Dey et al.
have defined context as “any information that can be used to characterize the situation of an entity. An entity is a
person, place, or object that is considered relevant to the interaction between a user and an application, including
the user and applications themselves” [2]. In this definition we focus on the word “situation”. It is often literally
interpreted as “the combination of circumstances at a given time”, yet many seem to have neglected the significance
of this definition. Inspired by Schmidt et al.’s work on the categorization of context [4] and by Dey et al.’s definition
of context [2], we postulate the following:
“All contextual information has at least one of these two properties – Spatiality and Temporality.”
All contextual information has properties either implicitly or explicitly related to spatiality. One category of
context that has an explicit spatial property is physical environment. Contexts such as temperature, brightness, and
vibrations have a definite notion of “where”; whereas, there are those with properties implicitly related to spatiality
such as the orientation of a physical device, the hardware specifications of a mobile device, or the network
configuration onto which devices are connected. Nevertheless, for intelligent context-awareness to exist, all
contextual information should be expressed with the reference to “when”.
Moreover, it is sometime necessary to consider a composition of contexts as a unity. This is because
contexts are often inter-related and can therefore be linked and sub-categorized. In some cases, relationships
between contexts can be pre-defined to relieve the participation of the application. Existing techniques of context
aggregation already provide simple context compositions and fulfil the initial requirement for relaxing the
engagement of an application. However, in many real-life situations, simple composition is often not sufficient.
Ideally, an application should have the ability to specify composite context requests in an intelligent manner. In the
following subsections we refine the notion of temporality and the concept of context aggregation, with embedding
logic and temporal control.
2.1 A Four-dimensional World
Since the world we live in is a four-dimension environment, all intelligent entities therefore must possess spatial and
temporal awareness. In a wireless environment for instance, most mobile context-aware systems have the ability to
capture useful contextual information such as network bandwidth or idle processing power to assist dynamic
adaptations [1]. Nevertheless, one of the key features of mobile systems is the constant changes in the availability of
resources that significantly impact the underlying performance of the system. These changes often take place over a
relatively short period of time. Therefore, it is imperative to capture both spatial and temporal properties within
these contexts. In particular mobile applications often need to be able to detect changes in several context entities
over one or more periods of time. These time durations are often continuous and the monitoring mechanisms might
even leverage on some historical information on context. Case 1 illustrates a hypothetical situation in which a
mobile device is context-aware in the domain of its network resources.
7
However, after reviewing several existing context-aware systems [1,3,10], we found that these systems
only consider contextual information in a three-dimensional environment; i.e., they only support context reasoning
in a spatial manner. Even when time was included as a context entity, it was never fully captured to support the use
of context. We consider this to be a hindrance to the full utilization of context information in the environment to the
advantage of the user. Until now, research work on context reasoning has not focused on temporal intelligence. It is
vital to see the significance of having this property, as such intelligence will allow context-aware systems to
quantify contextual information in the temporal domain; for example, by acquiring context information through the
use of historical information or pre-defining contextual constraints for some predictable events in the future. We
believe that fully exploiting contextual information in a four-dimensional environment will bring much more
advanced intelligence into the context-aware domain.
Suppose an application on a mobile device has established a wireless connection with a server on a wired
network to retrieve and process some service data. Since bandwidth availability is dynamic on a wireless
connection, during the period of this session, the application might need to know the following:
a) If the bandwidth is dropping, or since when it has been dropping, or how much it has dropped since
the session started and,
b) Whether the bandwidth will drop below the minimum bandwidth before the session concludes and,
therefore,
c) Whether it is more efficient to process such data on the server since it has a better overall
configuration and stable resources.
Such a monitoring mechanism will require the context to be quantified temporally on a continuous
timeframe – an interval. The data can then be used to construct a real-time profile of resource usage based
on historic data and eventual constraints (temporal quantification is discussed in section 3).
Case 1: Illustrates a hypothetical situation in which a mobile device is context-aware in the
domain of its network resources
2.2 Embedding Logic, Control Structure, and Context Aggregation,
In Case 1, a mobile application is in the middle of processing service data via a dynamic bandwidth connection. For
a real-time profile to be built, a composition of contextual information is needed. Existing context-aware mobile
systems only provide simple context aggregation, such as the conjunctive aggregation of context condition
enquiries. This limits the use of context. Existing techniques such as Dey et al.’s Context Toolkit [3] only facilitates
a simple on-demand context composition, whether for use in conditional constraints or merely for the delivery of
context. Its aggregation mechanism has a linear relationship to the number of contextual entities required. We
believe that by embedding mathematical logic and temporal quantifications into context aggregation, context
awareness can be augmented to a more intelligent level, thereby maximizing the dynamic adaptation of applications
to the environment.
8
In Case 1, where it is very much preferable to construct a real-time profile for the wireless network, rather
than only allowing applications to determine what contextual information to capture, applications will have the
ability to specify when and how information is captured based a more intelligent nested control structure. Using the
example of the construction of a real-time profile, the application will now be able to induce complex conditions.
Figure 2 lists the pseudo-code of some logical conditionals which can be induced by the application (Note that most
of the context types that we used in this example are defined by MobiPADS [1] specifications.).
Note that apart from allowing complex contextual conditioning, now users are able to “actively participate”
in the inference process. This integration of intelligent contextual sensing and user-directed invocation of procedure
is one of the underlying goals of CRL in encompassing intelligent interaction between the user and the environment.
Case 1 and Figure 2 only demonstrate the need for an on-demand intelligent context-sensing technique. To leverage
on this mechanism, we would more often than not like to keep historical information that captures previous
situations. These situations may occur often, and applications would benefit if context compositions that are
situation-dependent can be re-used or referenced. This is where the functionality of the CRL-instance repository,
which is described as part of the web services framework, becomes apparent (refer back to the web service
framework described in section 1).
Predicate and Function Definition:
not(A) – logical negation of A lessThan(x,y) – y < x
condition(…) success…fail… - branching structure
condtion(…) do(…) – iterative structure
sequence(A,B…) – sequential execution A followed by B…
value_in(S,F) – value of fluent F at situation S
DEF: condition(check(networkRate))
success condition(1) do( condition(lessThan(40,cpuLoading))
success MaxRate(ServiceDataConnection) )
fail condition(not(lessThan(66,storageFreeSpace)),
lessThan(0.5,value_in(s01,check(networkRate)) –
value_in(s10,check(networkRate)) ) )
success newConnection = ServiceDataConnection
DESCRIPTION: observes the processor utilization level for every instance of a routine bandwidth check,
and maximizes service data retrieval bandwidth over other miscellaneous connections when CPU
utilization is below 40%, otherwise if the device storage space is above 65% and bandwidth level has
dropped less than 5 bps over the last 10 minutes, automatically initiates a second connection to allow
concurrent service data retrieval and updates.
Figure 2: Pseudo-code of a situation-dependent control condition based on Case 1 in conformance to
CRL formats
9
Current research works do not provide any formal mathematical base upon which to build context-sensing
applications. There is a missing link between the formalism in theoretical logic and the implementation of an
intelligent context-sensing technique. Rather than seeking a solution to bridge this gap, much of the work on
context-aware computing has only focused on ad-hoc implementation on reusable infrastructure. Although a few
studies have investigated the use of ontological sharing and simple logical inference techniques [8,9,10] to bring
more expressive power to support context modelling and reasoning, they have yet been unable to provide a generic
solution to this hindrance. We believe a formal mathematical base is the key requirement for any complex context-
sensing technique.
3. Temporal Logic
Reasoning about time and change is ubiquitous in common-sense reasoning. Temporal reasoning is central to
advances in pervasive computing and Artificial Intelligence (AI); we believe that the context-aware domain is
inherently an AI problem and that it is a pre-requisite in common-sense reasoning; therefore, it should adhere to
these very basic principles. In this paper, our representation of contextual attributes is based a number of logical
entities used in temporal reasoning. This reasoning mechanism is an extension of predicate calculus and has been
divided into two categories – situations and events. The following subsections (Section 3.1, 3.2, 3.3) describe, and
thus define, some terminologies, temporal axioms, and formulae [6].
3.1 Situation and States
A situation is a snapshot of the universe at an instant. By considering situations to be sound logical entities, we can
include them as arguments in first-order predicates and functions. A well-known technique of representation is used
that reifies time-varying terms as fluents which is defined as a generalization of the “parameters” in temporal
predications and time-varying relations as Boolean fluents or states. Definition 1.1 and 1.2 are the formal
definitions of these basic extensions.
This system allows fluents to be treated as entities. Thus, it is possible to apply functions to fluents and to
quantify fluents. Furthermore, there are other properties within situation-based logic that our language has utilized,
such as asserting a fluent within a continuous timeframe. In order to express more detailed arithmetical information
about times while maintaining the option of using a total ordered system of situations, a measure space of clock
times is introduced. Also, the introduction of tokens allows us to express different occurrences of a state using the
same logical formula. Definition 1.3 shows the formalization of tokens.
3.2 Events and Intervals
In addition to the value of a particular state, a temporal language must have the facility to express the occurrence of
events; whereas a state of the environment can be captured at a snapshot of a measure space of clock times, an event
10
that often occurs during a period of time. By extending the notion of state type and token to incorporate event token
and type, a new predicate “occurs(I,E)” is introduced and is defined in Definition 1.4.
3.3 Control structures
The above definitions alone can only represent a very simple contextual environment. Ideally, it is often convenient
to reason about a complex structure of events built out of simple events. Therefore a natural set of constructs is
defined as analogous to party of the statement-level control structures used in ALGOL-type programming
languages: conditional branch, and iteration. Added to these is a concurrency operator, which is used to express the
occurrence of concurrent events. Definition 1.5 – 1.7 defines the logic of expressing compound events using a
control structure.
1) DEFINE: true_in(S,A)
DESCRIPTION: a predicate that asserts that state A holds in situation S.
2) DEFINE: value_in(S,F)
DESCRIPTION: a function that maps a situation S and a fluent F to the value of F in S.
3) DEFINE: true_in(S,A) ⇒ ∃ K token_of(K,A) ∧ S ∈ time_of(K)
DESCRIPTION: asserts that state type A holds in situation S if there exists a state token K of type A and if S is
within the interval of K (token K can be viewed as part of a series of situations).
4) DEFINE: occurs(I,E) ⇒ ∃ K token_of(K,E) ∧ I = time_of(K)
DESCRIPTION: asserts that event type E occurs at interval I if there exists an event token K of type E and if I is
the interval of K. (An interval is a finite sequence of situation.)
5) DEFINE: cond(A,E1,E2) = { I | I∈ E1 ∧ start(I)∈ A} ∪ { I | I∈ E2 ∧ start(I)∉ A}
DESCRIPTION: defines a conditional branch (similar to the if…then…else construct for procedural language
6) DEFINE: while(A,E) = cond(A,seq(E,while(A,E)),null)
DESCRIPTION: recursively defines iterations
7) DEFINE: occurs(I,con(E1…Ek)) ⇔ ∃ I1…Ik occurs(I1,E1) ∧ … ∧ occurs(Ik,Ek) ∧
start(I) = start(I1)=…=start(Ik) ∧ end(I)=max(end(I1)…end(Ik))
DESCRIPTION: defines the occurrence of concurrent events by formally stating: Events E1…Ek occur during I
if each event Ei starts at the beginning of I, and I continues until the last is finished.
Definition 1 Axiomatic definition of control structures (continued)
11
4. CRL – Context Request Language
As with all general mathematical models, it is not possible to completely map this representation of temporal
reasoning into a context-sensing domain. Here are the existing incompatibilities with the corresponding alteration:
A1. While in the predicate calculus, the Boolean connectives of CRL consist of negation, conjunction, disjunction,
implication, and equivalence. It is cumbersome to specify most of these connectives in their present format.
While some of these connectives can be made redundant within the context-sensing domain, it is still important
to construct a language that is in accordance with the standard notation of mathematical logic. Therefore, when
designing the language we have decided to utilize only conjunction and negation connectives, while in
propositional logic it is possible to express the remaining connectives using conjunction and negation.
A2. In CRL we have assumed that every occurrence of a variable in a context request rule is bound, as only closed
formulae are relevant in the context domain. In this way, we could eliminate quantifiers and the need to build
modal temporal reasoning mechanism into the language.
A3. Since it is possible to express the occurrence of several concurrent events with a generic concurrent operator,
we have decided to extend the temporal predicate true_in(S,A) to represent the conjunction of several states
over the same interval. Definition 2.1 defines our extension on true_in(S,A).
A4. Unlike the current temporal reasoning logic, CRL is a rule-based language specifying inference rules based on
Horns notation. Therefore, in addition to temporal predicates and functions (i.e., true_in(S,A) and
value_in(S,F)), which are primarily used for representational purposes, a new temporal entity – gVal(S,F) is
defined to specify the type of context information F to be parsed at situation S from the environment to the user.
Similar to A3, we extend gVal(S,F) to obtain a set of values from fluent F1…Fk. This is defined in Definition
2.2.
A5. Upon completing an inference set, similar to A4, we define a new temporal entity gState(S,A) that is used to
collect information about state A at situation S. This is shown in Definition 2.3, Corresponding to Definition 6
on true_in(S,A1…Ak), this definition is extended to incorporate the expression to obtain a set of state
information A1…Ak at situation S. Furthermore, we can now define gState(I,E) to capture information about a
set of concurrent events E1…Ek at some interval I using the definition of a set of concurrent events at
Definition 1.7 . This is shown in Definition 2.4.
A6. Similar to A4 and A5, to fully utilize the benefits of control structures, a corresponding temporal entity –
execute(Sf,Act1…Actk) is defined to specify the execution of one or more actions Act1…Actk initiated by the
user in the environment situation Sf, shown in Definition 2.5.
A7. To extend the above definitions to a general operator (state, fluent, event or non-temporal entities), we have
made a definition taking α(β1…βk) to be the generic form of an operator α with arguments β1…βk. This is
shown in Definition 2.6.
12
1) DEFINE: ∀S,A1,…Ak∃ S1…Sk true_in(S,A1…Ak) ⇔ true_in(S1,A1) ∧ … ∧ true_in(Sk,Ak) ∧ S = S1 =…=Sk
DESCRIPTION: asserts that state type A1… Ak holds in situation S
.
2) DEFINE: ∀S,F1,…Fk∃S1…Sk gVal(S,F1…Fk) = <gVal(S1,F1),…, gVal(Sk,Fk)> where S = S1 =…=Sk
DESCRIPTION: collect values of fluents F1…Fk at situation S (S denotes the situation of the fluents that we
would like to know about.)
3) DEFINE: ∀S,A1,…Ak∃S1…Sk gState(S,A1…Ak) = <gState(S1,A1),…,gState(Sk,Ak)> where S = S1 =…=Sk
DESCRIPTION: collect information on state type A1…Ak at situation S (S denotes the situation of the states
we would like to know about.)
4) DEFINE: ∀ I,E1,…Ek gState(I,E1…Ek) = < gState(I,E1),…, gState(I,Ek) > ⇔ occurs(I,con(E1…Ek))
DESCRIPTION: collect information on a set of concurrent events E1…Ek at some interval I.
5) DEFINE: execute(Sf,Act1…Actk)
DESCRIPTION: an invocation of action Act1..Actk at a future situation Sf.
6) DEFINE: α(β1,…,βk)
DESCRIPTION: a general operator α taking arguments β1…βk, where β1…βk are variables, constants, or
operators.
Definition 2: Formal definitions of logical extensions and constraints A1 to A7
The logical extensions and constraints A1 to A7 with Definitions 1 and 2 described in this paper formulate
the fundamentals of CRL, which is defined by a formal data structure and XML syntactic definitions. Furthermore,
we have defined some basic binary operators and extended it to N-ary, where anything greater than one. These
operators define arithmetic and inequality operations. In Definitions 3.1 and 3.2 are formal definitions of the
extensions of this language. With Definitions 3.1 and 3.2, we have derived Definitions 3.3 and 3.4 to grammatically
bind these operations with the overall grammar of temporal reasoning. Consequently, a more flexible and expressive
temporal language has been formulated.
1) DEFINE: θ(β1,β2,…,βn) = θ(β1, θ(β2,…, βn))
DESCRIPTION: given θ as arithmetic operators (add, subtract, multiply, divide), the specified operation will
be carried out recursively on some temporal fluent β1,…,βn; and yields a numeric value.
2) DEFINE: ρ(γ1, γ2,…,γn) = ρ(γ1, ρ(γ2,…, γn))
DESCRIPTION: given ρ as boolean operators (=, <>, >, <, >=, <=), the specified operation will be carried out
recursively on temporal states or fluents γ1,…,γn; and yields a boolean value.
3) DEFINE: ∀ S,A1,…Aq,ρ1…ρm true_in(S, ρ1(A1,…,Ai),…,ρm(Aj,…, Aq))
DESCRIPTION: asserts that for some boolean operations ρ1…ρm, states A1,…,Aq are true under their
respective boolean operations at situation S (multiple assertions under the same situation have been defined in
Definition 6)
4) DEFINE: ∀ S,F1,…Fq,θ1…θx gVal(S, θ1(F1,…,Fi),…, θx(Fj,…, Fq))
DESCRIPTION: collect values for some arithmetical operations θ1…θx; fluents F1,…,Fq are true under their
respective arithmetical operations at situation S (collecting multiple values under the same situation has been
defined in Definition 2.2)
Definition 3: Formal definitions of N-ary arthmetic and inequality operations
4.1 Defining CRL Context Tree (CRL-CTree)
In Section 2 we postulated that context information has temporal and spatial properties. Inspired by Dey et al.’s
discussion on context description [3] and Chen et al.’s COBRA-ONT ontology used in CoBrA architecture [9], we
developed a CRL Context Tree (CRL-CTree) to methodically organize information on context while allowing for
constant evolution as new contexts are discovered and added. This is an ordered tree of height 3. Figure 3 shows a
partial CRL-CTree representing possible information on context within a closed environment; e.g., a working area in
a building.
Figure 3: A top-down tree structure for information on context
13
As the structure denotes, there are three levels and each level represents a collection of contexts. Below are
some properties of the nodes on this tree structure:
1. The top level is called location ID. Each node in this level may represent a physical location such as a
room, or a virtual environment such as a workstation ID.
2. Each child node spawned from a location ID is an entity ID, which may either be an artefact, such as
a printer or a temperature sensor that is physically situated in the region of a physical location specified by the
location ID; or property, such as a power supply or physical memory related to a virtual environment
specified by the location ID (in this case a typical workstation).
3. Each child node spawned from an entity ID is a status ID, which is a property of the entity it spawns
from. For example, if the entity is the physical memory of a workstation, then some of the corresponding
properties are memory type, size, and unused space. The corresponding properties of a physical artefact such as
an air-conditioning system are power status and fan level.
The type of contextual information in the above context structure is known as general context. There is another
group of contextual information that is referred to as special context. These are context information such as specific
user’s preferred printer or default network group. Figure 4 is a CRL-CTree for special contexts specifying
information about a typical user.
Figure 4: A context tree denoting user information
From the definition of CRL-CTree, we have defined the Context Capture Set, which is composed of four direct
functions and one sub-function, as shown in Definition 4. These four direct functions are coupled with our temporal
language, defined in Section 4.1, to complete our temporal reasoning language set1.
141 The complete Grammar of CRL rule in EBNF [16] is shown in Appendix A
15
DEFINE: status(locationID,entityID,statusID)
DESCRIPTION: This is a linear function that returns a boolean state value or a fluent value specified by
the parameter. Its usage with the rest of the temporal reasoning set is in accordance with Definitions 1-15.
Items such as inferences about the number of occupants in room pq607 can be expressed with
status(pq607,occ001,amount). Each invocation of this function represents a walk through a path in the
specified CRL-CTree.
DEFINE: set(locationID,entityID,statusID,newValue)
DESCRIPTION: This is a linear function that sets a value for some specified context, such as turning on a
light switch light001 in a room pq607 and a boolean value is returned to indicate the success of this
operation. Each invocation of this function represents a walk through a path in the specified CRL-CTree.
DEFINE: assign(entityID,entityPropertyID,locationID,propertyID)
DESCRIPTION: Both set and status are functions to manipulate general context, whereas assign is a
function to modify information about special context. This function assigns a user-default pointer (special
context) to a general context. Each invocation of this function represents an instance of a path in the
specified special context CRL-CTree.
DEFINE: action(actionID,actionType,command)
DESCRIPTIONl: This is a linear function, which allows a user to execute a simple command such as
sending a print job or sending a signal to an user’s workstation/PDA.
Definition 4: Definition of Context Capture Set for acquiring information on context
4.3 The Use of the CRL – A Case Study
The development of CRL focuses on ensuring a separation of concerns and allowing generic inference rules
constructions that are suitable for building pragmatic context-aware applications. The following case study provides
an overview of a CRL-instance’s construction and how might CRL framework be used:
The Mobile Computing Group (MobiComp) in The Hong Kong Polytechnics University’s Department of
Computing organises a group meeting every Wednesday between 15:00 to 16:00 in room QT419. Assuming
everyone in the group acknowledges this meeting, Since the group chair would like to start the meeting when
everyone is present but at the same time not having to wait for other members to arrive at the meeting, he decides to
have a notification to be sent to his PDA during the period 14:55 to 15:15 if all the other group members present in
QT419. Below is the specification for constructing this rule
Temporal Condition: every Wednesday 14:55 to 15:15
Spatial Condition: room QT419
Rules (pseudo): if (all MobiComp members present) then send notification to group chair’s PDA
Before contructing the CRL-instance and using the CRL Framework, We need to specify the surrounding
environment by constructing a CRL-CTree document for QT419 and CRL-user documents for the group members
and the group chair. Figure 5 shows a CRL-CTree definition in tree format for room QT419.
Figure 5: CRL-CTree definition - qt419.xml
Figure 6 shows the partial definition of a typical MobiComp member and the MobiComp Chair in tree
formats. Each user is defined using CRL-user language in XML. Each definition contains user’s account information
such as domain, username, title, default host, etc.
Figure 6: CRL-user definition – mobiComp.xml
4.3.1 Constructing a CRL-instance document
After defining the contextual environment and its occupants, we now define the logics of the CRL-instance
document – mobiCompAlert.xml. Each CRL-instance document has a unique instance id as part of the
identification key; each CRL-instance contains three or more sub-elements: user, report and one or more rule
elements. The user element defines the context requester, i.e. the user who submits the corresponding CRL-
16
17
instance document. In the current version of the CRL, the user element contains the user’s ID and host IP (Internet
Protocol), each CRL-instance document is validated for uniqueness using the user’s ID and the instance id. Listing 1
show the definition of the user element and the document id in mobiCompAlert.xml, in this case study, the
document is composed and sent by the MobiComp Chair who has the username cstschan at the network location
324.40.2.1.
. . .
<context id="meetingAlert">
<user host="324.40.2.1" id="cstschan"/>
. . .
Listing 1: definition of user element and document id in mobiCompAlert.xml
<report>
<feedback proxyAssign="true" ruleId="1">
<aTemporalTypeAction aTemporalOperator="execute">
<operator concernType="state" id="1" operatorName="action" return="boolean">
<specifiedArgument>
<actionProperty actionID="meetingAction001" actionType="alert"
command="alert(cstschan,423.40.2.1)"/>
</specifiedArgument>
</operator>
</aTemporalTypeAction>
</feedback>
</report>
Listing 2: definition of report element in mobiCompAlert.xml
The logic of receiving feedback information from the inference engine is described by the report
element. It has the syntax to describe feedbacks that ranges from a simple acknowledgement to a direct execution of
a linear command. In this case study, the MobiComp Chair would like to be alerted when the corresponding
condition is met, Listing 2 shows the definition of report element in mobiCompAlert.xml. This report definition’s
ruleId attribute value specifies the rule of which a successful inference process will generate this feedback. The
proxyAssign attribute specifies whether this report definition should be adjourned for proxy notification (See
Section 5). The content of this report definition is an invocation of an action which has an id
meetingAction001. The actual command, specified by the command attribute, is
alert(cstschan,423.40.2.1). Whereas the action operation is part of the Context Capture Set, the
actual command is environment-dependent which makes the CRL generic and platform independent.
18
<rule backUp="false" id="1">
<others proxyAssign="true" monitor="event">
<argument id="1">
<temporalType>
<temporalTypeExpression realTime="true" temporalOperator="true_in"
return="boolean">
<operator concernType="state" id="1" operatorName="equal"
return="boolean">
<variableArgument property="csyhwong" type="string"/>
<operator concernType="state" id="1" operatorName="status"
return="string">
<specifiedArgument>
<statusProperty entityID="occ001" locationID="qt419"
statusID="occName"/>
</specifiedArgument>
</operator>
</operator>
<operator concernType="state" id="2" operatorName="equal"
return="boolean">
<variableArgument property="cssiunam" type="string"/>
...
</operator>
<operator concernType="state" id="3" operatorName="equal"
return="boolean">
<variableArgument property="csyzheng" type="string"/>
...
</operator>
</temporalTypeExpression>
</temporalType>
</argument>
</others>
</rule>
Listing 3: partial definition of the rule element in mobiCompAlert.xml
The rule element specifies the inference logic of this context request procedure. In this case study is
checks for the presence of all members of MobiComp in room QT419. Listing 3 shows the partial definition of the
rule element in mobiCompAlert.xml. This rule element has a unique id of 1 and its reference in the CRL
Framework is the combination of the document id and this rule id, i.e. meetingAlert-1. The logic of this rule
asserts that the status(qt419,occ001,occName) contains the user csyhwong, csyzheng and cssiunam. The
status operation, part of the Context Capture Set, returns a boolean or a fluent value of the context path specified
by the operation’s arguments (see Figure 5 which shows the CRL-CTree for this case study). Each rule in a CRL-
instance contains either a linear rule like the one used in this case study or a controlled flow of rules such as a branch
statement. In this case study we have demonstrated the use of multiple assertions (Definition 2.1) specified in
beginning of this section. As shown in Listing 3, we use the temporal operation true_in which asserts for 3
equal operations. Each equal operation compares the return of a status operation against a username. This
particular rule, like any other CRL rule definition, can be modelled using a tree data structure (see Figure 7).
Figure 7: partial definition of meetingAlert-1 in tree format
4.3.2 Building the Meta-Control
In this example we have chosen to use meta-control mechanism to control this CRL-instance, Listing 4 shows the
definition of a CRL-control definition for this case study - alertControl.xml
<control id="meetingAlert001">
<user host="324.40.2.1" id="cstschan"/>
<controlLogic control="enable" ruleId="meetingAlert-1">
<repTimeCondition endTime="15:15:000" frequency="wed" startTime="14:55:000"/>
</controlLogic>
</control>
Listing 4: partial defintion of alertControl.xml
This control document specifies the temporal restriction specified by the MobiComp chair which is to run the
inference procedure from 14:55 to 15:15 every Wednesday; this specification is described by the repTimeCondition
element in alertControl.xml. This document’s syntax is in accordance to CRL-control definition which has been
described in Section 1.
5. Context Layer
While constructing CRL, an implementation of the Context Layer was developed. We have chosen Java 2 Standard
Edition (J2SE) [15] to be the implementation language, as it is a platform-independent object-oriented language that
supports web service architecture and XML processing. In this implementation, Java API for XML Processing 1.2
19
specification is required to validate any CRL document against the CRL Schema. For developmental purposes, our
current implementation of the Context Layer contains the CRL-Inference Engine, CRL Management Module and it
also contains a fully functional CRParser which, although not part of the Context Layer, is a vital part of the
framework to carry out logical inferences. Moreover, the Context Layer also contains a collection of Java objects
that represent contextual sensors and a graphical user interface for purposes of emulation. Figure 8 depicts a
screenshot of the graphical user interface (CRL Control Panel) showing the internal process of the CRL Framework
under the scenario discussed in Section 4.
Figure 8: a screenshot of CRL Control Panel while CRL Framework is running under the scenario discussed in Section 4
5.1 The Language and the Context Layer
Before describing the design and the implementation of the Context Layer it is important to understand the
functionalities that we have defined into the layer. The current implementation of the Context Layer allows
individual rules to be “proxy-assigned”. Proxy-assigned CRL-rules means that while the rules reside in the
inference engine, each of them will have constructed a notification policy. These policies are a collection of tuples
each containing the condition, the name of the rule that has set up the policy and the engine thread that contains the
rules. Part of the implementation of the CRL Management Module is the CRL Proxy; once policies are constructed
they are sent to the CRL (sensor) proxy which monitors them for any changes in context. There are two types of
proxy-assignments – temporal notification and event notification.
20
21
5.2 Implementating the Context Layer
Two separate Java packages have been implemented to emulate our web services framework:
contextLayer.contextSource, contextLayer.crlParser. The packages have been organized so
that they match the Context Layer conceptual model. Below are a description of the two packages, their conceptual
representations, and the proposed structure for each representation. Package contextLayer.crlParser
This is the core of the Context Layer; it contains a CRL validation system, a logical parser, and an inference engine.
During implementation, we have constructed 4 main classes and 10 nested classes2. Below are the descriptions of
each entity in the model and their corresponding implementations.
Conceptual Entity CRL Validation System
Description If documents are sent as a SOAP message, they will be stripped and left with
CRL-instances. On parsing through the validation system, Each CRL-instance
will be validated against a CRL-schema and its content will be pushed onto an
abstract data structure (elementObject).
Implementation Classes crlValidator, elementObject, elementObject.argument
Conceptual Entity Logical Parsing
Description After CRL-rules are parsed through the CRL Validation System, they are only
syntactically correct against the CRL schema. These rules will then be
logically parsed through the CRParser to check their semantics.
Implementation Classes LogicalParser
Conceptual Entity Retrieval/Storage facility
Description While pushing a CRL-instance into an ADT, specified CRL rules will be
backed up by constructing the corresponding CRL-rule document and stored in
a CRL-rule repository. At the same time, specified CRL-rule documents can be
retrieved from the repository, transformed into CRL rules, and inserted into the
CRL-instance.
Implementation Classes crlValidator, elementObject, elementObject.argument
2 The UML Class diagram of contextLayer.crlParser is shown in the Appendix B
22
Conceptual Entity Proxy Engine
Description An interface between the CRL-inference engine and the CRL proxy that
monitors changes in contexts. After the CRL-inference engine has identified
the CRL rules for a proxy assignment, they will be passed to the Proxy Engine
and the Proxy Engine will send a “notification policy” specified by the
schedule of the CRL-rules.
Implementation Classes InferenceEngine.proxyInference
Conceptual Entity Inference
Description At the inference engine (CRL-inference engine), each rule will be processed
and inferred accordingly. Exceptions will be generated when a known error is
detected. The CRL-inference engine co-operates with the CRL-sensor proxy to
allow dynamic inference processes. Upon the success of an inference process,
corresponding CRL reports will be updated and stored until a request is made
for the creation of a CRL-feedback document.
Implementation Classes InferenceEngine and all its nested classeses
Package contextLayer.contextSource
Majority of this package is an implementation of the CRL Management Module such as
contextLayer.contextSource.sensorProxy class but part of it has been implemented for
developmental purposes, such as contextLayer.contextSource.contextObject class, which was
created to simulate contextual information. Other classes were implemented to help the CRL-inference engine carry
out the process of inference by organizing the context and through functions such as event listening or temporal
listening. Figure 8 shows the conceptual model of the contextLayer.contextSource package. As it shows
the CRL Management Module consists of the CRL Proxy, CRL Temporal Monitor, CRL-CTree, CRL User and
CRL Control. We have constructed 7 main classes and three nested classes3. Below are the descriptions of each
entity in the model and their corresponding implementation, as well as a description of the model. Note that CRL
Control Panel is not strictly part of the CRL Framework.
Conceptual Entity CRL (Sensor) Proxy
Description This entity sets up an interface between logical CRL rules and the contextual
information in the physical world. It cooperates with the CRL- inference
engine by coordinating contextual events, i.e. a change in some context in the
environment; and temporal events, i.e. an alert trigger by the CRL Temporal
Monitor. Each CRL rule within a CRL-instance can specify whether or not to
assign itself to a proxy notification.
Implementation Classes sensorProxy, contextRequestException
3 The UML Class diagram of contextLayer.contextSource is shown in the Appendix C
23
Conceptual Entity CRL Temporal Monitor
Description This is a class implemented to monitor the system’s clock. When the CRL
Proxy receives a temporal notification policy, the CRL Proxy will notify
CRL Temporal Monitor with this policy, thereby easing the CRL Proxy from
the need to constantly monitor (since event listening is carried out by a location
cluster sending a notification to the CRL Proxy.)
Implementation Classes temporalMonitor
Conceptual Entity Location Cluster
Description This provides for the aggregation of contexts within some physical/virtual
environment, such as a room in a building or a local area network within a
university campus. It provides functionalities to add/register and
remove/deregister context definitions and a channel for context information to
be passed to a CRL Proxy.
Implementation Classes sensorLocation
Conceptual Entity Context Sensors
Description As mentioned in the beginning of this section, for purposes of emulation, the
current implementation of the Context Layer abstracts context information as
Java objects. Each collection of context sensors is bounded and encapsulated
by Location Clusters. Together with Location Clusters the conceptual model
forms the context hierarchy stipulated in Section 4 (CRL CTree)
Implementation Classes contextObject
Conceptual Entity CRL Control
Description This is a component that is managed and monitor meta-controlling specified
for inference process in the CRL Framework
Implementation Classes CRLControlMonitor,
CRLControlMonitor.CRLControl
Conceptual Entity CRL CTree
Description Conceptually this is a component used to keep track of all context definition
but since context information is automatically loaded when starting the CRL
Framework for building the environment. There is no direct class
implementation.
Implementation Classes contextControl, sensorProxy, contextObject,
sensorLocation
Conceptual Entity CRL User
Description Conceptually this is embedded in the CRL Management Module to monitor
users currently using the CRL Framework. Similar to CRL CTree, there is no
direct class implementation
Implementation Classes contextControl, CRLControlMonitor,
Conceptual Entity CRL Control Panel
Description A Graphical User Interface used for purposes of assisting development and for
emulation. It allows for the direct manipulation of context.
Implementation Classes contextControl, contextControl.crlFilter,
contextControl.logFilter,
contextControl.contextClock
Figure 9: Conceptual model of the contextLayer.contextSource
5.3 Analysing the ContextLayer
Part of the development of CRL and the CRL Framework is to ensure CRL-instance can be parsed into the CRL-
inference engine efficiently. We have devised a set of experiments that allows the timing of parsing to be measured.
5.3.1 An Overview of CRL Parsing
Based on Grune et al’s work on compiler design and source parsing [17], our experiments focus on several stages of
parsing and provides cross examinations on CRL-instances in different dimensions.
Formally CRL parsing includes validating the original CRL-instance (source code), converting it into
CRLObject, sometimes this object is referred as the intermediary code or abstract syntax tree (AST). Since XML
24
documents are often conceptualized as object models [7], we have uses Java object to represent AST. The class of
syntactic analysis we have adopted in the CRL Framework is top-down parsing which constructs the AST in pre-
order. CRLObject is also designed for transportation between CRL Validation System (syntactic analysis – front
end) to CRLParser where the AST is examined for semantics correctness. At this point CRLParser carries out
semantic analysis by constructing a valid replicate of the AST in temporal predicate grammar which is described in
previous Sections. This process also transports the semantically-valid AST into the CRL-inference engine, at which
point the AST undergoes another type of parsing and translation (target code synthesis – back end). Target code
synthesis is a step that takes the AST into target code. In normal compilation of this is a process of deriving an
executable program from AST, however in the context of CRL, this phase is to derive a predicate object
(InferenceEngine.predicate).
5.3.2 Performance Examination We have defined performance examination based on the stages of parsing, shown in Figure 10. To cross examine
these stages we generate valid CRL-instances that have different dimension in their breadth and depth.
Breadth Analysis (rule definition) – Since one of the factors that affect the complexity of a CRL-instance
is the number of rule definition, breadth analysis measures the efficiency of parsing in terms the number of rule
definitions. Figure 11 shows a template of constructing CRL-instance samples for examination. The samples’ logic
representation comes from the rule definition used in the case study in Section 4. Each rule definition asserts that a
MobiComp member exists in room QT419.
Figure 10: Stages of CRL Parsing
25
<!-- Begin Rule Definition --> <rule backUp="false" id="1"> <others proxyAssign="true" monitor="event"> <argument id="1"> <temporalType> <temporalTypeExpression realTime="true" temporalOperator="true_in" return="boolean"> <operator concernType="state" id="1" operatorName="equal" return="boolean"> <variableArgument property="csyhwong" type="string"/> <operator concernType="state" id="1" operatorName="status" return="string"> <specifiedArgument> <statusProperty entityID="occ001" locationID="qt419" statusID="occName"/> </specifiedArgument> </operator> </operator> </temporalTypeExpression> </temporalType> </argument> </other> </rule> <!-- End Rule Definition -->
Figure 11: Template for rule examination
For each CRL-instance measured, we inserts n replicates of the same rule definition into the CRL-instance
where n is an integer value ranges from 100 to 1000 and passes the document through the stages of parsing. During
CRL parsing, the period that the Framework takes to bring the document from source to target is benchmarked.
Results are then tabulated, shown in Graph 1. The graph shows that semantic parsing consumes the majority of
parsing time as the breadth increases. It also depicts that semantic parsing in the CRL-framework parsing efficiency
in terms breadth.
0
500
1000
1500
2000
2500
3000
3500
4000
100 200 300 400 500 600 700 800 900 1000
number of rule definitions
pars
ing
time
(ms)
Syntax Parsing Semantic Parsing Target Synthesis Total Parsing
Graph 1: Breadth Analysis on rule definitions from 100 to 1000 rules
26
Depth Analysis (nested branching) – One of the advantages of using XML as the implementation language
for CRL is that it allows recursive definition and nested branching such as a terminating recursion. In this depth
analysis the same rule template for breadth analysis is used. Since the rule definition in the rule template defines a
simple assertion, it can also be a branch condition. Its syntax is in accordance to the EBNF defined in Section 4.
For each CRL-instance measured, we define a single rule into the document and recursively add n
branching conditions into this single rule, where n is an integer value ranging from 50 to 200. Measured results are
graphically presented in Graph 2.
0
1000
2000
3000
4000
5000
6000
50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200
Number of nested branch (depth)
pars
ing
time
(ms)
Syntactic Analysis Semantic Analysis Total time for Parsing
Graph 2: Depth Analysis in nested branching from 50 to 200 branches
5.3.3 General Observation
Both analyses show some similarity in that syntactic analysis i.e. from source code into AST (CRL Object) bears no
obvious relationship with the corresponding depth or breadth. Syntactic analysis takes place at the CRL Validation
System in which we have used Simple API for XML (SAX) [18], a generic XML parser for Java popular for its
efficiency, to implement the crlValidator class. SAX is an event-driven API and since it only feeds XML
content to the validating application through a callback interface, this makes SAX very fast. Therefore as both the
depth and the breadth of a CRL-instance increase, semantic parsing became the main factor that determines the total
parsing time. Note we have deliberately ignored target synthesis during depth analysis. This is because during
synthesizing, each rule is parsed into a predicate object (InferenceEngine.predicate) and the complete
dissemination of the CRL Object will not take place until inference processes commence. These inference processes
are carried out dynamically which meant it we cannot monitor for its efficiency in the same manner as the
corresponding syntactic and semantic parsing.
27
5.4 Supporting Existing Application with CRL Framework
Part of the analysis of the CRL Framework, we have utilized the CRL Framework by integrating it with some
existing applications to testify the compatibility of the CRL Framework with such applications and their hardware
configuration. In particular we have carried out this experiment with the departmental at integrating the CRL
Framework with RedPoint4, a middleware architecture based on our department’s Local Positioning System –
BluePoint [19] which is a Bluetooth-based architecture that provides location-positioning services and it allows
mobile user locations to be managed effectively and transparently. In the same way RedPoint adopts the diffused
infra-red technology to provide location tracking through tagged active badges that periodically send updated
location information via strategically installed base stations that are distributed across the premises. Figure 12a
shows a prototype of the tagged active badge that has been used for a prototype scenario based on a hospital
environment to track patients, medical personnel, and mobile equipment like wheelchairs. It is applicable as a SARS
tracking system, making the badge into a necklace or brace for patient
5.4.1 CRL Framework Connectivity
In this experiment, the CRL Framework realizes the semantics of contextual information by aggregating real-time
context (location) from RedPoint architecture through web services [12, 13, 14]; Figure 12b shows the conceptual
model of the CRL Framework interfacing the RedPoint architecture. The Context Layer communicates with
RedPoint via a two-layered interface. Each context, regardless of its semantics, is abstracted as a programming
object (contextObject). Each abstraction contains a unique string id that represents that particular context. Each id,
in the form of (locationID,entityID,statusID) or a tuple depicting an unique path of a CRL-CTree, matches a
corresponding sensor in the environment (in this case, the radius of RedPoint environment). These abstractions
acquire context information by submitting their ids to the Web Service Requestor which transports the ids as SOAP
messages [5] to the Web Service Provider via TCP/IP over HTTP.
Figure 12: (a) tagged active badge and (b) conceptual model of the CRL Framework interfacing the RedPoint Architecture
284 Research work on RedPoint technology is subject to future publications
29
5.4.2 RedPoint and Web Service
As shown in Figure 12b the RedPoint architecture contains clusters of base station. To use RedPoint, each relevant
personnel wear an electronic tagged active badge that transmits signal detectable by location sensors at close
proximity which updates the Location Database at the RedPoint middleware level. In this way the Web Service
Provider shown in Figure 12b updated contextual information corresponding to each base station through the
Location Database. Upon receiving a SOAP message from the Web Service Requester, SOAP messages are stripped
and the contextual information corresponding to the id in the message is sent back to the Web Service requester as a
new SOAP message which is stripped and passed through the CRL framework’s layers for inference processes. To
leverage on existing middleware components within RedPoint, Logical functions such as alerting a user’s PDA
defined in Section 4 may utilize the Peer-to-Peer Network in RedPoint architecture
6. Conclusion
By introducing temporal predicate calculus into context sensing, an XML-based Context Request Language (CRL)
has been defined to support the passing of a user’s request to a Web Service framework for context retrieval. Each
application will have a web service interface that contains the CRBuilder and acts as a web service requester. The
CRBuilder creates each CRL-instance automatically during a context request from a context-aware application.
CRL-instances are encapsulated into SOAP messages, which are asynchronously passed onto the Web service
provider that contains the CRParser. The CRParser parses CRL-instances as a set of inference rules into the CRL-
inference engine for interpretation. During the interpretation at the context layer, a dynamic inference technique is
adopted to collect context information around the environment. If the application operates in a common environment
(smart space), a specific CRL-instance can be retrieved from the CRL-rule repository. During the inference process,
applications can directly alter the CRL-instance using a method known as reflective reconfiguration to update the
context requirements and on-demand contextual changes. Upon the successful processing of a context inference,
feedback on contextual information or a signal used to signify the end of the context inference that is encapsulated in
CRL-feedback document is bounced back to the application encapsulated into a SOAP response message.
This document described a unique approach to context sensing in a mobile environment. We have bridged
the gap to link the formalism in theoretical logic to the implementation of intelligent context-aware applications. A
CRL definition forms an introduction bringing intelligent inferences into context sensing. We employed a well-
known temporal language which is an extension of predicate calculus and applied this formal logic to a context-
aware environment. In making CRL a fully functioning and usable logical rule-based language, we have defined a
collection of supplementary languages – CRLsup to assist the controlling of context inferences and rule manipulation.
We have also adopted a layered-approach to formulate a Web service framework and leverage on its standard
messaging protocol to achieve a complete separation of application concerns toward context environments. During
the stage of designing the framework we implemented the Context Layer, which includes a CRL-inference engine to
test and demonstrate the usability of CRL. Throughout the development of the framework we have investigated the
efficiency of CRL parsing and the compatibility to existing application.
30
References
[1] Alvin T.S. Chan, Siu Nam Chuang, “MobiPADS: A Reflective Middleware for Context-Aware Mobile
Computing”, IEEE Transactions on Software Engineering, vol. 29, no. 12, Dec 2003, pp. 1072-1085.
[2] A.K. Dey, “Understanding and Using Context”, Personal and Ubiquitous Computing Journal, Volume 5 (1),
2001, pp. 4-7.
[3] A.K. Dey, “Providing Architectural Support for Building Context-Aware Applications”, PhD thesis, College
of Computing, Georgia Institute of Technology, December 2000.
[4] A. Schmidt, M. Beigl, H.W. Gellersen, “There is more to Context than Location”, Computer & Graphics
23(6), December 1999, pp. 893-901
[5] M. Gudgin, M. Hadley, N. Mendelsohn, J.J. Moreau, H.F. Nielsen, “SOAP Version 1.2 Part 1: Messaging
Framework”, June 2003. Available at http://www.w3.org/TR/SOAP
[6] E. Davis, “Representations of Commonsense Knowledge”, Morgan Kaufmann Publishers, 1990
[7] T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler, F. Yergeau, J. Cowan, “Extensible Markup Language
(XML) 1.1”, Febuary 2004, Available at http://www.w3.org/TR/xml11
.
[8] H. Chen, S. Tolia, C. Sayers, T. Finin, A. Joshi, “Creating Context-Aware Software Agents”, Article, First
GSFC/JPL Workshop on Radical Agent Concepts, September 2001
[9] H. Chen, T. Finin, A. Joshi, “An Ontology for Context-Aware Pervasive Computing Environments”, Article,
To appear in Special Issue on Ontologies for Distributed Systems, Knowledge Engineering Review,
November 2003.
[10] H. Chen, T. Finin, A. Joshi, “An Intelligent Broker for Context-Aware Systems”, InCollection, Adjunct
Proceedings of Ubicomp 2003, October 2003.
[11] H.S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, “XML Schema Part 1: Structures”, May 2001,
Available at http://www.w3.org/TR/xmlschema-1
[12] UDDI Project, “UDDI Technical White Paper”, September 2000, Available at http://www.uddi.org
[13] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, “Web Services Description Language (WSDL)
1.1”, W3C Note, March 2001, Available at http://www.w3.org/TR/wsdl
31
[14] F. Curbera, W. Nagy, S. Weerawarana, “Web Services: Why and How”, OOPSLA 2001 Workshop on
Object-Oriented Web Services, Florida, USA, 2001
[15] Java™ 2 Platform, Standard Edition, v1.4.2 API Specification, http://java.sun.com/j2se/1.4.2/docs/api/
[16] International Standard EBNF Syntax Notation – ISO/IEC 14977: 1996(E),
Available at http://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf
[17] D. Grune, H.E. Bal, C.J.H. Jacobs, K.G. Langendoen, Modern Compiler Design, John Wiley and Sons, 2000
[18] E.R.Harold, Processing XML with Java™: a guide to SAX, DOM, JDOM, JAXP, and TrAX, Addison
Wesley, 2003
[19] Alvin T.S. Chan, Hong Va Leong, Joseph Chan, Alan Hon, Larry Lau, Leo Li, "BluePoint: A Bluetooth-
based Architecture for Location-Positioning Services", Proceedings of the ACM Symposium on Applied
Computing (SAC2003), 9-12 March 2003, Florida, USA, pp. 990-995.
32
Appendix A: The grammar of CRL rule in EBNF
<rule> ::= <schedule>* <condition>+ ( (<execute>|<true_in>)
(<execute>|<true_in>)* )* <condition> ::= <true_in>+ <true_in> ::= true_in( <timespace>,
( status( <constant> , <constant> , <constant> ) | <booleanOperator> )+ )
<getState> ::= getState( <timespace>,
status( <constant> , <constant> , <constant> ) | <booleanOperator> )
<booleanOperator> ::=
equal | lessThan | moreThan | lessThanOrEqual | moreThanOrEqual | notEqual ( ( status( <constant> , <constant> , <constant> ) | <arithmeticOperator> | <value_in> | <constant> )+ )
<arithmeticOperator> ::= add | subtract | multiply | divide ( ( status( <constant> , <constant> , <constant> ) | <arithmeticOperator> | <value_in> | <numeralconstant> )+ )
<value_in> ::= value_in( <situation>|<interval> ,
( status( <constant> , <constant> , <constant> ) | <arithmeticOperator> )+ )
<getValue> ::= getValue( <timespace> ,
status( <constant> , <constant> , <constant> ) | <arithmeticOperator> )
<execute> ::= execute( <timespace> ,
( set( <constant> , <constant> , <constant> , <constant> ) | assign( <constant> , <constant> , <constant> , <constant> ) | action( <constant> , <constant> , <constant> ) )+ )
<timespace> ::= ( "s" | "i" )<numeralConstant> <schedule> ::= sch <nonzero>( "0" <nonzero> )* <constant> ::= ( <numeralConstant> | <stringConstant> )+ <numberalConstant> ::= "0" | (<nonzero> <numberConstant>*) <nonzero> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" <stringConstant> ::= "a" | … | "z" | "A" | … | "Z"
Appendix B: The UML Class Diagram of contextLayer.crlParser
33
34 34
ppendix C: The UML Class Diagram of contextLayer.contextSource
A