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: csyhwong@comp.polyu.edu.hk

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