A Context Information Manager for Pervasive Computing Environments Jérôme Euzenat1, Jérôme Pierson2, Fano Ramparany2 Abstract. In a pervasive computing environment, heterogeneous Although, several scientific domains have considered the devices need to communicate in order to provide services adapted notion of context, the standpoints from which this notion is to the situation of users. So, they need to assess this situation as considered are different: in pervasive computing, the context of an their context. We have developed an extensible context model application in terms of its physical parameters has been especially using semantic web technologies and a context information considered ; in human-computer communication, the context is management component that enable the interaction between most often the user task and the history of its dialogue with the context information producer devices and context information computer [4]; in artificial intelligence, the context is rather consumer devices and as well as their insertion in an open considered as the conditions of validity of an assertion [14]. environment. 2.1 Context in pervasive computing 1 INTRODUCTION1 In pervasive computing, the physical context is of the utmost In a pervasive computing environment, various basic services can importance. In general, it is acquired through sensor data. These be provided by smart devices (e.g., sensors, actuators, human- data are further elaborated into context characterization adapted to computer interface). More advanced services can be provided when their use (for instance « high temperature » for some air they act together and cooperate, but smarter services can only be conditioning controller). With regard to the sensor data (a achieved if the devices could adapt their behaviour to the user, temperature), the information has been weakened (i.e., made less his/her preference and his/her task, than if users have to find the precise) but is more adapted. specific service they want among all the smart devices. The various definitions of context in pervasive computing are This idea requires the perception of the environment in which very often related to an application or a particular domain [6, 15]. devices and users interact. There are pieces of information that can The drawback of this characterization is its reliance on the task: be considered common to all services. In particular, spatial and « high temperature » is not an absolute characterization. It depends temporal location as well as information related to the physical on the use of the room (a sauna or a sleeping room). More than environment in which services are made available [1, 2]. These context, pervasive computing tends to manipulate a elements are part of the context in which applications operate. We characterization of the context in the perspective of an application. are here concerned with context-aware applications, i.e., As a consequence, it is difficult to dynamically implement st non applications whose behaviour is determined to some extent by the expected applications with the characterization of context made for Privacy/Tru context. another one. Web Our goal is to design a context management system general enough to be used by different pervasive computing applications, specific enough for encompassing existing services and Exploitation Discovery applications, and flexible enough for supporting the dynamic History addition of new devices. Context identification First we introduce our proposal for a distributed architecture Perception (symbolic) that manages context information (Section 2), then we define a Sensors (numeric) context representation (Section 3) which is independent of applications and an architecture enabling their evolution. The Figure 1: Model for context in pervasive computing. Data coming from openness of the system will require dealing with heterogeneous sensors are aggregated and elaborated into the context used by applications representations that will have to be reconciled before being used (from[7]). This paper does not consider the orthogonal aspects (discovery, (section 4). For that purpose, we will take advantage of solutions history and security). developed for the “semantic web”. However, multi-application context modelling is now understood in pervasive computing [7] and raises the issue of 2 CONTEXTS considering context independently from applications. Figure 1 Context is the set of information (partly) characterizing the shows the way to progressively elaborate context information from situation of some entity [5]. The notion of context is not universal sensors to applications. We will follow this approach and this paper but relative to some situation [15, 11]. This can be a physical details the content of the perception and situation layers so that situation (as the spatio-temporal location of some person) or they can support the dynamic nature of the environment (new functional (as the current task of the person). sensors and applications appear and disappear). 1 INRIA Rhône-Alpes, France 2 France Telecom R&D, France 2.2 Contexts in artificial intelligence 3 A CONTEXT INFORMATION In artificial intelligence, the notion of context is, in general, MANAGEMENT COMPONENT concerned with the representation of information. It is used for Pervasive Computing applications retrieve context data directly or accounting for two phenomena: the context of validity of indirectly from sensors, which are grounded in the physical information [16] and the efficiency of reasoning in narrower environment. We propose an architecture in which applications do contexts [1]. not need to directly connect to each sensor available and where John McCarthy [17] proposed a formalization of context adding a new sensor does not require all applications to be based on context « reification » as well as the « meta-predicate » ist, recompiled and redeployed. ist(p,c) meaning that assertion p is true in context c. The approaches of context in artificial intelligence allow grouping knowledge in micro-theories [1] and to reason within those. In this 3.1 Architecture framework (that of Cyc), the context is a more precise frame for interpreting information. This kind of approach can be used in Designing an architecture for hosting context-aware services, pervasive computing in order to integrate and interpret data suggests the development of a context management service for provided by sensors. Taking advantage of the theory associated providing other services or devices with context information [6, 7, with the sensor enables reducing the ambiguity of the data it 11]. We have identified several alternative approaches for delivers. In that view, raw data issued from sensors, are generally designing the target architecture. The first approach lets not weakened but rather enriched (and aggregated with other applications directly communicate with sensors they have an information sources allowing to further precise their interpretation). interest in. This approach requires applications to know in advance [14] describes the way to express this kind of context within the who they need to communicate with to get the information they semantic web by providing each triple information on its origin need. Furthermore it adds complexity to the process of information (« quad »). The same model is implemented in modern RDF aggregation, as this process should then be handled by the managers [2]. applications themselves and overloads sensors activity. Finally this Although work from McCarthy and Guha consider contexts as approach makes it difficult to insert new sensors into the independent theories related to some particular knowledge field, environment and thus doesn't comply with our flexibility Fausto Giunchiglia instead considers contexts as concurrent requirement. viewpoints on the same information. He expresses the relations In the framework of service oriented architectures, the second between contexts as « mappings » used for importing information approach consists of building a context management service [4] under some context into another. This approach can be useful in whose job is to collect sensors information and forward this pervasive computing when several information sources provide information to applications that need it. This approach makes it comparable information. These works found their way within possible to gather sensor information in a single place so that semantic web tools through the C-OWL language [18]. A information could be easily aggregated. For example, a system that comparison of both approaches is made in [19]. provides local temperature and atmospheric is very useful in a home environment. At a city level, the same information is useful; however it doesn't need the same degree of precision. The 2.3 Synthesis drawback of such a system is that it centralizes the management of context information, which is contradictory to the concept of In summary, pervasive computing tends to consider context as context. More specifically, this system provides information about what characterizes the situation while artificial intelligence rather the activity environment (a special case of context information), characterizes the information itself. More notably, Pervasive however this information is not contextual as it is independent of computing very often deals with the particular context of an the current task or situation, i.e. that of the client application. application while artificial intelligence determines the context in Moreover, with such a system, the scope of context management function of the information source. In pervasive computing, would be efficient in a limited area only. information coming from sources is very often weakened in order We have adopted a third approach in which each device or to fit the application needs while artificial intelligence tends to service embeds a context management component (CMC) for enrich it with further information. maintaining context information for its own use or for the benefit Of course, these approaches are rather complementary than of others (Figure 2). The main advantage of this approach is that competitors. In general, raw data can go through weakening and new devices can join online or leave, without having to recompile enrichment, thus bridging both approaches. or reinitialize any part of the whole environment. This component In pervasive computing, upgrading the environment is not an provides mechanisms for helping context-aware devices to request option: the environment must be designed from scratch in order to context information from context sensitive devices. evolve. Our goal is to contribute to dealing with the dynamic evolution of context [7]. For that purpose, we design an architecture supporting the introduction of new context elements (provided from some new device) and the introduction of new applications without interruption of the environment. This component-based context management architecture relies on a context modelling formalism based on semantic web technologies. We demonstrate how they can be used to dynamically extend the environment. Web CMC . Privacy/Tru st Alignment Service . CMC CMC CMC CMC . CMC . . . CMC . Figure 2: Each device embeds a context management component (CMC) and a semantic description of its context. implement the open world assumption under which it is always 3.2 Interaction possible to add more information to a context characterization; and Applications should be able to query context information they are they have been designed to work in a networked way. interested in and some services should be able to provide context information, such as aggregated context information to other devi- ces. For this purpose we design a protocol that makes the best of 4.1 Context model and language available services. We need to be able to identify a service, to In this dynamic pervasive computing environment, each CMC know what kind of context information it could provide and to manages context information of its device. To express its context interact with it to get access to this information. Thus the context model, its needs or its capabilities, we use semantic web languages. management component provides a few methods. In our They ensure interoperability between these heterogeneous devices. description the first element is the query, the second is the response The ground language for the semantic web is RDF (Resource type: Description Framework [8]). It enables expressing assertions of the form subject-predicate-object. The strength of RDF is that the Id() -> URI: The identifier of the service; names of entities (subjects, predicates or objects) are URIs (the Cl(URI) -> URI: The class of the identified service; identifiers of the web that can be seen as a generalization of URLs: Desc(URI) -> OWL: The description of the information that http://www.w3c.org/sw). This opens the possibility for different the component can provide; RDF documents to refer precisely to an entity (it is reasonable to Req(RDQL) -> RDF. assume that a URI denotes the same thing for all of its users). The OWL language [9], has been designed for expressing The first method allows identifying devices that are available in the « ontologies » or conceptual models of a domain of knowledge. It environment. The identifier can then be used to contact the device. constrains the interpretation of RDF graphs concerning this domain. Alternatively, it could be used to get a more detailed description of OWL defines classes of objects and predicates and makes it the device (e.g., in case the identifier is a URI pointing to a possible to declare constraints applying to them (i.e., that the network location where a description of the identified object is « output » of a « thermometer » is a « temperature »). stored). A second method identifies the class (in OWL terminology) The context model that we use at that stage is very simple: a of the device. In theory, this class should be accessible from the context is a set of RDF assertions. Interoperability is guaranteed network and once its definition is found, it provides a detailed through considering that context-aware devices are consumers and description of the device. A third method provides the device producers of RDF. However, this is not precise enough and devices description (or rather that of context information they provide) in may want to extract only the relevant information from context an OWL formalism (OWL-S). A fourth method is used to post sources. For that purpose, a language like RDQL [10] is useful for queries to the devices and to get the context information returned. querying or subscribing to context sources. In order to post the Thus any device is able to: find out, in its environment, relevant queries to the adequate components, it is necessary that services that are able to provide information relevant to its own components publish the OWL classes of objects and properties on context, get features of services that have been found (for example, which they can answer. measurement precision), connect to the selected service to get the information sought. We need a language to describe the context model of 4.2 Why ontologies? heterogeneous devices so that these devices can interact in a dynamic environment. If we can add components at any time, they may not be easily usable. Indeed, there is no a priori reason that components available, new applications and new sensors are compatible. 4 OPENESS, DYNAMICS AND Fortunately, knowledge representation techniques, and namely the HETEROGENITY open world assumption, makes it possible to introduce new device specifications in the environment by extending the ontology, The languages developed for the semantic web, and particularly through specifying a new concept or a property. Using ontologies RDF and OWL, are adapted to context representation in pervasive to characterize the situations permits new equipment whose computing and particularly to the representation of dynamically capabilities have not been known at the beginning to enter and new evolving contexts for two reasons: these languages are open: they applications to benefit from these possibilities. The applications must be as general as possible describing the information they need 5 RELATED WORKS whereas the context management system must be as precise as possible on the information it makes available. This approach In pervasive computing, it is largely recognized that handling enables the most specialized applications to take advantage of context information is essential. As we presented, there are many CMCs. The essential point is to have sufficiently generic different management systems for context information. The one ontologies to cover the various concepts implied in pervasive which is the nearest to what we presented here is the work on computing applications [12]. contextors [11]. It proposes a library of elements able to provide context information: it makes it possible to combine contextual information on a distributed mode. On the other hand, this system 4.3 Taking advantage of heterogeneous resources does not establish how to dynamically add devices without stopping the system or other devices. Regarding to the use of the The context management system we propose makes it possible to semantic Web technologies to represent context, there are several introduce new devices in the environment by extending the proposals to extend the languages of the semantic Web in order to ontologies in such a way that existing applications can make the contextualize the assertions [14, 19, 2]. With regard to the use of best use of them. However, this view holds if all parties share the OWL to represent the context information, [12] introduces a high same ontology. level ontology of contextual information for pervasive computing. Unfortunately this is not always the case and agreeing on standard, universal and self contained context ontology is not a reasonable assumption. This raises the issue of matching context 6 CONCLUSION AND PERSPECTIVES information with applications context information requirements. There are three alternative approaches addressing interoperability We specifically addressed the problem of adaptability of context in pervasive computing environments: (i) A priori standardisation management to an ever-evolving world. This is achieved by of ontologies, (ii) setting up mediators among ontologies and (iii) a providing a distributed component-based architecture and by using dynamical ontology matching service. These three approaches are semantic web technologies. Components enable the addition, at not incompatible and might even be jointly used. For example any moment, of new devices that can provide information about the parties could agree on sharing common high level ontologies. context of applications. The use of RDF and OWL ensures Letting more specific level ontology evolve freely and interoperability between components developed independently by independently is a strategy enabling a close account for a fast taking advantage of the open character of these technologies. evolving domain. Moreover, using ontology alignment modules allows dealing with As ontologies, matching services should be available for the necessary heterogeneity between components. The proposed applications and context managers through network access. They approach relies on a minimal commitment on basic technologies: provide an interface that allows the explicit handling of ontologies RDF, OWL, and some identification protocol. alignments developed in the framework of the semantic web [20]. We are currently developing a demonstrator of this We propose to set up one (or more) ontology matching service(s) technology. It consists of a toolkit for developers of pervasive (Figure 3). The goal of such services is to help agents (context applications which help them deploy a distributed context managers in our case) to find a matching between different management system. This toolkit provides a component for ontologies. These services provide mechanisms for finding out managing (searching, broadcasting and updating) context ontologies close to a given ontology, archiving (and retrieving) information. past alignments, dynamically computing matching between two ontologies and translating queries and responses to queries between context managers that use different ontologies [13]. Physical Context isA Context isA isA isA Temperature Brig htness WEB Ho use Context Room Context isA isA isA Temperature °C Temperature °F Temperature °K isA isA isA Avera ge Time Resident Temperature ⌠ Ph ysical Avera ge context Temperature Alignment isA Service isA isA myRo omTemperature Temperature Brightness >> Figure 3: For finding correspondence between its model and the model of the context information provider, the window service asks to an alignment service to translate his model to another device model. ACKNOWLEDGEMENTS Fano Ramparany and Jérôme Pierson are partially supported by the European project Amigo (IST-2004-004182); Jérôme Euzenat is partially supported by the European network of excellence Knowledge Web (IST-2004-507482). REFERENCES [1] R. Guha, Contexts: a formalization and some applications, PhD thesis, Stanford university (CA US), 1991 (Technical Report STAN-CS-91- 1399-Thesis et MCC ACT-CYC-423-91). [2] O. Khriyenko, V. Terziyan, Context description framework for the semantic web, Proceedings Context 2005 Context representation and reasoning workshop, Paris (FR), 2005 [3] A. Dey, D. Salber, G. Abowd, A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications, Human-Computer Interaction 16:97-166., 2001 [4] P. Dourish, Seeking a foundation for context-aware computing, Human-Computer Interaction, 16(2-3), 2001. [5] M. Chalmers, A Historical View of Context, Computer supported cooperative work 13(3), 223-247, 2004. [6] A. Dey, Understanding and using context, Personal and ubiquitous computing 5(1):4-7, 2001. [7] J. Coutaz, J. Crowley, S. Dobson, D. Garlan, Context is key, Communications of the ACM 48(3):49-53, 2005. [8] G. Klyne, J. Carroll, Eds., Resource Description Framework (RDF): Concepts and Abstract Syntax, W3C Recommendation, 2004 http://www.w3.org/TR/rdf-concepts/ [9] M. Dean, G. Schreiber Eds, OWL Web Ontology Language: Reference, W3C Recommendation, 2004. http://www.w3.org/TR/owl- ref/ [10] A. Seaborne, RDQL — A Query Language for RDF, W3C Member submission, 2004. http://www.w3.org/Submission/2004/SUBM- RDQL-20040109/ [11] J. Crowley, J. Coutaz, G. Rey, P. Reignier, Perceptual components for context aware computing, Proceedings International Conference on Ubiquitous Computing, Göteborg (SW), pp. 117-134, 2002. [12] X. H. Wang, D. Q. Zhang, T. Gu, H. Keng Pung, Ontology based context modeling and reasoning in OWL, Proceedings 2nd International conference on pervasive computing and communication Workshop on Context Modeling and Reasoning (CoMoRea), Orlando (FL US), 2000. [13] J. Euzenat, Alignment infrastructure for ontology mediation and other applications, Proceedings ICSOC 1st international workshop on Mediation in semantic web services, pp.81-95, Amsterdam (NL), 2005. [14] R. Guha, R. Fikes, R. McCool, Contexts for the Semantic Web, Proceedings 3rd ISWC, Hiroshima (JP), LNCS 3298:32-46, 2004. [15] H. Chen, T. Finin, A. Joshi, An Ontology for Context-Aware Pervasive Computing Environments, Knowledge engineering review 18(3):197-207, 2004. [16] J. de Kleer, An assumption-based TMS, Artificial Intelligence 28(2):127-162, 1986. [17] J. McCarthy, Notes on formalizing context, Proceedings 13th IJCAI, Chambéry (FR), pp. 555-560, 1993. [18] P. Bouquet, F. Giunchiglia, F. van Harmelen, L. Serafini, H. Stuckenschmidt, C-OWL: contextualizing ontologies, Proceedings 2nd ISWC, Sanibel Island (FL US), LNCS 2870:164-179, 2003 [19] L. Serafini, P. Bouquet, Comparing formal theories of context in AI, Artificial Intelligence 155:1-67, 2004. [20] J. Euzenat, An API for ontology alignment, Proceedings 3rd ISWC, Hiroshima (JP), LNCS 3298:698-712, 2004.