PROCEEDINGS OF THE 2nd WORKSHOP ON...

Definition and Implementation of Context Information

M. DEBES1, A. LEWANDOWSKA1, and J. SEITZ1

1INIT, Technische Universität Ilmenau, Germany, e-mail: (maik.debes, agnieszka.lewandowska, jochen.seitz)@tu-ilmenau.de

Abstract – Nowadays, many applications benefit from pervasive and ubiquitous computing. New services can be developed and offered. An important feature is the attempt to adapt ser-vices individually to the user. These services are called context-sensitive services, because they consider the context of the user and of his equipment. Although there are many projects that claim to be context-sensitive, a general definition for term context and a generalized specifica-tion technique for such information cannot be found there. This paper closes this gap and dis-cusses a general definition of the term context for any context-sensitive telecommunication ap-plication. Furthermore, it will be described which context information are relevant for context-sensitive applications, which is illustrated by an ongoing project.

1 Introduction

With the victory of pervasive and ubiquitous computing, new forms of services are emerging. The main feature of these new forms is that they are not provided for each user in the same way. Rather, they are adapted to suit the preferences or abilities of single users or specific user groups. Thus, they are called context-sensitive services. For using one of these services the context of a user, of his equipment and of his environment must to be described, context information must be gathered and analyzed accordingly. But in order to offer context-sensitive services, the term “context” must gener-ally be defined, which, however, is still treated differently in the literature. To introduce the term in a scientific way, a universal definition is needed, which can be mapped to all areas of life. Therefore, the next section of this article discusses a general definition of term context, based on extensive internet retrieval and literature study. Additionally, information describing context are explained.

The third section refers directly to a project in our department. After a short description of the pro-ject we investigate information playing an important role for offering context-sensitive services. For our project, two tasks benefit from context information. On the one hand, the system introduced in the project supports the tourist during a holiday trip. On the other hand, information or services that are optimally adapted to the tourist can be offered.

The fourth section discusses the possibilities of describing context and details how context-sensitive functionality is implemented within our project. Our solution is introduced and its advantages are substantiated. A short summary concludes this paper.

2 Definition of Context

The idea of context is treated differently in the literature. Different classifications and opinions about context information can be found there. First of all, three classes of context can be distinguished: user context, terminal context and communication network context. For given services or applications, these classes can be combined as required. In our article, we focus on the context of the user and the terminal. However, this restriction does not have any effects on the general definition of context we were looking for.

Furthermore, on the one hand a number of authors use a definition considering quite concrete prop-

