High Level Context Query Processing:

An Experience Report

Cristina Frà, Massimo Valla Strategy & Innovation Telecom Italia S.p.A.

Torino, Italy {cristina.fra, massimo.valla}@telecomitalia.it

Nearchos Paspallis Department of Computer Science

University of Cyprus Nicosia, Cyprus

nearchos@cs.ucy.ac.cy

Abstract — Pervasive applications want to describe in simple ways which context information they need about users, and be notified when low level context matches specified constraints defined by semantic expressions. In this paper we report our experience while implementing our Context Query Language and using it in a real context framework to support mobile context-aware applications in two European-funded projects. Our experience has shown that both the language design and its implementation are suitable to support complex asynchronous high-level context notification requirements from applications.

Keywords- context awareness; context query processing; CQL; experience; implementation; context models; context management

I. INTRODUCTION

Pervasive applications need to access heterogeneous context information about users and their devices in simple ways, without dealing with details about how raw sensor data was collected and how higher level context data has been derived from it. In addition, since context changes are asynchronous by nature, applications are interested to be notified when context matches specified constraints, often expressed at a semantic level, without knowing or specifying the equivalent constraints on raw sensor data.

In the past years, starting from a set of requirements and an analysis of related work on query languages for context data [1], we have proposed and implemented a new Context Query Language (CQL) [2] that allows applications to request and subscribe for notification of context information specifying a set of constraints on context values or using semantic expressions.

The CQL language design offers advanced features such as: (a) filters and constraints to subscribe to asynchronous context change events, on both context data and metadata; (b) a set of logical operators to combine elementary conditions into more complex ones; (c) access to current and past context information—raw or derived from other information—enabling the retrieval of a set of context elements using a single query; (d) programming language and system independent: access to context data is provided through high level APIs; (e) ability to formulate queries that

incorporate semantic reasoning and aggregation functions (e.g. “average network speed is below 1.0 Mbps”).

In this paper we report on our experience with both implementing the Context Query Language within our context framework and with applying it to a set of use cases related to context-aware applications for mobile users. In our approach, context is first collected by sensors on mobile phones and then delivered to a context management server, which notifies applications that have subscribed to it using CQL queries [4].

To describe how our implementation works, in the rest of the paper we will follow a specific technical use case: an application is interested to be notified when a user is “at home”. In a simple implementation, the user device could update regularly its GPS position to a server to compare with the coordinates of what the user has specified as “home” in his user profile. There are two main disadvantages to this simple approach: first, the position of the user can be of interest to several services but the device cannot continuously update its position to all of them. Second, the energy consumption implied by the continuous transmission of GPS position can be significant for mobile devices. A layered context architecture (which includes sensing & triggering, context management, context reasoning, query & notification) is thus needed to decouple applications requiring context notifications from device sensing. Furthermore, for privacy reasons the user may not want applications to know the exact coordinates of his home location, but may be willing to notify them when he reaches “home”. In a more complex scenario, users may associate the concept of “home” to several locations (“regular home”, “vacation home”, etc.) and context reasoning is needed to notify applications in all cases, regardless of the specific location of each user’s home.

The technical use case presented here may be a component for applications interested in knowing when a user is in a specific place type without knowing his exact location: a telecommunication operator could for example apply different mobile phone rates when the user is at home or in the office; advertising applications may deliver contextualized advertising messages when users are “with friends” and “at the mall”. The use case involves the translation of a high level query (“user is at home”) into

8th IEEE Workshop on Context Modeling and Reasoning

978-1-61284-937-9/11/$26.00 ©2011 IEEE 421

constraints on raw context data (GPS position) and the provision of monitoring conditions called triggers on the user device. In the following we describe the process from the reception of the high level query from an application, to the provision of triggers and finally to the notification sent to the application about matched context condition.

This paper aims at presenting our experience in the implementation of context query processing functionality on a real context framework. In fact, the implementation described here has been applied successfully in extensive application scenarios within two European projects: IST-MUSIC [11] and ICT-CCAST [12], which will be summarized in the evaluation section. In particular, our experience has shown that: (a) our CQL is expressive enough to support applications’ context requirements, yet it is simple to define and aggregate context conditions, thus reducing application complexity; (b) runtime performance is improved as conditions on context data are processed according to triggers deployed on mobile node sensors, avoiding unnecessary data transmission and reducing the number of notifications to be processed; (c) since semantic relations and concepts can be included in the queries, applications can remain at a more abstract layer without dealing with how raw context data is collected in practice from device sensors and how the conditions are verified.

In this paper Section II describes related work about context query languages; Section III briefly summarizes our context model and the design of the CQL to better understand the subsequent context query examples; Section IV describes the software architecture of the context framework; Section V details context processing and involved steps; Section VI gives details about the implementation and provides an evaluation; finally Section VII summarizes our conclusions.

II. RELATED WORK

Several approaches have been proposed to express context queries. An analysis of existing approaches has been already proposed [1] [2]; in this section we briefly describe works most relevant to our solution, paying attention to their context query processing features.

In PACE [5] the context management system provides aggregation and storage of context information and performs query evaluation. It contains a distributed set of context repositories where each repository manages a collection of context models, defined using CML - Context Modeling Language, and mapped to relational data schemes; context queries are internally mapped to SQL. PACE supports asynchronous programming by providing a trigger mechanism and an event-condition-action (ECA) model. Since context information is spread over several tables, a number of joins may be necessary in quite complex queries, in particular when performing context reasoning. The programming API of CML does not address the retrieval of context information with heterogeneous representations and inclusion of complex preprocessing functions is not supported. Another difference with the programming API of CML is that the CQL presented in this paper provides the

possibility to specify context queries in a platform and programming language independent way.

The Nexus project [6] has implemented servers for different classes of context data and a very flexible federation middleware for integrating them. Typical context information requests use either the object ID or the position to select a set of context objects, and then filter the attributes of the selected objects. For example, "all persons in 100m radius (selection: position), give me just the name (filter: name))”. To be part of the Nexus platform, a context server has to implement a certain interface: accept simple spatial queries and return results in specified XML languages called Augmented World Query Language (AWQL) and Augmented World Modeling Language (AWML). AWQL allows for spatial predicates like ‘overlaps’ or ‘within’ (range queries) and supports selections of the n objects nearest to a given position (nearest neighbor queries).

The CARE middleware [7] supports asynchronous notifications to applications using a triggering mechanism. Triggers are derived from requested context conditions set by applications (called monitoring specifications) and, similarly to our solution, triggers are communicated (using a socket protocol) to a light server module resident on the user’s device. Context triggers are derived from monitoring specification in an optimized way, to minimize unnecessary context updates.

III. CONTEXT MODEL AND QUERY LANGUAGE

For context modeling we chose a simple but highly extensible approach [3] based on XML where context information is represented in terms of context elements. Every context element contains a set of context values (represented as key-value pairs) belonging to the same domain (e.g. position, civil address, environment, etc.). We refer to a specific domain as a context scope; for example the scope position is composed by a couple of geographical coordinates (latitude and longitude) and optionally an accuracy estimation. An entity refers to a concrete object in the world (e.g. user, device, room, etc.) and is the subject the context data refer to. According to this model, every context element refers to a specific entity-scope couple.

The Context Query Language (CQL) was defined as an XML-based language, strongly related to the underlying context model. It allows applications to submit complex queries by specifying a set of constraints representing query filters. Every query is about an entity—or a set of entities belonging to the same type—and also about a context scope. Simple queries may not have conditions while more complex queries can have one or more conditions containing constraints connected with logical operators (potentially with unlimited nesting).