PROCEEDINGS OF THE 2nd WORKSHOP ON POSITIONING, NAVIGATION AND COMMUNICATION (WPNC’05)& 1st ULTRA-WIDEBAND EXPERT TALK (UET'05)

63

erties which are directly related to an object. On the other hand, one finds quite general definitions in the literature but which are only valid for special application cases.

In [1], context is defined as position, identities (of persons) around the user, time of day, season and temperature. However, these are more special context information than a general definition. The definition in [2] is similarly carried out but only position, surroundings, identity and time is defined as context there. Context is more generally defined in [3]. It describes status, applications, environment, surroundings and situation. Furthermore, there are very general definitions where context is a subset of a physical or conceptual state (i.e. [4]).

Nevertheless, in the authors’ opinion the definition of A. Dey and G. Abowd is the most appropri-ate. They state that context defines a subset of a physical or conceptual status, which is of interest to a certain entity. Their definition includes the complete range of context in such a universal way that it can be applied to very different applications. Dey and Abowd propose the following definition [5]: “Context is any information that can be used to characterize the situation of entities (i.e. whether a person, place or object) that are considered relevant to the interaction between a user and an applica-tion, including the user and the application themselves. Context is typically the location, identity and state of people, groups and computational and physical objects.”

According to the definition by Dey and Abowd, a huge amount of information needs to be gathered and analyzed to describe a specific context. In [6], three different entities were identified – places, people and things. The term “places” applies to geographical spaces like rooms, offices, buildings and so on. People need to be differentiated by groups or individuals. Things refer to physical objects or software components. To describe these entities, four categories are introduced:

• Identity – characterizes the entity with an explicit identifier, which has to be unique in the name domain of the application.

• Location – includes positioning data and orientation as well as information about regional re-lations to other entities (e.g. neighboring entities). This comprises geographical data as well as spatial relations.

• Status – contains properties, which can be perceived by a user. For a place, this can be, for ex-ample, the current temperature, the ambient illumination or the noise level. For persons this refers to physical factors like vital signs, tiredness or the current occupation.

• Time – is both date and time. In contrast [7] classifies the context and the necessary information in three categories:

• Physical context – contains objective information about the user like position, orientation, time, date...

• Action-based context – comprises user-actions, which attract certain attention: what the user thinks, says or what he is currently doing.

• Emotional context – contains the emotional state of the user. The following context information are listed at [8], [3] and [9]: status of user (i.e. moving, walking, standing, talking, …), emotional status of user, events, position, orientation, date, time, objects and people around the user, situation, speed, history of information (i.e. location), preferences of the user, light, status of communication and so on. As described already, all context information cannot be listed here since these can be very manifold. Therefore, in the next section we will describe and justify which context information is relevant for a project processed in our department.

3 Application of Context Information − the “TAS” Project

Our work on context information is motivated by a project funded by the German Federal Ministry of Education and Research (BMBF) in the research program InnoRegio. The project is called „TAS“ – “Touristisches Assistenzsystem für barrierefreie Urlaubs-, Freizeit- und Bildungsaktivitäten” (Tourist Assistance System) [10]. Context-sensitive services play a major role in this project. The main idea behind the project is to guide persons without barriers through tourist areas in the Thuringian Forest.


64

Service ProvidersService Providers

InternetInternet

Tag TagTag

Tag

Tag

ISPControl StationDatabase

MobileDevice

Touristat Home

Touristat Home

ISDN/DSLS2M Router

Barrier-freeinfo point


Service ProvidersService Providers

InternetInternet

TagTag TagTagTagTag

TagTag

TagTag

ISPControl StationDatabase

MobileDevice

Touristat Home

Touristat Home

ISDN/DSLS2M Router



Fig.1 The “TAS” Architecture

Thus, the tour must be adapted to the abilities and the handicap of the tourist. Furthermore, this tourist is provided with services and information which are optimized to the current context. Figure 1 shows the architecture of the “TAS” system. Service providers are able to store their offers and ser-vices, or at least information about their services and where these services are accessible, in the data-base of the control station. Furthermore, this database contains a detailed map of the according tourist area. The subscriber is now able to access information about navigation, routing and additional useful information (opening hours, sights, shopping possibilities etc.). The architecture of “TAS” enables seamless integration of new services and the exploitation of innovative context information. Commu-nication however, is conducted through existing networks, which are connected with the Internet.

Another idea implemented in “TAS” is the possibility to have access to up-to-date information dur-ing a walking-tour or a sporting activity within the so called model region “Thuringian Forest”. Tour plans are easier to organize with an efficient time schedule and management.

The information provided in “TAS” is to be adapted to the user as well as to the current conditions – thus, the current context defines which services and information are offered to the user. Correspond-ingly, the user is provided with information about topics and offers involving tourist activities, sports and environmental issues. Great importance is attached to the need to customize the information in presentation as well as in content so that the user gets guaranteed obstacle free access. Along with that, only the minimum amount of context information should be processed to reduce the load on the com-munication infrastructure by system information as much as possible.

To guarantee the adaptation mentioned above, the system needs to have knowledge about the user’s context. This includes information about the user, the environment of the user, the region where he is located, and so on. Gathering, processing and provision of context information can be implemented as a specific service. Additionally, other services should coexist and can dynamically be added. So it is planned, for example, that the user is notified about special offers in the vicinity (e.g. restaurants, sou-venir-shops, etc.). Providers of such information and services can be tourism business, cultural or medical institutions or emergency services.

Within the framework of “TAS”, the customization of offers to the needs of tourists should happen both generally for each tourist or with regard to blind, partially sighted, or physically handicapped people. The equipment and the services should be realized in a fashion that even elderly people and persons with an inhibition to use “high tech” experience easy access to the system. As hardware, PDAs (Personal Digital Assistant), smaller notebooks, web pads or mobile phones can be used.

For our project, it was advantageous to distinguish two kinds of context information: context in-formation for navigation and context information for service adaptation. In the end, it is not necessary


65

to constantly submit all context information to the control station. Consequently, three procedures to transfer context information can be distinguished: context information may be transmitted periodi-cally, whenever the current status of the user changes, or once, if does not change at all. To illustrate the difference, table 1 gives some examples.

Periodical transmission: Transmission on change of status (according to a logical threshold):

One-time transmission:

• position (longitude, latitude, altitude)

• orientation • time (time of day, date, week-

day, …)

• health (body temperature, heart frequency, blood pressure, …)

• information of fellow passen-gers

• weather (temperature, precipi-tation, …)

• properties of terminal (charge state, …)

• properties of terminal (kind, dimension of display, resolu-tion of display, …)

• kind and degree of handicap • user preferences (interests, etc.)

Tab. 1 Examples for Context Information and their Transmission

4 Specification of Context Information

After having defined context types for the project “TAS” it must be discussed, how this information shall be specified. Therefore, methods and procedures are analyzed which are also used in other pro-jects. The evaluation of the publications for the projects described above yielded that there are almost no special formats, possibilities and methods for transmitting context information. Rather, this sug-gests that context data will be transferred in some kind of textual form with the help of conventional protocols. Merely in [11], [12], [13], [14] and [15], context information is processed, evaluated or passed on by XML (eXtensible Markup Language). Furthermore, the project “Crumpet” [16] uses GML (Geographic Markup Language). This is a kind of XML which was specified especially for vec-torial geographical objects. In addition POIX (point of Interest eXchange Language) of the W3C (World Wide Web Consortium) is also used in this project in which POIX is generated from GML. Nevertheless, a format also had to be found for the project “TAS” described above to transmit and to be made available the context information in a suitable way. Finally, we also agreed to use XML as description language.

XML was developed for structuring data. The description is carried out via text. XML is expand-able and platform-independent. It is an open standard by the W3C. XML contains rules and conven-tions for the construction of document formats and the structuring of data. With this language it is simply possible to store arbitrary data. In addition, it realizes a uniform, open, generally recognized, and far common interface for structured data. The structure resembles this of HTML. However, XML has the advantage that the names of the Tags can be freely chosen, which makes XML very flexible. Even the structure of the data can be defined in limits itself and specified according to the usage. Be-sides this, special XML parsers allow programs to exchange data in the XML format.

The same functionality could be realized with the help of programming languages (i.e. C, C++, Java et cetera). However, firstly the corresponding structure has to be defined or programmed there. Hoew-ver, platform independence is not supported by every programming language. So XML is very well suitable with that to fulfill requirements for the description of the context within the project “TAS”. Figure 2a shows an example of a XML file with the context information for a person.

Because not all context information are time-dependent or variable and a unique identifier relates person and context information there is no need to constantly transmit static information at any time, which is depicted by the XML file in figure 2b. It only contains variable context information unlike the example from illustration 2a. By this concept bandwidth can be saved. On the other hand there is also the question when this information must be transmitted at all. Here an optimum between actuality of the context information and the traffic load created by it must be found. However, this discussion shall not be object of this article. It must be taken into account in the further course of research.


66

<USERKONTEXT> <user_label ID="001"> <PERSONAL_CONTEXT> <user_data> <name>Jane Doe</name> <interest>music</interest> </user_data> <group_membership/> <health_state> <heart_frequency>70</heart_frequency> <blood_pressure>120/80</blood_pressure> <body_temperature>36,2</body_temperature> </health_state> <handicap> <kind>seeing-hindrance</kind> <degree>50%</degree> </handicap> </PERSONAL_CONTEXT> <TECHNICAL_CONTEXT> <equipment> <type>Pocket PC</type> <display> <resolution>240x320</resolution> <color>monochrome</color> </display> <hardware_buttons> <number>4</number> <emergency_call>yes</emergency_call> </hardware_buttons> <audio_output>yes</audio_output> <speech_synthesis>yes</speech_synthesis>  <state of battery>100%</state of battery> </equipment> <technical_environment device="mobile"> <net>GSM/GPRS</net> </technical_environment> </TECHNICAL_CONTEXT> <ENVIRONMENT_CONTEXT> <time> <date>18.10.2004</date> <hour>13:34</hour> </time> <localization> <GPS> <length>10°56'23''oL</length> <width>50°40'55''nB</width> </GPS> <RFID-Tags/> </localization> <orientation/>  <environment> <weather> <temperature>10°C</temperature> <weather_conditions>rainy</ weather _conditions> </weather> </environment> </ENVIRONMENT_CONTEXT> </user_label>  </USERKONTEXT>

<USERKONTEXT> <user_label ID="001"> <PERSONAL_CONTEXT> <health_state> <heart_frequency>70</heart_frequency> <blood_pressure>120/80</blood_pressure> <body_temperature>36,2</body_temperature> </health_state> </PERSONAL_CONTEXT> <TECHNICAL_CONTEXT> <equipment> <state of battery>75%</state of battery> </equipment> <technical_environment device="mobile"> <net>GSM/GPRS</net> </technical_environment> </TECHNICAL_CONTEXT> <ENVIRONMENT_CONTEXT> <time> <date>18.10.2004</date> <hour>13:44</hour> </time> <localization> <GPS> <length>10°56'23''oL</length> <width>50°40'55''nB</width> </GPS> </localization> <orientation/>  <environment> <weather> <temperature>9°C</temperature> <weather_conditions>rainy</ weather _conditions> </weather> </environment> </ENVIRONMENT_CONTEXT> </user_label>  </USERKONTEXT>

Fig. 2a Representation of context information via XML (first transmission)

Fig. 2b XML file for variable context information (after first transmission)

5 Conclusion

The article discussed different suggestions for a general definition of context. A detailed enquiry was conducted. As a result, the authors favor the definition in [5], because it describes context clearly and so generally that it can be mapped to all variants of context. It was shown, which context information are generally used. Furthermore, we explained that not the complete set of context information is needed to realize a context-sensitive service. In fact, a choice of context information according to the application has to be carried out. So the context is application-dependent. It was shown with the pro-ject “TAS”, how a choice of suitable context information can be carried out. The required context types were listed, explained and justified why these were chosen. The composition of the context in-formation describes the current working status of the project. However, it cannot be complete for the reasons mentioned above. The system described for “TAS” is expandable. So additional context in-formation may be introduced according to the service, which will be offered in future. “TAS” supports a much wider spectrum of such information unlike other projects, where you can find only the position as context information. Finally, it was shown that XML is very suitable as a description language for context. The advantages and the flexibility as well as the clear structure promote the use of this lan-guage. So XML will be also used for the description and transmission of context information “TAS”.


67

6 References

[1] P. Brown, J. Bovey, and X. Chen, “Context-aware applications: From the laboratory to the mar-ketplace”, IEEE Personal Communications, vol. 4, no. 5, pp. 58-64, 1997.

[2] N. Ryan, J. Pascoe, and D. Morse, “Enhanced reality fieldwork: the context-aware archaeological assistant”, In Gaffney, V. et al. (Eds.) Computer Applications in Archaeology, 1997.

[3] A. Schmidt, K. Aidoo, A. Takaluoma, U. Tuomela, K. Van Laerhoven, and W. Van de Velde, „Advanced Interaction in Context“, 1th International Symposium on Handheld and Ubiquitous Computing (HUC99), Lecture notes in computer science, vol. 1707, Springer, pp. 89-101, 1999.

[4] J. Pascoe, N. Ryan, and D. Morse, “Human-Computer-Giraffe Interaction – HCI in the field”, Proceedings of the Workshop on Human Computer Interaction with Mobile Devices, Glasgow, Scotland, 1998.

[5] A. Dey and G. Abowd, “Towards a better understanding of context and context-awareness”, Pro-ceedings of the Workshop on the What, Who, Where, When and How of Context-Awareness, affili-ated with the CHI 2000 Conf. on Human Factors in Computer Systems, New York, NY, 2000.

[6] A. Dey, D. Salber, and G. Abowd: “A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications”, Special issue on Context-Aware Computing in the Human-Computer Interaction (HCI) Journal, vol. 16 (2-4), pp. 97-166, 2001.

[7] A. Dey and G. Abowd: "CyberDesk, The Use of Perception in Context-Aware Computing", Ex-tended Abstract presented as a poster in the Proceedings of 1997 Workshop on Perceptual User Interfaces PUI ’97, Oct. 1997, pp. 26-27.

[8] A. Dey: “Context-aware computing: The CyberDesk project”, Proceedings of the AAAI 1998 Spring Symposium on Intelligent Environments, AAAI Press, Menlo Park, CA, 1998, pp. 51-54.

[9] Ch. Bornträger: “Contextual Influence on the Usability of Different Media Types”, Diploma The-sis, Technische Universität Ilmenau, Ilmenau, Jan. 2003.

[10]M. Debes, M. Heubach, J. Seitz, and R. Tosse, “Information without Barriers - A New Form of Ubiquitous Computing”, 48. Internationales Wissenschaftliches Kolloquium IWK 2003, Tech-nische Universität Ilmenau, Ilmenau, Sep. 2003

[11]R. Wasinger, C. Stahl, and A. Krüger, “M3I in a Pedestrian Navigation & Exploration System”, Proceedings of the Fourth International Symposium on Human Computer Interaction with Mobile Devices, 2003, pp. 481-485.

[12]A. Krüger, A. Butz, C. Müller, C. Stahl, R. Wasinger, K. Steinberg, and A. Dirschl, “The Con-nected User Interface - Realizing a Personal Situated Navigation Service“, Proceedings of the 9th International Conference on Intelligent User Interface, 2004, pp. 161-168.

[13]H. Anegg, H. Kunczier, E. Michlmayr, G. Pospischil, and M. Umlauft, „LoL@: Designing a Lo-cation Based UMTS Application“, ÖVE-Verbandszeitschrift e&i, Springer, Heidelberg, Feb. 2002.

[14]M. Umlauft, G. Pospischil, G. Niklfeld, and E. Michlmayr, “Designing LoL@, a Mobile Tourist Guide for UMTS”, 4th International Symposium on Human Computer Interaction with Mobile Devices (Mobile HCI '02), Pisa, Italy, Sep. 2002.

[15]M. Kruppa and A. Krüger, “Concepts for a combined use of Personal Digital Assistants and large remote displays”, Proceedings of SimVis 2003, SCS Verlag, 2003.

[16]S. Poslad, H. Laamanen, R. Malaka, A. Nick, P. Buckle, and A. Zipf: “CRUMPET: creation of user-friendly mobile services personalised for tourism”, Proceedings of 3G 2001 - Second Int. Conf. on 3G Mobile Communication Technologies, London, 2001.


68

PROCEEDINGS OF THE 2nd WORKSHOP ON...

Documents

Transcript of PROCEEDINGS OF THE 2nd WORKSHOP ON...