CQL supports semantic references obtained through an ontology and used to describe concepts and relationships between entities. In this paper we assume that an ontology describing all the concepts involved in the query examples was available at a specific URL (for example:

422

http://www.example.com/ontology.xml). This URL, which would be normally used as the prefix of the various entity/scope designations, is omitted in the following examples to avoid cluttering.

The language allows applications to submit synchronous (SELECT) or asynchronous (SUBSCRIBE) queries to the system. For example an application that needs to be notified every time a user is in Turin can submit the following query: <ctxQuery> <entity ontConcept= "#Concept.EntityType.User">*</entity> <action type="SUBSCRIBE"/> <conds><cond type="ONVALUE"> <constraint ontConcept=”#Concept.Scope” par="civilAddress.city" op="EQ" value="Turin"/> </cond></conds> </ctxQuery>

The query is a subscription (specified by the action tag) related to all users in the system (identified by the wildcard ‘*’ in the entity tag). The condition specifies a type and a constraint that is on the value of a specific scope attribute. The scope under constraint is civilAddress and specifically the constraint is on its attribute city that must be equal to ‘Turin’. Attributes ontConcept are used to identify the semantic concepts involved in the query.

IV. SOFTWARE ARCHITECTURE

The use case presented is enabled by a general client-server Context Framework [8] illustrated in Figure 1. On the client side a Local Context Broker (LCB) collects data from different sensors. In the example used in this paper the following context sensors are installed on the mobile device: GPS and Wi-Fi, but other sensors can be installed. According to some energy saving policies and to applications needs, context data is updated using HTTP to the Context Broker (CB) server that makes this information available to applications through a set of web APIs. In our framework, context information is represented using ContextML [9] [10], a XML-based binding of our context model, and exchanged between components using HTTP. The Context Broker can also communicate with the LCB of registered mobile devices by sending commands using XMPP RPC extensions [13]: this enables a server-to-device channel to allow control by the server of context update policies on the device. For example the Context Broker, based on current applications’ needs, can send a command on the device to activate/deactivate a context sensor. In our use case, the Context Broker sends commands using XMPP to provision on the device a context trigger containing conditions: when the context conditions are matched by sensors, context is updated by LCB to the server.

The Context Broker acts as an aggregator of raw context data related to the same entity coming from different sources and exploits other components in order to infer higher level context information. These components (in the following we refer to them as Context Providers - CP) are easily pluggable in the architecture since the CB offers an API that a Context Provider can invoke to register itself and to announce its capabilities in terms of entities and scopes.

ContextML data

LocalContext Broker(LCB)

Context Broker (CB)

Context Application

mobile network

1. query

Context Query 

Processor

7. notification

3. triggersactivation(via XMPP)

5. context update

CQL messages

2. triggers creation

4. triggers evaluation

6. condition evaluation

ActiveQueryDB

Web APIs

sensors

Location Provider

Weather Provider

...

Figure 1. Overall system architecture and query processing steps.

For example consider two CP plugged on the system, the first one able to translate the user’s position in the corresponding civil address and the second one able to retrieve the weather condition in a specific city. An application can ask for the weather conditions in the city where the user is currently located. If the user’s device sends the GPS position to the CB, it invokes these two backend components first to translate the geographical coordinates in the corresponding civil address and then to retrieve the related weather forecast.

More complex Context Providers can announce their capabilities in terms of semantic concepts. For example Figure 1 shows the Location Provider (LP), a CP that during its registration phase announces to the CB that it is able to deal with relations and concepts related to user’s location (in this example the supported relations and concepts are respectively #Concept.Relation.Location.* and #Concept.Location.*). The CB stores these data so every time it receives a request where these concepts and relations are involved can exploit the Location Provider to retrieve needed information.

The Location Provider is able to provide the best calculation of the user’s position starting from raw context data coming from his device. Exploitable raw data are the cell-ID the device is connected to, the list of MAC addresses of visible Wi-Fi access points and Bluetooth devices nearby, the current IP address of the device (if any), etc.

Moreover it stores information about places that have significant meaning for the user. A place is always associated with a semantic type defined as a concept in the ontology (e.g. home, office, etc.) and can be characterized by many raw data like a geographical position, a set of mobile cell-ID, a list of Wi-Fi MAC addresses, etc. Provisioning of preferred places can be done manually by the user, or can be inferred automatically by reasoning on current and historical user’s

423

context data. Through a web portal, the user can select areas on a map to define his preferred places. The acceptable position accuracy can be specified by the user or selected by the LP component using a default value according to the place type. Automatic discovery of a user’s preferred places is still under study and is out of the scope of this paper where we consider the Location Provider as a repository of user’s favorite places regardless how they have been provisioned on the system.

V. QUERY PROCESSING

The case study described in this paper starts from an application that needs to be notified every time a user is at home. From the application point of view, home is a high level concept: it does not matter how many places have this meaning for the user, where they are geographically located, etc. Figure 1 describes the whole query processing, from the query submission to the notification to the application.

A. Context query submission

The high level request described previously can be represented using CQL by the following query: <ctxQuery> <entity ontConcept="#Concept.EntityType.User">Mary </entity> <action type="SUBSCRIBE"/> <conds><cond type="ONVALUE"> <reasconstraint relation="#Concept.Relation.Location.isLocatedIn" toEntities="#Concept.Location.Residential.Home"/> </cond></conds> </ctxQuery>

By submitting this query (step 1 in Figure 1) the application requests to be notified every time Mary is detected at home by the system. The query contains a reasconstraint: the condition is verified if the relation between the main entity (Mary) and the entities specified in the tag toEntities is satisfied. As we will detail in the following, the relation isLocatedIn is supported by the Location Provider that implements it according to the available raw context data. The query is submitted by the application using an HTTP-based API offered by the Context Broker that needs also a callback URL to send the notifications. The processing of the query is in charge of the Context Query Processor, a sub-module of the Context Broker that as initial step of the process checks the query compliance with the CQL grammar and returns a subscription ID that is used by the application to periodically renew the request.

B. Device context triggers

After the syntax validation phase, the Context Query Processor has to translate the query into a set of triggers for the device. Again, the trigger conditions are expressed using CQL. Consider for example a user (Mary) that has her home (in the following we call it h1) provisioned on the Location Provider. Mary’s home is identified by a Wi-Fi MAC address (referred to in the following as wf1). The presence of a reasconstraint requires CQP to ask the support of a

Context Provider to create triggers. Lookup registered Context Providers and their capabilities, the CQP uses the Location Provider to obtain the triggers to send to the device (step 2). Given the entity (Mary), the relation under constraint (isLocatedIn) and the entities involved in it (Residential.Home) the Location Provider returns the condition for the trigger. The LP retrieves from its database the raw data identifying Mary’s home (in this example the Wi-Fi MAC address wf1) and constructs the proper trigger. The evaluation of h1 proximity is done monitoring the Wi-Fi environment nearby Mary’s device since LP assumes the range of the Wi-Fi visibility good enough to consider a device close by a specific location and to satisfy the requested relation (isLocatedIn). Therefore, the condition of the related trigger returned by LP and then sent to the device looks like the following: <conds><cond type="ONVALUE"> <constraint ontConcept="#Concept.Scope" par="wf.wfList" op="CONT" value="wf1"/> </cond></conds>

The trigger condition is on the scope wf that represents the device’s nearby Wi-Fi environment and it is satisfied if the attribute wfList (the list of all the visible Wi-Fi MAC addresses) contains wf1. The trigger condition is also stored by the CQP in its Active Query Database in order to be used later during the condition evaluation phase. The trigger is activated on the device (step 3): every time its conditions filters are met the device sends context updates to the Context Broker (steps 4 and 5). In this way Mary’s device will send an update of the scope wf every time the MAC address of the access point identifying h1 is visible.

C. Subscription evaluation and notifications

Every time the Context Broker receives a context update of wf scope from Mary’s device, data are processed by the Context Query Processor to evaluate the active subscriptions (step 6). The CQP retrieves from the Active Query Database queries that have conditions involving the context just updated and verifies all the constraints, also considering logical connections (AND/OR) with other scopes. In the example the query has no logical operators and the condition is verified on the updated context values, therefore a ContextML notification message is sent to the application. The message also contains the subscription ID it refers to, and is sent to the related callback URL specified in the subscription by the application (step 7). Every notification means that the system has detected Mary is close to her home, while the application remains unaware of Mary’s location, preserving user’s privacy.

D. Conditions on multiple places

The previous case study can be more complex if we consider for example that Mary has a second home provisioned on the Location Provider (in the following we call it h2).

Place h2 is identified by a couple of geographical coordinates expressed in WGS84 system (in the following we refer to them as lat1 and lon1). Once again, after the

424

CB receives the subscription, the Location Provider is invoked to obtain device triggers. In this case the invocation returns one more trigger on the attributes of scope position. For places characterized by a geographical position LP considers the relation isLocatedIn as satisfied if the distance between the user and the place (h2) is under a threshold that depends on the place type (e.g. ~150 meters for places belonging to type home). The threshold will be transformed in the corresponding delta in degrees; therefore the returned condition looks like: <conds><cond type="ONVALUE"><logical op="AND"> <constraint ontConcept="#Concept.Scope" par="position.latitude" op="EQ" value="lat1" delta="0.001"/> <constraint ontConcept="#Concept.Scope" par="position.longitude" op="EQ" value="lon1" delta="0.002"/> </logical></cond></conds>

The previous trigger requires the device to send the scope position only if its attributes latitude AND longitude are respectively equal to lat1 and lon1 within a delta range.

In conclusion, since Mary has provisioned two homes (h1 and h2) two triggers will be provisioned on the device, one for h1 (with a constraint on wf) and one for h2 (with a constraint on position). These two triggers can be merged in a more complex one using logical operators. In our example the trigger sent to the device looks like: <conds><condOp op="OR"> <cond type="ONVALUE"> <constraint ontConcept="#Concept.Scope" par="wf.wfList" op="CONT" value="wf1"/> </cond> <cond type="ONVALUE"><logical op="AND"> <constraint ontConcept="#Concept.Scope" par="position.latitude" op="EQ" value="lat1" delta="0.001"/> <constraint ontConcept="#Concept.Scope" par="position.longitude" op="EQ" value="lon1" delta="0.002"/> </logical> </cond></condOp></conds>

VI. IMPLEMENTATION AND EVALUATION

In this section we present our empirical experience with the implementation and use of CQL in practical use-cases and provide some comparison with existing approaches.

A. Implementing CQL processing

The core of the query processing module (CQP – Context Query Processor) described in the previous paragraph has been implemented as a Java library (~41 KB footprint) and integrated in the Context Middleware of the IST-MUSIC project and in the Context Server of the IST-CCAST project. In MUSIC, context distribution was implemented over the SIP protocol and context notifications were delivered using SIP notifications instead of HTTP, as in IST-CCAST.

The CQP library provides the IContextQueryService interface: this interface has methods that allow the processing of synchronous (SELECT) and asynchronous queries (SUBSCRIBE).

Each time a new query is received by the context framework, the processQuery(IContextQuery) method of the interface is called and the query syntax validated. If the query is synchronous, the returned QueryResponse object contains context information that satisfies the query, if any; if the query is asynchronous, the returned QueryResponse contains a QueryTrigger object to provision the triggers on the device. Once triggers are armed on the device, the asynchronous query becomes active, an unique queryID is assigned and is stored in the CQP’s Active Query Database, along with a reference to the interested entity and application that should be notified. Context queries are considered active until their validity period expires, unless applications renew them. When a triggered context update is received from the device, the processActiveAsynchQuery method is called and the returned QueryResponse contains context information that satisfies the query conditions, ready to be notified to the application.

B. Experience with practical use of CQL in mobile applications

CQL queries were used by two different teams of developers (~12 people) in two European projects.

In the IST-CCAST project the PartyApp mobile web application has used CQL queries in order to be notified when users profiled as ‘friends’ are nearby each-other, thus forming an ad-hoc group to share user generated content using their mobile devices. In the MallApp context queries where used to deliver personalized mobile advertising when a user device was nearby a shop, which was detected by a constraint on the list of nearby Bluetooth devices.

In IST-MUSIC, CQL queries were used in two demonstration applications. In PRM (Passengers with Reduced Mobility), the Paris metro station attendants were able, using their MUSIC-enabled mobile devices, to be notified when a passenger with sight problem was located on a specific metro line: the query involved both profile and location context constraints. Finally in the MUSIC TravelAssistant, a mobile application to provide context-aware itineraries in the Paris metro system, users were notified when a delay was detected on the metro line: a CQL query was used by the application to be notified about “delay context” on lines that are part of the currently selected itinerary.

By using CQL in several application scenarios in the two European projects, we were able to confirm that the language is expressive enough to support use-cases that come from quite different domains. From our experience in both projects, it has been clear that application developers are not interested in receiving continuous streams of raw context data so they are later filtered at the application layer, but instead they are interested in formulating queries with conditions expressed at a higher level, leaving the complexity of verifying these conditions to the underlying context middleware. Such mechanism offers two main benefits: first, the developer can more easily define the equivalent functionality while minimizing the amount of code and thus the risk for bugs. Second, runtime

425

performance is improved because conditions on context data are processed according to triggers on mobile node’s sensors, thus avoiding unnecessary data transmission.

In particular, application developers appreciated the ability to concatenate in a single query different constraints on different context scopes/attributes (e.g. profile AND location, device status AND user proximity), thus reducing the number of notifications to be processed by the application.

Another positive feedback came from the ability to use relations (“isLocatedIn”) and concepts (“home”) in the queries, leaving the application involved only at a semantic level, without dealing with how in practice raw context data is collected from device sensors and conditions on such data are verified by the framework. Programmers have found this capability an important simplifying factor during the development of their context-aware applications.

In the IST-MUSIC project programmers have requested to be able to formulate CQL queries programmatically (i.e., in plain Java), in addition to the standard XML syntax described here. Our CQL Java library was therefore extended to support the creation of queries from the Java code. Another requested feature (not implemented yet) was to expand query renewal mechanisms, to avoid timers in applications, allowing for example an application to renew the CQL query with a command in the HTTP response to the context notification received from the Context Broker, instead of renewing the query with an explicit renewal request.

Since the output of the IST-MUSIC project has been released as open source (LGPL v3 license) programmers interested in the CQL can use the Java library to include CQL query processing in their context frameworks.

C. Evaluation

Compared to existing approaches, the proposed CQL presents a very flexible and simple syntax that allows the programmer to express easily quite complex context queries involving different context information and receive asynchronous notifications. Contrary to other approaches, our query processing is not targeted to a specific context domain (e.g. location context queries).

Similarly to CARE [7], context queries are translated into triggers to be provisioned on the device, to limit unnecessary context updates. However no analytic optimization is performed on triggers to be provisioned: this could be an additional feature to be added to our solution.

A strong point of the proposed solution, which is missing in some related works, is the possibility to express queries at a higher semantic level, as shown in the previous examples. This feature is important to hide from the programmer the complexity of context acquisition and processing, and provides an abstraction from actual conditions on raw context data. In fact, some applications may not be allowed to specify conditions on context using actual values, to guarantee users’ privacy. Our modular solution delegates the generation of triggers to context providers (in our example:

Location Provider), leaving the context middleware and applications unaware of this translation and involved data.

One weak point of the solution is that XML parsing is necessary on the device to interpret triggers received by the Context Query Processor; but provision of triggers is not a frequent operation since occurs only when a new service is activated by the user and XML parsers are now efficient and available on several mobile devices.

VII. CONCLUSIONS

In this paper we described the design and implementation of a query processing mechanism, and reported on our experience with using our CQL language for the development of pilot applications in the environment of two EU-funded projects. Based on our experience from applying the CQL concepts in numerous case study applications—that come from quite different domains—, we have concluded that the design goals have been largely met, simplifying the development of context-aware applications.

REFERENCES [1] P. D. Haghighi, A. Zaslavsky, and S. Krishnaswamy, “An evaluation

of query languages for context-aware computing,” 17th Int. Conf. on Database and Expert Systems Applications (DEXA), September 2006, Krakow, Poland, pp. 455-462.

[2] R. Reichle et al., “A context query language for pervasive computing environments,” 5th IEEE Workshop on Context Modeling and Reasoning (CoMoRea – PerCom 08), IEEE Computer Society Press, March 2008, Hong Kong, pp. 434-440.

[3] M. Wagner, et al., “A Comprehensive Context Modeling Framework for Pervasive Computing Systems,” 8th IFIP Int. Conf. on Distributed Applications and Interoperable Systems (DAIS), June 2008, Oslo, Norway, Springer Verlag LNCS 5053, pp. 281-295.

[4] N. Paspallis, et al., “A Pluggable and Reconfigurable Architecture for a Context-aware Enabling Middleware System,” 10th Int. Symposium on Distributed Objects, Middleware, and Applications (DOA 08), November 2008, Monterrey, Mexico, Springer-Verlag LNCS 5331, pp. 553-570.

[5] K. Henricksen, J. Indulska, T. McFadden, and S. Balasubramaniam, “Middleware for distributed context-aware systems,” in Int. Symposium on Distributed Objects and Applications (DOA), 2005, Springer-Verlag, pp. 846-863.

[6] M. Grossmann, et al., "Efficiently Managing Context Information for Large-Scale Scenarios," Third IEEE Int. Conf. on Pervasive Computing and Communications (PerCom 05), 2005, pp. 331-340.

[7] C. Bettini, D. Maggiorini, and D. Riboni, “Distributed Context Monitoring for the Adaptation of Continuous Services,” 2007, World Wide Web, vol. 10, no. 4, pp. 503-528.

[8] L. Lamorte et al., “A platform for enabling context aware telecommunication services,” Proc. Third Workshop on Context Awareness for Proactive Systems (CAPS 07), 2007, Guildford, UK.

[9] ContextML: A Context Representation and Management Language. ContextML and CQL XML schemas are available at: http://contextml.tilab.com

[10] M. Knappmeyer, S.L. Kiani, C. Frà, B. Moltchanov, and N. Baker, “ContextML: A light-weight context representation and context management schema,” Proc. 5th IEEE International Symposium on Wireless Pervasive Computing (ISWPC), May 2010, pp. 367-372.

[11] IST FP6 MUSIC Project, contract # 35166 - http://www.ist-music.eu

[12] IST FP7 CCAST Project, contract # 216462 - http://www.ict-ccast.eu

[13] XMPP RPC extensions (XEP-0009) - http://xmpp.org/extensions/xep-0009.html

426