AmbieSense Reference Information Model - folk.idi.ntnu.no · IST 2001- 34244 D2 - Reference Information Model (RIM) WP2 – Modelling and design of AmbieSense Technology Editors:

IST 2001- 34244

D2 - Reference Information Model (RIM) WP2 – Modelling and design of AmbieSense Technology

Editors:

Stein L. Tomassen (SINTEF) Till C. Lech (CognIT)

Juergen Pollich (YellowMap)

1 © 2004 The AmbieSense Consortium

IST 2001- 34244

Report REPORT TITLE

AmbieSense Reference Information Model

RESPONSIBLE WORK PACKAGE WORK PACKAGE LEADER

WP 2 CognIT (Till C. Lech)

WRITTEN BY

Juergen Pollich, Frank Sembowski (YellowMap) Børge Haugset, Tor Erlend Fægri, Hans Inge Myrhaug, Marius Mikalsen, Stein L. Tomassen (SINTEF) Till Christopher Lech, Robert Engels (CognIT) Anders Kofoed Petersen (NTNU) Heinrich Huber, Peter Markovics (Siemens AG) Murat Yakici, Ayse Göker, Bin Hu, Ralf Bierig, Nik Whitehead (Robert Gordon University)

ABSTRACT

This document is the Reference Information Model (RIM) of the AmbieSense Project. It provides the project’s vocabulary and a consistent description the AmbieSense technology and how it can be applied. This is done by describing the overall system and architecture, the AmbieSense core technology, and four example applications. REPORT STATUS KEYWORDS

Final Version (Revised) Reference Information Model

INITIATED DATE WRITTEN DATE

27-06-2002 30-01-2004

FILE CODE CLASSIFICATION

Public

ELECTRONIC FILE CODE

https://project.sintef.no/eRoom/informatics/ambiesense/Final Deliverables/D2 revised prior to review.pdf


IST 2001- 34244

Table of contents

1 EXECUTIVE SUMMARY ...................................................................................................................5

2 INTRODUCTION TO THE AMBIESENSE REFERENCE INFORMATION MODEL ..............6 2.1 DOCUMENT OBJECTIVES ..................................................................................................................6 2.2 WHAT IS THE AMBIESENSE REFERENCE INFORMATION MODEL? .....................................................6 2.3 THE NEED FOR AN AMBIESENSE REFERENCE INFORMATION MODEL ...............................................6 2.4 HOW TO USE THE AMBIESENSE REFERENCE INFORMATION MODEL.................................................6 2.5 DOCUMENT ROADMAP .....................................................................................................................7 2.6 AUDIENCE ........................................................................................................................................7 2.7 RELATED PROJECT DOCUMENTS ......................................................................................................7

3 UNDERSTANDING AMBIESENSE...................................................................................................9 3.1 INTRODUCTION TO AMBIESENSE ......................................................................................................9

3.1.1 Infrastructure, Framework and Applications ........................................................................10 3.1.2 Current Approaches...............................................................................................................11

3.2 AMBIESENSE SYSTEM CONCEPTS...................................................................................................12 3.3 AMBIESENSE FUNCTIONAL ASPECTS..............................................................................................13

3.3.1 Personalisation of Content and Content Services..................................................................13 3.3.2 Using Context to Provide Relevant Information to the User .................................................13 3.3.3 Ambient Computing — Intelligent Surroundings?.................................................................13 3.3.4 Context-Awareness ................................................................................................................14 3.3.5 Context-Aware Content Delivery...........................................................................................14

4 AMBIESENSE REFERENCE ARCHITECTURE..........................................................................15 4.1 BACKGROUND ................................................................................................................................15

4.1.1 What is a reference architecture?..........................................................................................15 4.1.2 Rationale................................................................................................................................15 4.1.3 Documentation Approach......................................................................................................16

4.2 ENTERPRISE VIEWPOINT – USERS, ROLES AND FUNCTIONALITY....................................................17 4.2.1 Users, Roles and Actors.........................................................................................................17 4.2.2 Use-cases and task models ....................................................................................................19 4.2.3 Summary ................................................................................................................................27

4.3 COMPUTATIONAL VIEWPOINT – AMBIESENSE FUNCTIONAL COMPONENTS ...................................27 4.3.1 User interaction (User Interface) ..........................................................................................29 4.3.2 Applications ...........................................................................................................................30 4.3.3 Agents ....................................................................................................................................30 4.3.4 Content distribution (Pull).....................................................................................................32 4.3.5 Content distribution (Push) ...................................................................................................33 4.3.6 Context management (Context Middleware) .........................................................................33 4.3.7 Content management and integration (CIP)..........................................................................34 4.3.8 Proximity detection................................................................................................................36 4.3.9 Network Service .....................................................................................................................36 4.3.10 Key component interactions...................................................................................................36

4.4 ENGINEERING VIEWPOINT – HOW TO BUILD AMBIESENSE APPLICATIONS......................................39 5 INFORMATION STRUCTURES AND PROCESSING .................................................................43

5.1 INFORMATION STRUCTURE VIEWPOINTS ........................................................................................44 5.1.1 Context – proposed as a general information structure ........................................................44 5.1.2 Various types of contexts – determined by the actor/entity in focus ......................................45 5.1.3 User contexts – describes aspects of the user's situations .....................................................47 5.1.4 Tag contexts - automatically merged with user contexts .......................................................48


IST 2001- 34244

5.1.5 Context templates – made to guide the creation of contexts..................................................49 5.1.6 Context Space – a general repository for past, present, and future contexts.........................51 5.1.7 Context Tags – enabling ambient content services ................................................................52 5.1.8 Content items and info packages – meta-information about content.....................................53 5.1.9 Context-aware access to content via calendars.....................................................................56

5.2 INFORMATION PROCESSING VIEWPOINTS .......................................................................................58 5.2.1 Information retrieval in general ............................................................................................58 5.2.2 Using context in context-aware information retrieval ...........................................................60 5.2.3 Using context in personalised information retrieval .............................................................63 5.2.4 Acquiring and capturing contexts..........................................................................................65 5.2.5 Linking and matching of content and context ........................................................................66 5.2.6 Matching and retrieval of similar contexts ............................................................................68

5.3 DETAILED CLASS DESCRIPTIONS....................................................................................................68 6 APPENDIXES......................................................................................................................................91

6.1 CONTACT INFORMATION ................................................................................................................91 6.2 GLOSSARY......................................................................................................................................91 6.3 ABBREVIATIONS.............................................................................................................................96 6.4 EXAMPLE INFORMATION STRUCTURES FOR APPLICATIONS............................................................98

6.4.1 News/Events/Information Services ........................................................................................98 6.4.2 Context-aware airport services ...........................................................................................105 6.4.3 Travel-guide services...........................................................................................................112 6.4.4 Context-aware map service .................................................................................................118

6.5 REFERENCES.................................................................................................................................125 6.6 FIGURES .......................................................................................................................................127 6.7 TABLES ........................................................................................................................................129


IST 2001- 34244

1 Executive Summary The purpose of this document is to present the AmbieSense Reference Information Model. This report will be valuable as a reference for consortium partners, as a source of technical information for organisations or persons intending to implement an AmbieSense system, and as a source of inspiration for people with an interest in personalisation, ambient computing, or context-awareness. At an overall level, the following citation describes what AmbieSense is about:

“The purpose of AmbieSense is to provide personalised, context-sensitive information to the mobile user. An ambient information environment will be provided by a combination of context tag technology, a software platform to manage and deliver the information, and personal computing devices to which the information is served. This project aims to deliver information to the mobile citizen at the right time, place and situation. This information will largely be provided by specialist content providers associated with the project.”

[AmbieSense-D1] The report first defines the AmbieSense Reference Information Model. Then it describes the fundamental AmbieSense principles and goes into more detail of explaining the AmbieSense system by introducing the four core system concepts: content, context, context tags, and users including related functional aspects, i.e. personalisation, context-awareness, ambient-computing, etc. Next, the AmbieSense Reference Architecture and its system components are described in detail using multiple viewpoints. Lastly, the information model is presented using three viewpoints of descriptions – information structures, information processing, and detailed class descriptions.


IST 2001- 34244

2 Introduction to the AmbieSense Reference Information Model

This chapter defines the AmbieSense Reference Information Model. We first present the objectives and rationale for the model. Then we provide a model roadmap, explaining what is contained in the other chapters of the report. Lastly, we identify the intended audience and a list of related project documents.

2.1 DOCUMENT OBJECTIVES The main objective of the AmbieSense Reference Information Model (RIM) is to explain our recommended approach for building personalised, ambient, context-aware information systems for mobile users. Thus, through this document, typical software-houses should have adequate information in order to decide upon, design, and implement an AmbieSense system.

2.2 WHAT IS THE AMBIESENSE REFERENCE INFORMATION MODEL? The AmbieSense Reference Information Model is an exhaustive documentation of the AmbieSense system. The model explains the basic components of the AmbieSense system, their functional aspects, and how they interact. Further, it describes the information flow of the system and gives in depth descriptions of the information classes that are shared and used by most components. It is important to note that the AmbieSense Reference Information Model is not addressing a specific development environment. Rather, it may be implemented using any kind of programming language. Thus, two independently developed systems will not necessarily be able to communicate with each other, unless the developers have agreed upon the technical aspects of message interchange.

2.3 THE NEED FOR AN AMBIESENSE REFERENCE INFORMATION MODEL All that intend to implement an AmbieSense system must use the AmbieSense Reference Information Model. The model should present sufficient information for the readers to obtain a common understanding of the system, which e.g. is vital to perform a fully functional implementation of it. Other independent implementations will have the same semantics and support co-operation with limited efforts, since they are based on the same fundamental design elements, principles, and information structures. The reference model also gives useful information for people interested in building systems that address only some of the aspects personalisation, context-awareness, and ambient computing – but without following the full AmbieSense system architecture. For these people, the model can serve as background material, highlighting useful issues to consider and providing design principles.

2.4 HOW TO USE THE AMBIESENSE REFERENCE INFORMATION MODEL A reference information model addresses multiple reader groups. It gives the background knowledge required to support the decision process regarding whether or not to implement the described system approach. It also gives technical descriptions of how to actually build such a system. By following the reference information model different organisations can, possibly without prior knowledge of the system domain, more easily build working systems. The AmbieSense Reference Information Model describes a family of systems that will bring new opportunities for content delivery from content service providers to mobile users. It does not, however, contain implementation level details. Each organisation interested in building an AmbieSense system must perform a thorough analysis of the specific system environment. In addition, specific requirements pertaining to the desired system must be gathered and analysed to determine potential conflicts or other consequences for the system recommended by this Reference Information Model. Subsequently, these


IST 2001- 34244

conflicts and/or consequences must be taken into account when the concrete architecture and information model is designed. The concrete architecture and information model should then be input to the implementation process, wherein the concrete system is built.

2.5 DOCUMENT ROADMAP The AmbieSense Reference Information Model is divided into five chapters and a set of appendixes: Chapter 1 – Executive Summary. The chapter gives a very brief summary of the report and is useful for everybody. Chapter 2 – Introduction to the AmbieSense Reference Information Model. This chapter contains the objective and the rationale for the AmbieSense Reference Information Model. It is useful for anyone wanting to get an overview of the content of the document. Chapter 3 – Understanding AmbieSense. The third chapter explains the AmbieSense basic principles, i.e. the techniques and approaches that are used to construct the system. All users new to the AmbieSense approach should read this chapter. Chapter 4 – AmbieSense Reference Architecture. The fourth chapter presents the AmbieSense Reference Architecture. It is the project’s recommended set of architectural guidelines for building ambient, personalised, context-sensitive information systems for mobile users. The chapter explains the proposed architecture, its components and their functional aspects, and then presents some example configurations of the reference architecture to illustrate concrete implementations. Anyone intending to implement AmbieSense technologies should read the chapter. Chapter 5 – Information Structures and Processing. The fifth chapter’s main objective is to document the AmbieSense information model. The chapter is divided in three sections: information structures, information processes, and the detailed information classes. Developers intending to implement either all or parts of the AmbieSense system should read this chapter. Chapter 6 – Appendixes. The appendix chapter contains background and reference information such as a set of documented example applications, a glossary of important terms, and a list of abbreviations. In addition, the appendix contains contact information in case of any need for more information on the AmbieSense system, and lists of the references, figures, and tables found in this report.

2.6 AUDIENCE The AmbieSense Reference Information Model is written mainly for software-houses – i.e. system architects, designers, and developers. For this reason this document contains knowledge about architectures, information structures, and the information processing which we mean would be needed in order to build, understand, or support information systems that deal with personalisation, context-awareness, and ambient computing. Therefore, this document should also be of interest for the content service providers that often use software-houses in the development of the information systems while they focus on providing content.

2.7 RELATED PROJECT DOCUMENTS The following project documents provide some background and related information for the reader:

• D1 - Requirements and Overall system architecture report* • D3 - Context tag technology report* • D5 - User context middleware and report* • D6 - System architecture and information standards report


IST 2001- 34244

• D8 - Multi-agent framework, architecture report • D10 - User interface survey and design report

* Restricted report, see section 6.1 for contact information.


IST 2001- 34244

3 Understanding AmbieSense This chapter serves as an introduction to chapters 4 and 5. Its main objective is to give an understanding of the AmbieSense system. The AmbieSense system is complex because it encompasses many different user roles, components, and configurations. For example, for organisations intending to implement an AmbieSense system, it is vital to have a good understanding of the system. The key to this is the central system concepts, the functional aspects of its components, how the system will fit to existing infrastructure, and how it differs from other current approaches.

3.1 INTRODUCTION TO AMBIESENSE AmbieSense deals with ambient, personalised, and context-sensitive information systems for mobile users. The main overall goal of these systems is to realise the idea of a digital, ambient environment that make user’s information-related tasks easier by adapting to user’s context and personal requirements. The AmbieSense approach is illustrated in Figure 1 below:

Context tagsHolds contextual info about the current situation around it

Mobile/traveling users

Content service providers

Statue

Business lounge

Restaurant Shopping center

= Context tag mounted anywhere in order to help the mobile user get right information in the right situation

Wirelesscommunication

Personalisedinfo

Wireless

communication

Context tagsHolds contextual info about the current situation around it

Mobile/traveling users

Content service providers

Statue

Business lounge

Restaurant Shopping center

= Context tag mounted anywhere in order to help the mobile user get right information in the right situation

Wirelesscommunication

Personalisedinfo

Wireless

communication

Figure 1: The AmbieSense system presenting the value proposition

The figure illustrates how AmbieSense implements a new, digital information channel for mobile users. AmbieSense propose to implement and deploy new, digital information channels into the mobile user’s physical surroundings. The objective is to provide the correct information to the right situation of the mobile user. The figure depicts three central corner stones of the system: Content Service Providers (CSP), Context Tags and Mobile/travelling users. Information or content is provided by Content Service Providers, offering net-based, digital information services to their customers. This is currently achieved by direct communication between the information consumers (i.e. the mobile users) and the CSP. A key objective of Content Service Providers is to increase the value of their services by increasing the reach, relevance, and accuracy of information provided to the consumer.


IST 2001- 34244

AmbieSense propose to implement these channels using Context Tags – small and inexpensive yet generic computers that can relay content and context from the Content Service Provider to the mobile user – right into the user’s physical surroundings. The Context Tags have computing capabilities, which enable a range of innovative software applications. For example, such applications can exploit contextual information about the tag and the user in range to provide higher quality content services. Context Tags may vary from being cost optimised with little system logic simply fulfilling the task for the other components, to serve a diverse range of applications. Therefore, the tags may differ with respect to storage capacity, transmission technology (including type, frequency and range), Quality of Service (QoS), and security services. Mobile users are the consumers of information services provided by the system. We assume that they use some kind of mobile computer, e.g. a PDA or a smartphone to interact with these services. Just by being in a dynamic context – i.e. travelling - a certain additional mental load is put on the user. AmbieSense applications can reduce the impact of this load by exploiting contextual knowledge about the user that reduces the efforts necessary to obtain the desired information. Similarly, AmbieSense applications may indeed point the user to information he might not have obtained otherwise. A central idea is to associate information with objects in the surroundings, thus creating an environment that stimulates the user’s curiosity and encourages him to look for information in the surroundings. In summary, AmbieSense seeks to address the requirements of the Content Service Provider and the mobile/travelling users by improving the reach, accuracy and timeliness of content and context delivered to the mobile user. The next sections explain how AmbieSense achieves this.

3.1.1 Infrastructure, Framework and Applications

Innovations in AmbieSense build upon existing infrastructure. The innovations are made available in a framework that enables the development of advanced content provisioning applications. To ease the development, a set of four example applications from distinctly different domains is included. Figure 2 below illustrates the main infrastructure elements that are used as the basis for the framework and the example applications that build upon this framework.


IST 2001- 34244

Application (examples)Travel applicationNews applicationAirport applicationMap application

AmbieSense Framework (innovation elements)New digital information channelsContext aware IR and extractionContext MiddlewareContext tags

InfrastructureWireless communications: BT, WLAN, GPRS, 3G, Utra WiFiHandheld computers, PDA and smartphonesContent management infrastructure - OpenCMS, Central 2000Server technologies - App. Servers, Web ServicesPlatform independence technologies - Java, agentframeworksSearch engine technologies

Figure 2: AmbieSense innovation corner stones

Infrastructure: As is evident from Figure 2, AmbieSense includes a range of infrastructure technologies. These have been selected because they provide important, value-adding functionality to the framework. For example, ambient digital information channels are made possible through wireless communications and mobile users access their information while travelling using handheld computers. Content management systems, search engines and server-based utilities provide vital services to the AmbieSense Framework for the content service provision platform. AmbieSense Framework: The main innovation in AmbieSense is in the framework, i.e. the application foundation. New digital information channels are implemented by content providers and bring relevant information to the user. The context tags are the key vehicles for implementing these channels. Context-aware IR and extraction exploit context knowledge about the user to find the correct information for the user. The context middleware implements context management functionality as well as the storage and retrieval of contexts. Application examples: Four example applications, from distinctly different business domains, demonstrate how the AmbieSense Framework can be used.

3.1.2 Current Approaches

There have been identified some current approaches with similarities of the AmbieSense system. A majority of these are, however, location-based systems only although some are based on context tagging of information. In section 7.4.4 of [AmbieSense-D1] an overview of some other current approaches are given.


IST 2001- 34244

3.2 AMBIESENSE SYSTEM CONCEPTS The main objective of an AmbieSense system is to bring relevant information to the mobile user in the right situation. In other words, to increase the effectiveness of information systems by improving the relevance of the information provided. This chapter presents the AmbieSense core system concepts that help to support this objective. These core concepts will be present in any valid AmbieSense system. The next section will illustrate some functional aspects of AmbieSense based on the system concepts introduced in this chapter.

Content

Content is the information that flows through the AmbieSense system. From the user's point of view, content is any data that the user can download, either explicitly or (in respect of some settings) automatically (e.g. while the mobile computer is in contact with a legitimate access point such as a Context Tag or a Content Service Provider platform). Usually, content is temporarily stored in the form of audio, movie, image, text, or mark-up files before the user is able to perceive it. See sections 4.2.2, 4.3.7, 5.1.7, 5.1.8, and 5.3 for more information of this topic.

Context

Context can be defined as a description of the aspects of a situation. The period of a context can range from being a very short moment to many years. The current context can depend on several criteria, e.g. the location, mental state, etc. The user’s current context can have a direct influence on the behaviour of the user application (e.g. the application can present or choose not to present relevant information to the user based on the current context). One may speak of several types of contexts, depending on your application and your needs for info – and of your view of what info/data is important to capture/describe a situation. Context technology is a mechanism that can capture concepts and relationships between these concepts. We argue, however, that there should be some common structure for user contexts which is easy to reuse across domains (such as different applications). What makes domains differ is mainly that the relevance and importance of concepts within the context structure differ. Redundant items may exist in the context because their relevance can change over time. See sections 4.3.6, 5.1, 5.2.4, 5.2.5, and 5.3 for more information of this topic.

Users

The users are the consumers of content (and possibly context) that a Content Service Provider provides. A user is assumed to be carrying a mobile device with AmbieSense enabled software. Further, users are on the move and have a current context. A user will be able to receive information according to the current context. See section 4.2 and 5.3 for more information of this topic.

Context Tags

AmbieSense introduces a new concept called the Context Tag. The context tag is an entity that enables the binding of location to a context (or a set of contexts). The context tag is realised as an embedded computer with a Bluetooth interface for communication. The communication facility is used for the exchange of software, content and context. In its simplest form, a context tag only gives a reference to a location to be used by a mobile user. More advanced context tags will support other services. For example, a context tag can be used to gather and provide relevant information as well. If a context tag is equipped with sensors, it can know the temperature or the lighting conditions at the location in which it is mounted.


IST 2001- 34244

See sections 4.3.8, 4.4, 5.1.7, and 5.3 for more information of this topic.

3.3 AMBIESENSE FUNCTIONAL ASPECTS This chapter will give a slight overview and describe some of the functional aspects relevant for AmbieSense.

3.3.1 Personalisation of Content and Content Services

Generally, personalisation is about tailoring products and services to better fit the user. Its main goal is to improve the relationship with the customer. However, occasional visitors can be turned into regular customers. An example of personalisation can be found in the way cars are purchased nowadays. After selecting the car model, you can tailor it using extra equipment, colour, seat textiles and many other extras. In information technology, the same tendency can be discovered. Personalised web portals, for example, are more likely revisited than standard websites. Personalised information provision helps the user to cope with information overload. There are several ways of achieving this. The main methods are by focusing on the user needs, preferences, interests, expertise, workload, tasks etc. We advocate use of the user context as a means of capturing all these and using them as an information source for the personalisation process. Personalisation can be achieved by tailoring products and services to large user groups, smaller interest groups, or the individual user. AmbieSense is able to personalise for all these areas, but the main focus is on the individual users. We conjecture that providing high quality, personalised services for mobile users based upon user context is one way of achieving this. In order to do so a standardised way of understanding context (i.e. modelling/representing the context) is important in enabling this [MyrhaugGöker2002].

3.3.2 Using Context to Provide Relevant Information to the User

A mobile user’s primary task is not simply to use a PDA or smartphone. Initially, the mobile user might be inclined not to use the mobile computer while moving around. His main task is to deal with the environment and situations that he is facing. We assume that the dream of a user with a mobile computer is to proactively sense the current context, keep track of the evolution of the various contexts that the user is in, and to provide continuously relevant content based upon this. Content is often organised for a specific use. Mobile users challenge the information delivery process. The information that they need is associated with the current context and frequent context change will be the case for most users. This gives the content service provider the dilemma of whether to spending time on very small and targeted use or to focus on broader use. Spending time on the first case is probably not very cost effective compared to the latter one. AmbieSense makes the assumption that context technology can enable the content service provider to be more accurate in delivering content; one can achieve more satisfied mobile users. More information can be found in section 4.3.6.

3.3.3 Ambient Computing — Intelligent Surroundings?

Ambient computing denotes a computing paradigm that entails a computerised environment for the user. Essentially, it provides the user with surrounding, yet hidden computing services [Weiser]. The rationale is that the user should not be tied to a specific location in order to have access to the necessary information or services. Information should be available everywhere.


IST 2001- 34244

“Ubiquitous computing [a.k.a. ambient computing] is roughly the opposite of virtual reality. Where virtual reality puts people inside a computer-generated world, ubiquitous computing forces the computer to live out here in the world with people. Virtual reality is primarily a horse power problem; ubiquitous computing is a very difficult integration of human factors, computer science, engineering, and social sciences.”

[Weiser] A pre-requisite for ambient computing is wireless networking. Wireless networking allows users to move about freely while still having access to the computer network. The ambient computing paradigm extends the functionality of wireless networking by bridging the gap between technology, information and a mobile user. One of AmbieSense’ objectives is to be able to deliver context sensitive information to the user. This is done through context-aware applications running on the mobile computer, the context tag and the content service provision platform using wireless communications to reach the mobile user. Additional information can be found in chapter 3.1 of [AmbieSense-D1].

3.3.4 Context-Awareness

A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user's task1 and other context information as well [DeyAbowd1999]. Components that deliver computational services may be context-aware. For example, a mobile computer may exploit the user’s task context to better adapt the information provided to his current situation. Today a PDA does not take into account whether the mobile user is in a private or job related setting. The user has to decide which information can or cannot be shown to surrounding people. A context-aware PDA would enable information to be hidden at certain places. The AmbieSense system will provide the distribution of personalised information meeting the users’ needs in any given situation. Context-aware methods and techniques are central concepts in this. Context-aware services in AmbieSense respond to changes of context and retrieve the appropriate content items. The context tag plays an integral role in this. It is not only the link between the content and the mobile user, but also provides environmental information (that is, the tag context) that defines the current context, together with the user context. Detailed discussion can be found in sections 5.1 and 5.2.

3.3.5 Context-Aware Content Delivery

Context-aware content delivery can be the bridge between knowing the mobile user's current situation and delivering related content to that situation. It can be an ideal tool to deliver content in a useful and focused way for content providers. Fundamentally, the process can be defined as collecting evidence of a context, matching it with other contexts in the context space, and searching and integrating the content, which is to be delivered. This is how the linking between context and Content Items/Info Packages should be done in order to put content into context. Detailed discussion can be found in sections 5.1 and 5.2.

1 Task should be understood here as goal-directed activity.


IST 2001- 34244

4 AmbieSense Reference Architecture This chapter presents the AmbieSense Reference Architecture, i.e. the project’s recommended guideline for how to build ambient, personalised, and context-sensitive information systems for mobile users.

4.1 BACKGROUND This section explains the basic principles of reference architectures, justifications for using them and the approach used to document the AmbieSense Reference Architecture.

4.1.1 What is a reference architecture?

There are many definitions of reference architectures:

“A reference architecture is the generalized architecture of several end systems that share one or more common domains. The reference architecture defines the infrastructure common to the end systems and the interfaces of components that will be included in the end systems. The reference architecture is then instantiated to create a software architecture of a specific system. The definition of the reference architecture facilitates deriving and extending new software architectures for classes of systems. A reference architecture, therefore, plays a dual role with regard to specific target software architectures. First, it generalizes and extracts common functions and configurations. Second, it provides a base for instantiating target systems that use that common base more reliably and cost effectively.”

[W3]

[A reference architecture] “...is, in essence, a predefined architectural pattern, or set of patterns, possibly partially or completely instantiated, designed, and proven for use in particular business and technical contexts, together with supporting artefacts to enable their use. Often, these artefacts are harvested from previous projects.”

[Rational] “A reference architecture is a high-level system design free of implementation details and consists of the following elements: a) a high-level description of the system components; b) definitions of relationships between components, c) definitions of relationships between system components and elements external to the system and d) identification of performance drivers and capacity requirements.”

[Sunset] Although the above definitions take different views as to what should be part of a reference architecture, in summary, we can say that a reference architecture is a guideline for the design of architectures within a domain, i.e. it is a recommendation for how to build a particular kind of system. Thus, a reference architecture is the architecture of a set of architectures. The AmbieSense Reference Architecture, documented here, is a blueprint for the construction of architectures that implement the AmbieSense vision, Ambient, personalised, and context-sensitive information systems for mobile users.

4.1.2 Rationale

The main rationale for an AmbieSense Reference Architecture is to support solution builders in implementing the techniques, models, and principles proposed in this Reference Information Model. Many aspects have been considered when designing the Reference Architecture. This chapter accounts for the most significant architectural drivers:

1. Functional user requirements


IST 2001- 34244

2. Distribution 3. Component-based development 4. Alignment with legacy systems and existing information value chains 5. Non-functional quality requirements (cost, complexity, security, privacy, availability,

configurability) Additional requirements will naturally be identified when the reference architecture is implemented for concrete solutions. These requirements may be in any of the categories above, and must be carefully analysed in order to determine the necessary adaptations of the reference architecture.

4.1.3 Documentation Approach

There are no established methods for documenting reference architectures specifically. As such, any software architecture documentation method can be used. However, reference architectures are more open (under specified) than software architectures and are thus not concerned with all the details. The AmbieSense Reference Architecture is documented using principles from the RM-ODP (Reference Model - Open Distributed Processing) method [ISO 10746-1]. This method was selected mainly because it is an established standard and because it comes with five predefined viewpoints (enterprise, information, computational, engineering, and technological viewpoints respectively) that help to visualise the range of different aspects that needs to be documented in an architecture. In the reference architecture described here, we focus on only the first four of these viewpoints from the RM-ODP standard:

1. Enterprise viewpoint – focusing on the overall functionality of the system towards its users and stakeholders, described in terms of user roles and actors. The enterprise viewpoint is documented using use-cases and task models for the various user roles.

2. Information viewpoint – focusing on the semantics of information stored and processed by the system. The information viewpoint is documented in section 5.1, using information structures, information process descriptions, and detailed class descriptions.

3. Computational viewpoint – focusing on the high-level component descriptions and interactions between these components. The computational viewpoint is documented using diagrams showing the functional decomposition into components and their interfaces.

4. Engineering viewpoint – focusing on how the concrete configurations of the reference architecture can be deployed to real systems. The engineering viewpoint is documented using deployment diagrams showing communication and distribution aspects of system components. It also addresses performance and capacity issues by suggesting how these quality requirements can be satisfied by the different configurations.

The technological viewpoint as specified by RM-ODP is not addressed. As this is a reference architecture, intended to be platform and implementation neutral, such technological aspects should be addressed at the time of derivation of a specific system when detailed technological requirements become available. Although we do present some implementation specific details in the Reference Architecture, this is done for illustrative purposes only. Additionally, RM-ODP is specifically targeted at open distributed systems, i.e. systems with key requirements for distribution, interworking, and portability. These are key requirements in AmbieSense as well, further strengthening RM-ODP as a good candidate. Unified Modelling Language (UML) based notations have been used when applicable, for example to describe use-cases and functional decomposition into components with interfaces [OMG]. A slightly less detailed notation than UML’s deployment diagrams have been used to illustrate deployment configurations in the engineering viewpoint (section 4.4) in order to better convey the principles of configurability of the components in the Reference Architecture.


IST 2001- 34244

4.2 ENTERPRISE VIEWPOINT – USERS, ROLES AND FUNCTIONALITY This section documents the enterprise viewpoint of the AmbieSense Reference Architecture. It is concerned with the purpose, scope, and policies of the enterprise related to the specified system or service. The enterprise viewpoint addresses the services the system shall provide and the interaction with those services. In short, what the system is supposed to do for its users and stakeholders.

The AmbieSense Reference Architecture is service-oriented, i.e. it provides a set of services to the applications being built on top of it and to users interacting with framework concepts. The enterprise viewpoint is documented using use-cases and task models for high-level system concepts (system concepts are further documented in chapter 5).

4.2.1 Users, Roles and Actors

This section provides a brief overview over the most important roles played by users of the AmbieSense system. The roles are defined by a set of tasks performed by users/actors adhering to that role. We assume that some users/actors might adhere to multiple roles, so it is useful to think in terms of roles.

Context tag ownerOwns the context tag, can hire administrationContext tag administrator Updates the context tag data (the description of the context, ,content or applications)

The network owner, the network provider, the access service providerOwns the network the user accesses at the momentProvides access to the network

Statue

Business loungeRestaurant

Shopping center

Wireless and wired

Communication

Content authorsDevelop and maintain contentNeeds to tag info to relevant situations

Content providersProvides content to the owners

The mobile userTraveling aroundIndoor and outdoorIndividuals and groups

Content ownersOwn the content that the authors/ providers make

The building-/ area ownersContracts with network owners and access service providersHave specific norms and constraints for system use and visitors

AuthoritiesDefines and follow up laws and constraints

Content service providers/ software application providersProvides content/ applications directly to the userTrust brokers

Maintains the trust between the various roles and actors

Context tag ownerOwns the context tag, can hire administrationContext tag administrator Updates the context tag data (the description of the context, ,content or applications)

The network owner, the network provider, the access service providerOwns the network the user accesses at the momentProvides access to the network

Statue


Shopping center

Statue


Statue


Shopping center

Wireless and wired

Communication

Content authorsDevelop and maintain contentNeeds to tag info to relevant situations

Content providersProvides content to the owners

The mobile userTraveling aroundIndoor and outdoorIndividuals and groups

Content ownersOwn the content that the authors/ providers make

The building-/ area ownersContracts with network owners and access service providersHave specific norms and constraints for system use and visitors

AuthoritiesDefines and follow up laws and constraints

Content service providers/ software application providersProvides content/ applications directly to the userTrust brokers

Maintains the trust between the various roles and actors

Figure 3: Users, actors and roles

The picture above (Figure 3) depicts the interactions between the roles in the system. The Mobile User purchases the right to use an information service from some Content Service Provider (the act of purchase need not necessarily be subject to money payment, but perhaps agreeing to copyright or licensing agreements). The information is provided through business collaborations between Content Authors, Content Providers and Content Owners. Content Service Providers working together with software application providers prepare, aggregate, quality assure, and make the content available for users. As the name suggests, a Context Tag Administrator is responsible for the running of a (set of) Context Tag(s). A Context Tag may hold local content, so part of the responsibility of the Context Tag


IST 2001- 34244

Administrator is to upload and manage Content to be distributed directly by the Context Tag. In other cases, the Context Tag will simply refer to the relevant information on the World Wide Web, thus simply acting as a forwarder for the Mobile User. When the Mobile User is in the vicinity of a context tag, he/she might be able to retrieve Content. Subject to access rights and any active payment models, the Mobile User can access a wide range of information services through the Context Tag. If the Context Tag does not itself hold the Content, the Mobile User will download the Content from the World Wide Web. Additionally, the figure illustrates a number of auxiliary actors/roles that must be dealt with during a concrete implementation of the system. Authorities, trust brokers, building/area owners, network owners, network providers and access service providers are likely to have at least some importance. However, they do not have any significant importance in terms of the reference architecture described herein. It is important to note that one actor (organisation or person) can obtain more than one role: a restaurant owner publishing his menu on the Context Tag installed at his premises will probably be the Content Owner as well as the Content Author. When uploading the menu to the tag, he/she obtains the role of the Context Tag Administrator. The table below summarise the roles identified in AmbieSense and the central use-cases2 they participate in.

Role Description Use-Cases Mobile User “End user” of the AmbieSense system.

Interacts with information services on her mobile computer while being on the move.

• Retrieve, browse and edit information on mobile computer

• Maintain personal interests • Maintain contexts

Context Tag Administrator (CTA)

Technical administrator of one or more Context Tags

• Build and maintain CT infrastructure

• Update CT content • Maintain CT context space • Administer CT access rights • Administer CT software

Content Author Author of content items • Produce content items

Content Service Provider (CSP)

Person or organisation offering a coherent set of information services

• Aggregate content from content providers

• Implement quality assurance of content

• Transmit content to appropriate Context Tag Administrators

• Define and maintain context templates

• Define and specify Information Zones

• Implement and maintain payment models

Table 1: Roles and use-cases in the AmbieSense system

2 The use-cases highlight the user’s interaction with the system. They are normally developed from scenarios, but does not include environmental information that is not directly relevant for the interaction or tasks performed.


IST 2001- 34244

Administration. Context Tag Administrators and Content Service Providers are regarded as privileged users on their respective platforms. In contrast to normal (Mobile) users, they have access to management software that enables management of the Context Tag and the content provision platform. This software enables them to add new Content, remove Content and to maintain payment models for the Content. Additionally, there are system level tasks, such as monitoring the system, fault-diagnosis and simple repairs that may be performed through the same interface. Presumably, within certain organisations of some size, monitoring, fault-diagnosis and repairs will be performed by dedicated personnel (but using the same interface). Further, Context Tags may be administered from remote locations if it is connected to a network3.

4.2.2 Use-cases and task models

The following three subsections presents use cases and tasks for the users:

• Mobile users • Context tag administrators • Content service providers

The use-case models illustrate at a high level the services a user is offered by the system. Essentially, they capture what a user is expected to use the system for. From the high-level use-cases, we can extract key concepts that the system should implement. These might be concrete services or information objects. The concepts are later captured in the information structures. At last, when we consider the use-cases together with the extracted concepts we can start identifying what the user’s operations on a particular concept will be. These become the tasks that the system supports for each concept.

Mobile User

The circle of use-cases describes actions that are taken care of by the AmbieSense system at a generic level. The ‘core’ of the system supports this. The use-cases can be described or exemplified as shown in Figure 4.

3 As will be explained in the engineering viewpoint section, section 4.4, context tags may be used independently of any backbone network to CSP. In this case, all processing occurs on the context tag, and all content is stored on the context tag.


IST 2001- 34244

User authentication

Context-awareinformation retrieval

Share content,context, user context

Subscribe tocontent services

Download content fromcontent service provider

Mark and annotateinteresting info packages

Use contextmanagement service

Mobile user

Use and maintainuser modes

Set personalinterest options

Figure 4: Use case for the Mobile User

• Context-aware information retrieval: What to retrieve in different modes. The user has several

modes available, and what kind of information the user would like to get depends on his mode. (Leisure, business etc). This is matching the current context with the situation templates.

• Use context management service: Create, maintain, and manage user contexts. • Share content, context, and user context: All content and contexts of the user can be shared with

other users, provided the user allows this, and sets the appropriate access rights. The access rights can be set at different levels and can be withdrawn.

• Mark and annotate interesting Info Packages: When the user selects some information packages as interesting, this can be utilised by agents to update the user interest profile.

• Download content from content service provider: This can cost money or not. The payment model is in itself not to be a part of the AmbieSense project prototypes, but will be modelled in the rest of the project.

• Subscribe to content services: This could for instance be subscribing to updates from particular content providers.

• User authentication: The mobile user may need to log in and out of the AmbieSense system (depending on the application in use, some applications may be freely available). Some services also require an identification of the mobile user in order to allow downloads. An example is hotel room specific information downloaded from the hotel lobby.

• Use and maintain user modes: Includes switching between different modes, as well as editing the direct preferences of the modes (included in the user’s context information structure).

• Set personal interest options: Set and edit (and remove) personal interests.

THE MOST RELEVANT DOMAIN CONCEPTS ARE


IST 2001- 34244

• User context • Personal calendar • Content • Context tag • Info Package

TASKS FOR THE MOBILE USER Tasks for user context:

• New context • Edit context • Delete context • Merge contexts • Match contexts

Tasks for Personal calendar:

• View day • New activity • View activity • Edit activity • Delete activity

Tasks for Content:

• Search for content • View content • Set access rights for content • Download content

Tasks for Context tag:

• Accept/ignore context tag Tasks for Info Package:

• Browse Info Packages • View Info Package • Search for Info Packages • Delete Info Package • Rate Info Package

OTHER IMPORTANT CONCERNS Usability. We assume that usability is the most important non-functional aspect of the system for the Mobile User. Therefore, the reference architecture is structured to allow for different software configurations of the mobile computer, thus enabling both web-based and rich-client GUIs. The configurations are discussed further in the engineering viewpoint, see section 4.4. Security. Mobile Users also have considerable interest in the system’s ability to maintain security and privacy of information. Personal information, such as user context, should be protected by access right policies and encrypted in case of security attacks. Security of context is addressed in section 4.3.6.

Context Tag Administrator

The context tag administrator’s overall activities are illustrated in the use-case diagram (Figure 5) below:


IST 2001- 34244

Context tag administrator

Maintain content(info packages) on tags

Search for contenton tag

Maintain contextsfor each context tag

Link informationto contexts

Administrate groupsof context tags

Develop zones forcontext tags

Handle software andagents for the tag

Figure 5: Use case for the Context Tag Administrator

• Administrate groups of context tags: It should be possible to maintain multiple context tags

simultaneously, e.g. update a set of context tags with the same content. • Maintain contexts for each context tag: The administrator has the full rights to control when

different contexts on the context tag is activated (and may thus control what information is most relevant for the users in the vicinity of the tag). An example is the museum manager that may want to activate a new set of contexts on the tags when a new exhibition is initiated.

• Link information to contexts: The administrator also has the capability to link information/content to the contexts existing on her own tag. Subsequently, if matches between a user’s context and the context on the tag, a certain control are gained as to what information is provided to the user.

• Maintain content (Info Packages) on tags: The administrator is in charge of administrating the adding, removing, and updating of content and Info Packages on the tag. This could be done on a single tag at a time or a group of tags simultaneously. The CTA will normally receive the content from the Content Service Provider.

• Handle software and agents for the tag: The tags may run software, e.g. applications or agents, in order to complement the full solution. The CTA has the privileges to maintain these on the tags for which he has the CTA role.

• Develop zones for context tags: The administrator can define associations between tags to form group of tags. Such tag groups can implement Information Zones. For example, all tags in a museum or shop. He can define a connection between the tags unique ID and the zone.

THE MOST RELEVANT DOMAIN CONCEPTS ARE • User context • Tag context • Context template • Context tag calendar • Info Package


IST 2001- 34244

• User and user group • Context tag • Information zones • Content

TASKS FOR THE CONTEXT TAG ADMINISTRATOR Possible tasks for user contexts:

• New mode • Select mode • Delete mode • Accept/ignore context change

Possible tasks for tag contexts:

• New context • Edit context • Delete context • Merge contexts • Match contexts

Possible tasks for context template:

• View • Browse • Possible tasks for contexts trigger • Browse context triggers • View context trigger • New context trigger • Delete context trigger

Possible tasks for tag calendar:

• View day • New activity • View activity • Edit activity • Delete activity

Possible tasks for content template:

• View content template • Browse content templates

Possible tasks for users and user groups:

• New user • Edit user • Delete user • Discharge user • New user group • Add user in user group • Remove user from user group

Possible tasks for context tag:

• Turn on/off system • Local/Remote Logon • Install/uninstall software


IST 2001- 34244

• Link software to user • Link software to user group

Possible tasks for context tag groups:

• Group context tags • Ungroup Context tags • Install/uninstall software

Possible tasks for content/Info Packages:

• View content • Upload content • Edit content

OTHER IMPORTANT CONCERNS Price/cost. Naturally, when considering scenarios where a large number of Context Tags are deployed in the surroundings, the cost of each tag becomes critical for the acceptance of the technology. AmbieSense proposes a Context Tag Family, a range of Context Tags, to support the various needs that technical solutions might enforce (see the project report [AmbieSense-D3], discussed in section 0). Robustness. For the Context Tag Administrator it is important that tags are robust and require only a minimum of management effort to keep them available. This requirement is partly addressed by using commodity components and established reference designs for the Context Tags (see also [AmbieSense-D3]). This requirement is also addressed by using a layered software architecture that clearly separates the functional capabilities of the context tag (see computational viewpoint discussion, section 4.3).

Content Service Provider

This depicts the three main actors involved in creation and administration of content. They communicate with each other. The three actors are describes in further detail in section 6.1 of [AmbieSense-D1].

Provide content tothe mobile users

Content service provider

Specify contentbehavoiur

Activate and usepayment models

Develop andadministrate context templates

Develop andadministrate content/ info

packages

Content provider Content author

Link content tocontext

Develop andadministrate contexts

Use contentmanagement system

Figure 6: Use case for Content Service Provider (and content provision roles)


IST 2001- 34244

• Develop and administrate context templates: Context templates describe the ‘common’ behaviour of a user within that specific area. An example could be on an airport, where arriving via train is distinctly different from arriving via plane with respect to the information needed. The template building is based on knowledge gained from domain experts on how people act in different setting.

• Develop and administrate contexts: The different contexts are in turn administered and developed. E.g., students that prepares the different session contexts before a conference. All sessions are of the same template, namely sessions, but the content varies to some degree depending on speakers and so on.

• Link content to context: The different pieces of content must be linked to the contexts that are to exist in the tags area.

• Use content management system: The development and administration of content and linking is done via the content management system. This serves as a means of communication between the different parts of the provision process (authors and providers and service providers).

• Activate and use payment models: Although payment is not to be an issue in our prototypes, supporting a payment model in theory is good. The easiest payment is of course that the content is free, but other options are pay per item, package etc.

• Specify content behaviour: The content might be specified as read only, with a limited life span, a number of viewing times etc. This is extra information on the content that the content service provision (or context tag administrator) takes care of.

• Provide content to the mobile users: Make sure that the content and context is moved to a place where mobile users can find it.

• Develop and administrate content/Info Packages: AmbieSense users involved in the content service provision will have content, and if necessary create information packages from it. These are in turn provided to the context tag administrator for implementation on the tag. The content and packages are adhering to the other use cases in this diagram.

THE MOST RELEVANT DOMAIN CONCEPTS ARE • User context • Context template • Info Package • Content • User and user groups • Context tag

TASKS FOR THE CONTENT SERVICE PROVIDER Possible tasks for user context:

• New mode • Select mode • Delete mode

Possible tasks for context template:

• New context template • Insert/remove contexts types • Add/delete attribute • Add/delete attribute values • Delete context template

Possible tasks for context trigger:

• Browse context triggers • View context trigger


IST 2001- 34244

• New context trigger • Choose condition/state • Choose event

Possible tasks for Info Package:

• New Info Package • Edit Info Package • Browse Info Packages • Link to contexts

Possible tasks for content templates:

• New content template • Edit content template • Delete content template • Add/delete attribute • Add/delete attribute values

Possible tasks for content:

• New content • Edit content • Delete content • Search for content • Link to contexts

Possible tasks for users and user groups:

• New user • Edit user • Delete user • New user group • Add user in user group

Possible tasks for context tag:

• Edit Settings • Edit content • Delete content

OTHER IMPORTANT CONCERNS Content Service Providers have a large number of (potentially very different) concerns. Therefore, for a given technical solutions, the derived architecture will need to address these. However, during the design of the Reference Architecture, we have identified some concerns that are quite generic: A framework that simplifies the development of new solutions. The main motive for a Content Service Provider to use a framework such as the one included in the AmbieSense Reference Architecture, is to enable the development of new and attractive solutions for content delivery. Thus, the framework must be adaptable to a wide range of technical solution scenarios. This concern is discussed further in section 4.4. Minimal service disruptions. Firstly, it is critical that any new system that interacts or affects their information value chain does not assume disruption to currently running systems. Minimal requirements to changes in existing content. It is important that the system does not enforce major restructuring of existing content. Rather, it should be possible to reuse existing content, while adding value to it using the new system. The concern is addressed in section 4.3.7.


IST 2001- 34244

Ability to maintain full control over content rendering. A Content Service Provider has great interest in the system’s ability to give him full control of the content’s appearance on the Mobile Computer. These concerns are addressed by the Content Provision Platform, discussed in section 4.3.7.

4.2.3 Summary

The enterprise viewpoint documented here has explained the key overall requirements to the AmbieSense Reference Architecture. These requirements are now further developed in two different parts of this document. The use-cases and task models presented are the foundation for the Information Model presented in chapter 5. Thus, the domain concepts and tasks described in the enterprise viewpoint are refined to information viewpoints, information processes, and class descriptions. In parallel, the system centric requirements set forth by the enterprise viewpoint are used as foundation for the technical reference architecture described in the following two sections, section 4.3 and section 4.4.

4.3 COMPUTATIONAL VIEWPOINT – AMBIESENSE FUNCTIONAL COMPONENTS This section documents the computational viewpoint of the AmbieSense Reference Architecture. The computational viewpoint is concerned with the functional decomposition of the system into components and the interaction patterns between the components (services) of the system, described through their interfaces. A good understanding the functional decomposition enables more flexible reuse of functional components across different applications. Overview. The AmbieSense Reference Architecture consists of a set of main components, described below following a top-down sequence. The components are also described in further detail in sections 4.3.1 to 4.3.9. Section 4.3.10 discusses some key interaction patterns between the components. Figure 7 below, illustrates how layering the main organising architecture pattern is used. The light grey components are part of the AmbieSense Framework; the darker grey components are part of each application/solution developed on top of the framework. By layering, we assume that components form a stack that prescribes how components interact with each other. For example, in Figure 7 User Interface is illustrated on top of Applications and Agents. This implies that the User Interface uses the services offered by Applications and Agents. Likewise, Applications and Agents use the services from the Push and Pull components. Normally, layering would prohibit the User Interface to use services from the Push and Pull components directly. This is not enforced by the AmbieSense Reference Architecture. In some technical solutions, one or more of the indicated layers may not be present, thus it is necessary to allow interaction between non-adjacent layers. However, if the layer is present, then the layering principle should be adhered to.


IST 2001- 34244

Figure 7: Functional decomposition

• User Interface. The User Interface is the GUI that implements the user’s interaction with the

application on the machine. The GUI is designed based upon the requirements for the particular application, and therefore the GUI, the application and eventual agents are developed together. However, the user interface uses the services offered by the application and agent components developed.

• Applications and agents. Applications and Agents4 are developed according to the needs of each specific solution. Developers may choose whether to exploit agents to complete the solution. Applications (and agents) use the services of the layers below, primarily the push and pull services, but also from the Context Middleware and CIP when appropriate. In section 6.4, some example applications are presented that gives concrete examples of the usage of the AmbieSense Framework.

• The Push and pull components implements functionality for content distribution, supporting the two different principles push and pull. The Push and Pull components uses the context management functionality of the Context Middleware together with the content provisioning capabilities of the CIP to implement content distribution.

• Context Middleware. The Context Middleware is responsible for context management (storage, retrieval, and matching functions). The Context Middleware uses services from the CIP in order to perform certain functions, such as linking context with content and low-level context-content matching.

• CIP. The CIP (Content Integration Platform) is a complex service component that deals with content management, integration, and adds functionality for personalisation and customisation – all within an integrated platform. The CIP provides a single interface to the heterogeneous content

4 In multi-agent systems, agents are programs that act in a self-interested manner in their dealings with numerous other agents inside a computer. This arrangement can mimic almost any interactive system: a stock market; a habitat; even a business supply-chain.


IST 2001- 34244

databases underneath, while adding useful functionality for caching, personalisation, and content management in an integrated environment.

In addition to the above, networking and proximity services are supported by the following functional components:

• Network Services. Because AmbieSense is inherently distributed, networking capabilities are used between the platforms (i.e. Mobile Computer, Context Tag, and Content Service Provision platform). Networking capabilities are provided by industry standard technologies, such as Bluetooth, WLAN, 3G, and GPRS.

• Proximity Detection. In addition, a subcomponent called Proximity Detection will enable detection of Mobile Computers in the vicinity of the Context Tag (Section 4.4 - Engineering Viewpoint – explains how the component is utilised in concrete implementations of the reference architecture).

Below, each of the functional components will be described in terms of their main functions and the interfaces they expose to other components in the reference architecture.

4.3.1 User interaction (User Interface)

A User Interface enables the user to interact with an application. Interaction with applications occurs in three different ways, a) application management, b) notification of the user, and c) through prompting. A) must be implemented as a component outside the applications; b) and c) must be implemented by the applications. The three different categories are presented separately in the three following subsections. For clarity, the interfaces exposed by the User Interface component are illustrated in Figure 8 below.

Figure 8: User Interface Component interfaces

Application management interface

This interface is to be used if AmbieSense is to provide a mechanism for choosing among a set of different applications. If used, it is implemented by the application component’s Management interface (refer to section 4.3.2).

Notification interface

Two interfaces are used for notification of changes that the User Interface should react upon, ContextChangeListener and ContentChangeListener. These interfaces are to be used by other parts of the AmbieSense system to notify the prototype applications about changes in context or content data. A prototype application will typically implement both interfaces, but as it is different types of information involved, they are kept separated.

Prompting interface

Often, events in other parts of the technical solution should be brought to the user’s attention. This interface is to be used to prompt the user about issues that requires explicit user feedback.


IST 2001- 34244

4.3.2 Applications

Applications in the AmbieSense Reference Architecture are developed to implement the business logic required to serve the needs of a technical solution. The AmbieSense Reference Architecture prescribes only a single interface for applications. In order for applications to be manageable, i.e. started and stopped from the User Interface, the application components must implement the Management interface.

Figure 9: Application component interface

Apart from this interface, it has been a design goal to minimize restrictions towards the way applications are built. The main goal is to provide interfaces from other framework components that the applications can use. Applications may be extensive however. For example, a natural functional aspect of applications is to implement the integration with other external systems on the platform, for example a user’s personal calendar on the Mobile Computer (see also discussion about the context-aware calendar, see discussion of Activity in section 5.3).

4.3.3 Agents

In the AmbieSense Reference Architecture, agents are used by applications in order to accomplish a range of complex tasks. Agents can be defined as self-contained, autonomous pieces of software. Agent theory comes from many different fields of research: from the theories of human agents, economics, AI, etc.

Levels of Agent Intelligence

Agents come in many different versions, from the purely reactive to very deliberate. The simplest agents are small entities that have fixed responses to specific input. As opposed to the stimulus-response type of agents, the intelligent agents are agents that somehow reason about the tasks, which they are supposed to do. Within AmbieSense, part of the motivation for using agent systems is based upon non-functional requirements and lies in the fact that the complexity of the interaction of the system's users with their environment, including the sheer diversity of usage domains and contexts, require a modular, component-based approach. Various devices for system interaction at rather diverse places posing context sensitive requests to a distributed system made the choice of technology easy. Only Multi-Agent System (MAS) approaches are capable of delivering the flexibility, which is needed in such a case. Additionally, the non-functional requirements specified for the AmbieSense system, including the requirement to scalability and extendibility into new domains with new users and new contexts, made obvious the need for a MAS-like solution.

The AmbieSense Multi-Agent System – An Infrastructure for the Distribution of Relevant Information

Agent-based technology has proven useful in Information Retrieval (IR) and recommender systems, especially in settings that require distributed computing. AmbieSense exploits the advantages of state-of-the-art multi-agent systems, by providing a platform-independent infrastructure for detecting and maintaining user contexts and delivery of information that suits the needs of users in their specific contexts.


IST 2001- 34244

The AmbieSense Multi-Agent System (A-MAS) uses JADE/LEAP5, an existing multi-agent framework, for the protocol and communication. The agents implemented within the JADE/LEAP framework provide the generic core functionality for handling user contexts and triggering content queries. The JADE/LEAP platform was chosen as a result of a state-of-the-art survey and evaluation process of agent programming. On top of the JADE/LEAP framework, the A-MAS integrates with intelligent components for context-based content retrieval. The components comprise state-of the-art technologies such as case-based reasoning for situation recognition, IR, and personalisation modules as well as semantic web technology for content classification. As Figure 10 shows, the infrastructure imposed by the A-MAS consists of three main layers:

• Core technology agents that constitute the core of the architecture. There are agents for context handling, recommender agents, search agents, personalisation agents, content agents, and user interface agents.

• Enabling technologies that provide “intelligence” for the core technology agents. This includes technologies for content, context and user management, information extraction and retrieval, as well as reasoning engines. The open architecture of the A-MAS allows for plugging in various systems for handling these tasks. For the AmbieSense project, the following technologies will be used: the AmbieSense Context Middleware, a Case-Based Reasoning (CBR) engine for situation recognition (Creek), intelligent CORPORUM agents (OntoSense), a personalisation module as well as the AmbieSense Content Base. Chapter 5 will provide further information on these.

• Surrounding Components like User Interfaces on the end-user clients, content repositories, or enterprise systems (e.g. SAP). Content may be accessed through the AmbieSense Content Base (discussed in section 4.3.7) or other components of the AmbieSense Content Integration Platform6.

The AmbieSense Multi-Agent System combines the agent-based computing paradigm and state-of-the-art technology in order to create a flexible infrastructure that can be re-used by any context-aware information system.

Agent types in the A-MAS

There are six agent categories, derived from the JADE/LEAP framework and thus benefit from that infrastructure7:

• Integration Agents are a kind of wrapper that provides interaction capabilities between the A-MAS and external components (non-AmbieSense).

• Content Agents provide low-level content dependent functionality by interfacing directly with CIP and the underlying content providers.

• Search Agents receives an information request from the Context Agent in the form of a user context. The Search Agent will forward this context to Content Agents and Integration Agents that will convert the context to a proprietary query fit for the respective IR and content modules. The Search Agent keeps track of the available search types/modules and will always forward the context to each of these modules.

• GUI Agents. Interacts directly with the User Interface, helping to adapt and inform the user of important events.

• Context Agents are the principal agent of the A-MAS. It interacts with the Context Middleware and administers the access to the user’s context space while ensuring privacy and security. The Context Agent updates and maintains the user context and triggers the queries for content conducted by the Search Agent. Furthermore, it informs the Interface Agent about available content.

5 [Bellifemine 2000], http://jade.cselt.it 6 A complete account of the Content Integration Platform will be provided in the AmbieSense deliverable No.6. 7 JADE/LEAP is compliant to FIPA, Foundation for Intelligent Physical Agents (http://www.fipa.org)


IST 2001- 34244

• Recommender Agents uses contextual information and employs reasoning techniques like e.g. case-based reasoning for an analysis of the users’ situation in order to provide appropriate content.

The six A-MAS agent categories in turn use services from other components, such as the push / pull, CIP, and Context Middleware. Additionally, Agent specific system components, such as Creek and OntoSense may be used by the Recommender Agent. The engineering viewpoint (presented in section 4.4) illustrates how these components may be deployed to the different platforms. The A-MAS agents however, reside only on the Mobile Computer or on the Context Tag in order to ensure quick and secure processing of the user’s context.

Agent interfaces

One major difference between agent-based technology and traditional component-based programming is that agents are usually not invoked or controlled by other components. Instead, they are parts of complex agent behaviours that agents “choose” to execute in order to achieve a state in the given environment that corresponds with a goal-state of the agent.

Figure 10: Agents interface

Thus, interfaces of the AmbieSense Multi-Agent System are restricted to the instantiation of JADE/LEAP containers with either context agents (Mobile Device, Context Tag) or Integration Agents (Content Service Provision).

4.3.4 Content distribution (Pull)

Content distribution using the pull principle can most easily be described as procedure calls, i.e. the requestor sends a request for information to the provider, and subsequently waits until it is retrieved. In a distributed setting, it is comparable to client/server operation, the client sends a request to the server, and waits until the result is passed back. Content is referenced by URIs, and the basic unit of content retrieved is Info Package or Content Item (defined in sections 5.3). Both are retrieved using the standard Internet protocols HTTP or HTTPS (for technical solutions that demand higher security). Thus, the Pull component can be regarded as a server that responds to HTTP-encoded requests for URIs. A concrete example of this is a Web Server. Figure 11 below illustrates how the Pull component exposes these two interfaces.

Figure 11: Pull component interface

Pull interface

The Pull interfaces implements the HTTP and HTTPS protocols according to the current standards. The Pull component is free to implement the interfaces in the way that seems appropriate for the technical solution. For example, it might very well exploit the Caching interface of the CIP in order to increase performance of content retrieval (described in section 4.3.7).


IST 2001- 34244

4.3.5 Content distribution (Push)

In systems implementing content distribution following the push principle, content providers offer publications that content consumers (i.e. Mobile Users) can subscribe to. Whenever new content that match a subscription becomes available, it is transmitted to the consumer at the first possible time (for example when a connection is established between the Context Tag and the Mobile Computer).

Figure 12: Push component interface

The push framework component deals with distributing content to the mobile user. The component is continuously running, trying to find information that matches the criteria for each subscribing user. A promise of push technology within the AmbieSense Reference Architecture is that Mobile Users can get updated information more quickly, because the component server is always looking for relevant information. Furthermore, by exploiting multicasting capabilities in the networking infrastructure, a more scalable information distribution model is achieved.

Publications interface

The publications interface includes functionality for managing publications, i.e. logical grouping of content belonging to particular topics or categories. Management of these publications involves creating, editing, activating, deactivating, and deleting publications.

Subscriptions interface

The subscriptions interface contains functionality that allows Mobile Users to indicate an interest in a particular kind of content by subscribing to available publications (discussed above).

Distribution Management interface

The distribution management interface contains functions to manage the policies used to distribute content to the subscribers. Such policies can for example control the frequency of updating information, preferences w.r.t. limitations on the size of content to be distributed on given network technologies. Further, it should adhere to implemented payment models (see section 4.2, 5.3, and [AmbieSense-D1] for further details).

4.3.6 Context management (Context Middleware)

The main objective of the context middleware is to hide the possible intricacies of context management tasks by implementing a common, secure way of retrieving, manipulating and storing context. This allows application developers to work on a higher level of abstraction and focus at the important task at hand, developing higher quality services to the end users within their application domain. The Context Middleware offers the abstraction of a Context Space as the main concept of context interaction. Both application components and software agents may benefit from the use of Context Spaces. Typical application/agent tasks may be to update current context with contextual information that has been gathered from external sources (sensors, other agents, the user etc.). The security requirements mentioned above are fulfilled by maintaining user preferences like privacy classes or content/ context sharing access rights. The mobile user controls these security settings. They are


IST 2001- 34244

stored, updated, and handled in the user’s Context Space that consists of the contexts, content links, and access rights. The context middleware exposes a rich set of functionality through its interfaces. For in-depth presentation of the Context Middleware, see the project report [AmbieSense-D5].

Figure 13: Context Middleware interfaces

XML Interface

This interface contains functionality to marshal and unmarshal context representations to and from XML.

Time Interface

Since time is an integral part of the notion of context, a standalone interface is dedicated to classes dealing with time. Here you can e.g. define periods, and activities that have periods etc.

Security Inter ace f

As seen, security is essential to the success of the context middleware. Therefore, in addition to the built in security features such as username/password protection and context space encryption, the interface also provide support for the use of X509 certificates and the use of SSL network connections.

Context Interface

This interface contains core classes for implementing the Context, ContextSpace concepts (see detailed discussions in section 5.3). These are the central concepts for the user of the Context Middleware.

Util Interface

This interface contains misc. utility classes like collections that are frequently used in the context middleware.

Synchronisation Interface

Context Spaces are likely to run on mobile computers (with limited storage space, limited battery power etc.). Therefore, there will be a need to back up your data (from mobile devices to stationary devices). Such functionality is supported by classes in this interface.

Events Interface

This interface defines all the possible events that are generated in the context middleware.

4.3.7 Content management and integration (CIP)

The CIP (Content Integration Platform) is the component in the AmbieSense Framework that provides the common interface to content and an extensive range of sophisticated Information Retrieval related tasks.


IST 2001- 34244

An important aspect of the CIP is it’s ability to function as an add-on to existing Content Management Systems, thus causing minimal disruptions to the existing infrastructure at the CSP’s site. This section gives an overview of the functionality offered by the CIP and the way it can be used through descriptions of its various interfaces. The AmbieSense Reference Architecture also envisions the need for a lightweight version of the CIP called CIP Light. This instance of the CIP should be specially designed for the technical solution at hand for computers with limited capacities and should not include all the features of the full version depicted below.

Figure 14: CIP interfaces

Analysis inter ace f

The functions available through the Analysis interface provide analytical processing of content in terms of context (using e.g. information retrieval, information extraction, information filtering and data mining techniques). The main objective of these processes is to implement personalization and adaptation of the content based upon context. Adaptation of content is supported e.g. by linking of Content Items (see description in section 5.3)

Tracking interface

The Tracking interface offers functions to record traces of user’s actions (naturally adhering to security and privacy policies for the system). Among the action categories that can be traced are Mobile Computer type, user activities within Information Zones (see section 5.3), and specific information retrieved.

Content Delivery interface

An important aspect of an integrated content platform is the ability to deliver content in suitable formats to ensure that the rendering of content is done according to the requirements of the Content Provider. The Content Delivery interface of the CIP contains the functions to construct Info Packages (see also section 5.3), suitable for the Mobile User’s computer.

User Management interface

The functions available through this interface enable the management of users and user groups within the CIP system. Security is an important concern for the CIP, and proper management of user is key in achieving security goals.

Content Base interface

The Content Base interface provides functions that controls low-level storage capabilities, for example CMS-like functions for adding, deleting, and updating Content Items (see also description in section 5.3).


IST 2001- 34244

4.3.8 Proximity detection

Proximity Detection deals with detection of Mobile Computers in the vicinity of a Context Tag, or vice versa. A Mobile Computer can also use the Proximity Detection component to detect the presence of Context Tags (see [AmbieSense-D3]).

Proximity Detection interface

The Proximity Detection component implements functionality for search for other units, obtains a measure of the distance to another unit, and establishes a connection to a unit.

Figure 15: Proximity Detection interface

The Proximity Detection component uses services available from the Network Service component in order to implement the interface.

4.3.9 Network Service

The Network Service provides uniform network access, using the industry standard TCP/IP protocols, on top of the network technology selected for the particular technical solution. In addition to this, certain functions are only useful on certain networks, for example, the ability to determine the proximity measure for wireless communication units. This function is only available on WLAN and Bluetooth networks. The Network Service component provides access to secure communication protocols, such as SSL and HTTPS.

4.3.10 Key component interactions

The previous sections have explained the main functionalities of each component in the AmbieSense Reference Architecture. Depending upon the requirements that are set by the concrete technical solution, a detailed configuration must be designed. To guide the solution builder, some example configurations are presented in section 4.4 - Engineering Viewpoint. However, even if the main functional aspects of the components are known, it is also necessary to illustrate how the components can interact, with function invocations and data transfer, in order to accomplish their tasks. In this section, we will illustrate some of the key interaction patterns between the components. As previously stated, layering is the principle pattern in the software architecture (see section 4.3). This simplifies reasoning, design, and implementation of the system as functional aspects are clearly separated in logically coherent components. This section illustrates a selection of interactions between layers (i.e. components).

User Interface, applica ion and agent interaction t ,

User Interface, Application, and Agent components are developed together; to suit the needs of the particular technical solution one seeks to build. Figure 16 illustrates the principle interaction pattern between these components in a generic solution.


IST 2001- 34244

Figure 16: Principle interaction pattern User Interface, Application, and Agent

The User Interface starts the Application component, which in turn starts the Agent component. The Agent detects a change in context (the Agent’s interaction with Context Middleware is not shown in the figure) and reports this to the User Interface using the notification interface. Similarly, the Application detects a change in the content, perhaps because it has received new content from the push component (not shown in the figure). The notification interface is asynchronous, meaning that the User Interface is not paused by this occurrence, but is free to deal with the events at an appropriate time. At last, the User Interface tells the Application to stop, which in turn causes the Application to try to stop the Agent.

Application/Agent and Pull component interaction

Applications and Agents use the Pull component as a Web Server, requesting content using HTTP requests. A simple usage scenario of the Pull component is shown in Figure 17 below. The CIP is included in the figure for the sake of completeness.

Figure 17: Application/Agent using the pull component

The Application/Agent takes the initiative to retrieve content from the Pull component by sending it a request. The Pull component determines that the request is for content, and thus forwards it to the Analysis interface of the CIP (see also section 4.3.7). Some partition of the current context (either user context or tag


IST 2001- 34244

context) is sent as argument to the CIP. Based upon the contextual request, and the content available, the CIP returns some content if a match with the request is found.

Application and Push component interaction

As described earlier, the Push component is based upon the concepts of publications and subscriptions (see section 4.3.5). In order for a consumer to receive content, he must subscribe to one or more publications. The figure below illustrates how this can be accomplished.

Figure 18: Push component, defining publications and creating subscriptions

Initially, some program must define the publication and which Content Items (or Info Packages) that should be contained in them (the section 5.3 provides a discussion of Content Item and Info Package). In the illustration, the operator of the User Interface on the Content Service Provision platform accomplishes this by retrieving a list of Content Items from the CIP and subsequently creating a publication in the Push component for these Content Items. This establish a relationship between the CIP and the Push component – every time a change is made to a Content Item belonging to that particular publication, the Push component is notified by the CIP. This, in turn, allows the Push component to notify subscribers about the change. Subsequently, referring to the illustration again, the Application component creates a subscription for the publication just defined. A subscription establishes a relationship between the subscriber (i.e. the Application) and the publisher (i.e. the CIP). The illustration below illustrates how the update of a Content Item in the CIP is signalled to the Push component, which in turn notifies any component that has subscribed to publications including that particular Content Item. In the figure, an Application/Agent component has already subscribed and is thus notified by the Push component. The Application/Agent component subsequently contacts the CIP and retrieves the Content Item.


IST 2001- 34244

Figure 19: Application/Agent notified by Push component

Summary

A large number of other interaction patterns will occur in a concrete implementation of the reference architecture. However, the illustrations presented here show some of the most common ones.

4.4 ENGINEERING VIEWPOINT – HOW TO BUILD AMBIESENSE APPLICATIONS The engineering viewpoint is concerned with the design of distribution-oriented aspects, i.e. how components are physically deployed to the different machines and the infrastructure required to support distribution. An engineering specification of an ODP system defines a networked computing infrastructure that supports the system structure defined in the computational specification and provides the distribution transparencies that it defines. It is important to note that although we discuss the Context Tag in all configurations, it is possible to implement the AmbieSense Reference Architecture without them. They might be omitted or other style computers with similar capabilities can be used instead.


IST 2001- 34244

Figure 20: The AmbieSense Reference Architecture

Figure 20 above illustrates how the various functional components are organised logically in the reference architecture. It does not show a concrete implementation of it. Rather, it shows how each of the three platforms (mobile computer, context tag and content service provision platform) is able to function as nearly independent execution environments for the AmbieSense system. Now, however, this is not a very likely scenario in practice, it is merely a demonstration of the flexibility of the reference architecture to support widely different implementations, for example dictated by different technical requirements imposed on the concrete solution one wants to implement. Now, we will present three examples of concrete configurations of these components on the platforms. Configurations are determined by analysing the requirements of the wanted solution, and then applying these requirements to select the components needed on each platform. Subsequently the solution must be implemented and tested. The configurations are illustrated using deployment diagrams, showing which components are installed on the various computers in the system. Communication protocols HTTP and TCP/IP, both of which are supported by the Network Service, implement cross computer interaction (see also section 4.3.9).


IST 2001- 34244

Figure 21 Deployment configurations

Example 1, Thin client, rich Context Tag configuration. Certain solutions require low complexity mobile computer configurations. For example, if a solution was going to support the use of smartphones with very limited storage and processing capacities, most of the processing should be allocated to the Context Tag or the Content Service Provision platforms. The configuration illustration above shows an implementation of the reference architecture with a minimum weight client used in combination with Context Tags (i.e. no Content Service Provision platform required). The thin client configuration illustrated here requires only three components on the client: 1) A user interface, 2) a minimal amount of application logic and 3) proximity detection. The need for 1) and 3) are self-explanatory, and 2) is needed to send some context information to the Context Tag. Because only very small amounts of context information may be necessary by the solution in order to find useful information for the mobile user, the Context Middleware is not needed on the Mobile Computer. The context could be sent to the Context Tag as a single (or set of) parameter(s), for example, as a location parameter as the Proximity Detection component signals a mobile computer in range of the Context Tag. All remaining processing (i.e. receive context, process context, push relevant information) is done on the Context Tag. Consequently, in this configuration, a rich set of functionality is deployed to the Context Tag. A fairly resourceful Context Tag is required (with respect to processing power and storage).


IST 2001- 34244

As this configuration does not include the Content Service Provision platform, it is assumed that the Context Tag Administrator receives the content complete and ready to be uploaded to Context Tag and into the CIP Light component (discussed in section 4.3.7). The Context Tag Administrator uses the context tag administrator component to accomplish this task. Example 2, Medium-weight Mobile Computer, rich Context Tag configuration. In scenarios where more generic and sophisticated context processing such as context matching is required, the Context Middleware is deployed also to the Mobile Computer. Naturally, this assumes more processing power and storage is available on the device. Configuration no. 2 in the figure above illustrates the deployment scenario. The two instances of the Context Middleware component deployed are used by the application to use the context matching functionality of the Context Middleware (implemented by the interface Context Interface, discussed in section 4.3.6). Also here, a rich set of functionality is deployed to the Context Tag setting requirements to a fairly resourceful Context Tag. The Proximity Detection component is used, it will signal both the Mobile Computer and the Context Tag when a mobile computer in range of the Context Tag. As this configuration does not include the Content Service Provision platform, it is assumed that the Context Tag Administrator receives the content complete and ready to be uploaded to the Context Tag and into the CIP Light component (discussed in section 4.3.7). The Context Tag Administrator uses the context tag administrator component to accomplish this task. Example 3, Rich Mobile Computer, medium weight Context Tag, medium weight Content Service Provision platform. The previous configurations have not included the Content Service Provision platform. For many technical solutions, the integration of content from existing content management systems is critical. This may be a good reason to consider configurations that include a back-office server that can provide the link to existing legacy systems. The CIP component addresses the task of integration and a vast number of other sophisticated processes (see discussion in section 4.3.7). As before, the Context Middleware component is deployed to both Mobile Computer and Context Tag. To determine a potential context match, the Application component initiates a context match operation between the context of the Context Tag and the context of the Mobile Computer (see discussion in section 5.2.3 for more details on context matching). Also, the prevision configurations have not included agents. For a range of technical solutions, agents can be a good vehicle for certain processing. Example no. 3 in Figure 21 above illustrates a deployment configuration including agents. All AmbieSense agents interact using the JADE framework, which are based upon the message transmission protocols (IIOP, HTTP). In addition, they interact with other AmbieSense components such as the CIP or the Context Middleware (see also discussion in section 4.3.3). Summary. The configurations presented above only represent a small number of many possible configurations. Depending on the exact technical needs of the solutions, different configurations from these can be developed and deployed. It follows from the flexibility of the reference architecture that some components may be quite similar even if they in different configurations are deployed to different platforms. The Reference Architecture should therefore be seen also a vehicle in increasing the reuse of functionality between different configurations. Examples of such reuse potential might be in the use of advanced agents or business logic in the applications. Likewise, in a technical solution that require offline Mobile Computers, it might make sense to implement a light-weight version of the CIP that can handle content management and thus support a certain degree of functionality for example by maintaining some local content that remain available while being disconnected from a network.


IST 2001- 34244

5 Information Structures and Processing The goal of this chapter is to enable the implementation and use of ambient, personalised and context-sensitive information systems. The audience are application and service developers who will develop ambient content services. The project would like to transfer the project's knowledge of the AmbieSense information structures to the information society. The AmbieSense project has chosen to populate and deploy the information structures and the processing of them in pilot applications for travellers and tourists, because of the challenging requirements that these kinds of applications have. Some of these requirements can be summarised as:

1. The need for ambient access to relevant information while being mobile 2. The rapid change of the user's situation (context) imply the rapid change of information needs 3. Individual needs and interests creates the need for personalised access to information

The implementation and use of such information systems requires that we establish a common vocabulary that can enable:

a) Ambient access to information stored anywhere in the world without changing existing information repositories. This is done by proposing the use of a meta-layer of information objects where links between the actual content (e.g. pictures, documents, music, books, and web pages) and these new information objects can be created without changing the actual content itself. The information object for this is called the Content item, which points to the actual content.

b) Different information relevance technologies to find and provide the right information in the right situation and to the right user. Again this is achieved by the proposed meta-layer of information objects. The core information objects for this are Context, Content item and Info package. The context tag is a vehicle that enables context, content items, and info packages to be provided in the different situations they encounter.

c) Different business and revenue models for ambient content services by proposing a meta-layer on top of Content items called the Info package.

d) Personalised access to information for individuals and groups of people from anywhere in the world. This is achieved by the following information structures: User, User group, and User Context. Parts of the user context describe the personal context for a group of people or individuals. User contexts can be linked to any content via content items and info packages.

This chapter therefore presents the AmbieSense information structures. This is done from several viewpoints to the information structures and how they are/can be used. Note that some of the same information structures and their relations can therefore be explained in several different ways. Detailed class and interface descriptions of the AmbieSense information structures follow at the end. All readers interested in implementing and using these should read this chapter. By information structures we mean any kind of information or data structure that can be described by concepts and relations. In UML, concepts and relations are commonly described in terms of: classes, attributes, associations, and interfaces. By information processing we mean how the information structures (i.e. the classes) can be processed and used by people or computers. This chapter is a result of using RM-ODP with UML as the modelling language. In other words, it can be regarded as the information structure and processing viewpoint of RM-ODP. UML is used to present the information structures, because it is a widely used industrial standard which many software houses follow to develop applications and services. Each of the following sections consists of a UML class diagram together with some paragraphs that explains it for each of the information structure viewpoints. Note that


IST 2001- 34244

each concept in the class diagrams is described in detail at the end of this chapter8. A class can in this document occur in several viewpoints. It is also important to know that the proposed information structures may be implemented in any programming language. Hence, they may be implemented as classes and objects in object-oriented programming, as abstract data structures in functional oriented programming languages, as file formats stored in a file system (e.g. HTML), as data tables and relations in a relational database, as XML messages and so on. It is up to the programmer to decide this when implementing.

5.1 INFORMATION STRUCTURE VIEWPOINTS This section contains the following information structure viewpoints:

• Context –a general information structure • Various types of contexts – determined by the actor/entity in focus • User contexts – describe aspects of the user's situations • Tag contexts - automatically merged with user contexts • Context templates – made to guide the creation of contexts • Context Space – a general repository for past, present, and future contexts • Context Tags – these enable ambient content services • Content items and info packages – meta-information about content • Context-aware access to content via calendars

5.1.1 Context – proposed as a general information structure

At the core of a context sensitive system there must be an information structure to store the context-sensitive information, here called context. Allowing applications to process the context within which they operate in is the key to context-sensitive information systems. This section explains how context is proposed as a general information structure to be used and extended by application developers. AmbieSense chose to implement this structure by developing Java-classes integrated with XML technology. A context describes aspects of a situation seen from a particular actor's point of view. An actor is a person or object (possibly, but not necessarily, a computer system) that interacts with the situation. In this way context is actually defined as something separate from the situation it self. A context in AmbieSense is a representation of aspects of the real-world situation held inside the computer. A context consists of:

• Name • Type • Attributes • Sub-contexts • Links to content

8 It is assumed that the reader of this chapter has basic knowledge of UML notations. Associations are drawn as lines between two classes. Inheritance associations are drawn as lines with a white triangle pointing to the super class. "Part of" associations are drawn as a black diamonds pointing to the class in which the opposite class is a part of. An association can in general be given a name, end names, direction, and cardinality. When the attributes of a class are important to show, they are shown as text inside the class. Each class is drawn as a rectangle. When it is possible to identify the data primitive of an attribute, this is done by the following notation <attribute>: <data primitive>. Examples of data primitives are: integer, byte, float, real, complex, char, string, text, symbol, double etc. Data primitives exist in all programming languages from the computer instruction set and up to high-level programming languages - including symbolic languages.


IST 2001- 34244

-name: string-type:string

Context

-name: string-type: data primitive (e.g. boolean, int, float, double, string,.. )-value: type

Attribute

** can be linked to

-is part of1

-has0..*

-can be part of 1

-can have sub-contexts

0..*

Content

Figure 22: Context

Context as an information structure is not of much use unless it can be linked or associated with chunks of information and data – in AmbieSense these are referred to as content. Content is typically stored in files or databases, and is presented to the user through a specialised interface. Content is what content service providers sell - or provides for free - to people and businesses. A context (see figure above) can have sub-contexts, which again can contain several other sub-contexts. This means that a context can be part of another context, and a context can consist of several other contexts. In general, a context should always contain one or more attributes. When a context consists of several sub-contexts, however, it is also possible to make meaningful contexts without including any attributes at the top-level context (see the tag context and the user context later this chapter for two examples on this). Each attribute of a context has a name and a value. A name should be a string - but feel free to develop your own data structure for it if necessary for the application. A value can be a number, a truth value, or a text string. The attribute always has a type, which should be a data primitive from the programming language in use. Examples of data primitives in Java are: boolean, int, float, double, and String, while in Pascal: Byte, Boolean, Integer, Character and so on. The value of an attribute could beneficially be constrained in some applications. An example could be an attribute with the name="Country", the type=string, and the value="Scotland (UK)". The set of legal values could be constrained to the set of valid country names of a specific language/ locale. Constraining the possible values an attribute may optimise aspects of the application being developed (see context template later in this chapter for more on value sets and ranges). In summary, context can only contain information that can be captured either automatically by the system or manually by user input. Some contextual information is quite static while others are more dynamic. This means that some attributes may never change, others change once a year, or even every millisecond. Since an actor/entity encounter new situations at regular times, the context should either be updated, or replaced by a completely new context.

5.1.2 Various types of contexts – determined by the actor/entity in focus

In general, one can speak of many different types of contexts. The type of a context depends on the actor/entity that the context is intended for. As mentioned above, an actor/entity may be any person or system involved in the situation.


IST 2001- 34244

Context

User context Tag context Other types of contexts

Entity/ActorSituation

0..* 1

describes aspects of >

* *< encounters, is within, leaves

1*

is described from the viewpoint of >

Figure 23: Various types of contexts

Here are some basic examples on how to determine the context type depending on the actor/entity that is involved:

• Contexts describing a user's situation should be named user context • Contexts describing a software's situation should be named software context • Contexts describing a document's situation should be named document context • Contexts describing a user's task situation should be named user task context • Contexts describing a user's personal situation should be named user personal context • Contexts describing a network's situation should be named network context

The following more complex examples illustrate how one can determine the type of a context that consists of several sub-contexts. Again, the suggestion is to see it from the view of the overall actor/entity:

• You need to describe the user's task situation and user's personal situation (see above). They can be regarded as parts of an overall user's situation. You can organise them under an overall user context consisting of the task context and personal context.

• You are making an application for car tourists and need to describe the situation that the car is in every minute due to the changing geographic location, in order to choose the right infotainment in for rear passenger seats. You find out that important parts of the car that should be regularly described are the speed, location, passengers, and traffic jam etc. In this case one can develop a car context consisting of the following four types of contexts (sub-contexts): speed attribute, location attribute, passenger context, and traffic context.

AmbieSense needs to describe user contexts in some prototype applications, and has therefore identified the need for a handheld computer to automatically receive information from its surroundings. It must update the user contexts with minimal user input, due to usability requirements. The information in the surroundings will be communicated to the handheld computer via context tags. It has therefore identified two important actors in the situation where information is received from the surroundings: the user and the context tag. The conclusion is that there should be one context structure for each of them, namely the user context and the tag context. The rationale behind the two context structures is that we believe that automatically fusion of the “current tag context” (residing on the context tag) with the “current user context” (residing on the mobile client) helps the mobile user to have a minimum need to input data into the system. This approach also protects the sensitive information about the user found in the user context. The merging of the two context structures can be described as: merge (user context 1, tag context 1) -> user context 2. The current user context at the handheld computer can then be set to user context 2.


IST 2001- 34244

The user context and the tag contexts as general information structures are described in the following two sections (see Appendices for the four other concrete user context and tag context structures are found in the application). Hence AmbieSense operates using a flexible context structure. This is because there is a common structure for contexts, which is easy to reuse across application domains.

5.1.3 User contexts – describes aspects of the user's situations

The user context describes aspects of a situation seen from the user's point of view.

User

Usercontext

0..*1

Socialcontext

partof

Taskcontext

Personalcontext

Mentalcontext

partof

Physiologicalcontext

Environmentcontext

Spatio-temporalcontext

partof

Figure 24: User context

This is proposed as a framework for exploiting user contexts within and across application domains. The user context structure is designed in order to enable effective matching and retrieval of contexts within and between applications. All information is therefore available to the user through the interface, although only the relevant information is presented to the user at any time. The AmbieSense user context structure consists of five sub-contexts:

• Environment context • Personal context • Task context • Social context • Spatio-temporal context

Each sub-context should be considered as a container where you as an application developer insert the attributes with values and types that are needed in the context-aware application you are developing. Environment context – This part of the user context captures the entities that surround the user. These entities may be (but are not limited to) things, services, temperature, light, humidity, noise, and persons. Information (e.g. text, images, movies, sounds) that is accessed by the user should be linked to the environment context. The various networks that are in the surrounding area can also be described in the user’s environment context. Personal context – This part of the user context consists of two sub contexts: the physiological context and the mental context. The physiological context contains information such as pulse, blood pressure, weight, glucose level, retinal pattern, and hair colour. The mental context contains information like mood, expertise, angriness, stress etc. Task context – This context describes what the persons (actors) are doing. The task context can be described with explicit goals, tasks, actions, activities, or events. Note that this can also include other


IST 2001- 34244

persons’ tasks that are within the situation. For example, with a car with a driver and passengers, the situation can include the driver driving the car, passengers doing various activities such as reading, watching the car TV, and listening to music on the personal stereo. The task context of the driver and the passengers will be different. Social context – This context describes the social aspects of the current user context. It can contain information about friends, neighbours, co-workers, and relatives. One important aspect in a social context is the role that the user plays in the context. A role can for instance be described with a name, the user’s status in this role, and connections to the tasks in the task context. A role can, in addition, be played in a social arena. A social arena can have a name like “at work” and have a geographical area. Spatio-temporal context – This context aspect describes aspects of the user context relating to the time and spatial location for the user context. It may contain attributes for time, location, direction, speed, shape (of objects/buildings/terrain), track, place, clothes of the user and so on (i.e. the spatial extension of the environment and the things in it). Note that it is up to you as an application developer to decide whether an attribute such as location should be in the environment context or in the spatio-temporal context. The important issue is that you must decide where an attribute should be inserted based upon what you and other people believe makes more sense.

5.1.4 Tag contexts - automatically merged with user contexts

The tag context describes aspects of the situation seen from the context tag's point of view.

Tag context

Environmentcontext

Taskcontext

Socialcontext

Spatio-temporalcontext

partof

partof

Context Tag

0..*1

Figure 25: Tag context

The tag context refers to the context descriptions that reside on the context tag. Contexts can be updated and replaced by a new context as time goes by as a result of a change in the situation around the tag. The structure is very similar to the user context, but lacks personal context. The rationales for this design are: 1) tag contexts will be automatically merged with the user context, and 2) personal context only applies to actual end users (humans), and is to be regarded as personal and sensitive data about the user. The context tag enables first the exchange, and subsequently the comparison of the mobile user’s context with the tag’s context. The similarity in the structure of both the user and the tag contexts makes it efficient to compare, construct, and merge these contexts. The user context and tag context can be enriched by each other when the user approaches to the context tag. Applications both on the context tag and the mobile computer can use this enriched context information to ensure the contextual adaptation of services. In summary, then, an AmbieSense tag context consists of four parts:

(1) Environment context – This part of the tag context captures the entities that surround the tag. (2) Task context – This context describes what the persons (actors) are doing around the tag.


IST 2001- 34244

(3) Social context – This part describes the social aspects around the current tag context. It can contain information about people in the vicinity of the specific context tag.

(4) Spatio-temporal context – This context type describes aspects of the tag context relating to its spatio-temporal extent. It can contain attributes like: time, location, direction, speed, shape of the thing that the tag is mounted on, track, and place.

The important issue is that the application developer should decide which context and attributes to insert. This decision will be based upon what people may require and what makes more sense.

5.1.5 Context templates – made to guide the creation of contexts

Contexts are created from context templates. This means that there can literally be thousands of contexts adhering to a certain context template. Context templates should be used in order to standardise the creation and exchange of contexts both within and between applications. The context template should be developed by the application designer or programmer in consultation with the content service provider. It can be viewed as a means of describing aspects of a general/typical situation that an actor/entity can encounter. By developing a context template for an application we can achieve the following:

1. A shared understanding of what the context is as an information object 2. Ensure that all context objects within the application are computational information structures

By using context templates we can improve the quality of the application of the application as well as allowing developer-based extension of the technology. Another result is that we can effectively compare two contexts made from the same context template in order to identify similarities in the data. Context templates are different from the contexts, because contexts are created (either manually by the user or automatically by the system) during application use. Context templates cannot and should not therefore be linked to content at all. They also differ from contexts, because they constrain the contexts with respect to structure of sub-contexts and attributes. In addition, context templates set and constrain the set of valid value sets and value ranges for each of the attributes. For instance, the valid values of an integer attribute can be constrained by one or more value ranges, while the valid values of a string attribute can be constrained by a finite value set of strings. A value range has a type of the value and a min and max as parameters, while a value set has a type and a finite set of values included. Some examples of value ranges are:

I. Value range A = [10, 1000], type=integer II. Value range B = [0.1, 0.12>, type=real

III. Value range C = <-1.0, 1.0>, type=complex IV. Value range E = [false, true], type=boolean V. Value range F = [June 1 2004, Aug 31 2004], type=date

Some examples of value sets are:

i. Value set 1 = {"Red", "Blue", "Green"}, type=string ii. Value set 2 = {"Little", "Average", "Much"}, type=string

iii. Value set 3 = {"12", "14", "N-12", "N-14"}, type=string iv. Value set 4 = {1, 10, 100, 1000}, type=integer v. Value set 5 = {false, true}, type=boolean

vi. Value set 6 = {May 1 2003, Jan 1 2003}, type=date


IST 2001- 34244

In order to illustrate the use of attributes, value sets, and value ranges for context templates, an application example is provided below. Example application: A photo album application helps the user to manage their personal digital images. The user takes the pictures with a digital camera and annotates a context for each of the pictures in order to make the digital photo album searchable. A single "photo context template" was made, to which each "photo context" created by the user must adhere. The attributes of the "photo context template" are:

Attribute 1: name="Title", type=string Attribute 2: name="Persons", type=string Attribute 3: name="Location", type=string Attribute 4: name="When", type=date, value range= [1 Jan 1900, 31 Dec 2099] Attribute 5: name="Category", type=string, value set= {"portrait", "landscape", "people"} Attribute 6: name="My rating", type=string, value set = {"favourite shot", "normal shot"}

The attributes of a context linked to a photo can be:

Attribute 1: name="Title", type=string, value="Grandma 2003" Attribute 2: name="Persons", type=string, value="Grandma and me" Attribute 3: name="Location", type=string, "In the garden at home" Attribute 4: name="When", type=date, value="21 Aug 2003" Attribute 5: name="Category", type=string, value= "people" Attribute 6: name="My rating", type=string, value="favourite shot"

Hence, the user can fill in the values of the six fields for each of the picture that he chooses to annotate, and he can search and sort the photos according to attributes and values of previously created contexts. The relationship between a context and a context template is depicted in the figure below:

Context template

Attribute

-is part of1

-has0..*

ValueRange ValueSet

-can be part of

1

-can consist of0..*Context

0..*

0..*

0..*0..*

-Constrains0..*

-Made from 1

Figure 26: Context template

In summary, context templates constrain a context with regard to both sub-contexts and attributes with values. One important mechanism is through the value ranges and value sets that can constrain the possible values of an attribute. I.e. the context template defines an information structure from which contexts can be created and against which they are validated. Once an application determines that two contexts were made from the same template, it can be assumed that the meaning carried by the contexts and its attributes are the same. In AmbieSense, the context middleware supports the management of both context and context templates (see [AmbieSense-D5].


IST 2001- 34244

5.1.6 Context Space – a general repository for past, present, and future contexts

The context space is a viewpoint into a user's personal information space, where the information is linked to past, present and future contexts. The user may have access to the context space from anywhere at anytime. There is a set of history of contexts, a current context, and a set of possible future contexts. In other words, this means that the content that was presented and used by the user in a situation that he encountered can be presented to the user once again, when the user wants a past context to be retrieved from the context history. The UML model of the context space is depicted in the figure below:

ContextSpace

Context

ContextHistory

CurrentContext

Futurecontexts

0..*0..*

10..*

< partof 1

0..*

part of>

11

part of> 1

11

1

< partof

User

Figure 27: Context space

The context space is capable of containing contexts based upon any kind of context template. This means that any kind of context-aware application can store, update, and retrieve their specific types of contexts from the same context space. Hence, a context space could be a general service provided to each individual user. User contexts, tag contexts, and other types of contexts can be stored in the same context space. Multiple applications can concurrently access and use the same context space as a general service. The context history contains all past contexts. An example is that a person drags and drops content item X over context A, and stores it in the context history. Two days later when the person is in the current context B, similar to context A, the system automatically presents content item X to the user. The current context contains information about the current context. The current context is where applications get information concerning the current context of the involved actor/entity. Various context sources can feed information into the current context (e.g. people, sensors, software etc.). The context future is a set of contexts that systems or users can predict. The context future contains contexts that are created and explicitly stored in context future. Planned activities in a personal calendar can all be thought as examples of future contexts. A system might also predict some future contexts when a user subscribes to a service. An example is when a user is travelling from one city to another. He encounters various contexts like "in the taxi", "in the airport,” "at the gate", "onboard,” "at arrivals", "baggage claim" and so on. Different content items can automatically be linked to future contexts, like the e-ticket, the city map, the shopping content for the airport and so on. This would have been very difficult to make were it not for the explicit focus on context-awareness. Context changes rapidly. When users travel, for instance, the change of situation and context is likely to occur more frequent than if the user stays at the same place. However, one can easily argue that the situation changes even if a person remains in the same room, due to activities nearby – and most


IST 2001- 34244

importantly as time passes by. For example, the situations can be "in the morning", "at breakfast", "at noon", "in the afternoon", "dinner", "supper", and "night". At breakfast, the content linked to the context might be the wake-up melody, at breakfast the local newspaper, at noon the CNN news, in the afternoon the latest stock prices, at dinner tons of grocery ads, and so on. In other words, contexts can be planned to occur at recurring times during the day, week, month, and year. The context space is a persistent storage area for the contexts encountered during time. There can be only one current context, but there can be zero, one or many contexts as part of the context history and the same for the context future. An increasing number of contexts stored in the context space introduce the need for context management functionalities. Context is sometimes sensitive information about the user – especially when previously presented user contexts are stored. The contexts should therefore be accessed, stored, and retrieved using stat-of-the-art security and privacy mechanisms. It is useful to be able to query for contexts that contain certain attributes and values. However, application developers should avoid matching a context against all the other contexts. This is mainly because they can be of different types. The advice is that different types of contexts should in practice never be matched with each other. They are normally made for different application domains even if the names of two attributes in two different types are same. For instance, an attribute called "location" in two types of contexts can both be a string. In one of the applications, however, it represents a geo-code, and in the other it is a string where city names are written. Hence, there should be very strong arguments before we consider comparing contexts of different types. If the application developer needs to match two types of context then he should merge the two contexts together into the same context template used by one of the original two contexts. Context management is about the creation of new contexts, determining the current context; the storing, searching, matching, retrieval of, and sharing of contexts with other people. Content may be linked to contexts either explicitly or with the use of retrieval algorithms. In fact, context technology is only useful for users once contexts are linked either directly to content, or indirectly via information retrieval and extraction mechanisms (i.e. search functions). Remember that a context without relevant content is useless, whilst relevant content without context would still be useful.

5.1.7 Context Tags – enabling ambient content services

The goal of using the context tag is to enable the development of ambient content services that provide relevant information to the users. The context tag is an entity, which binds both content and context to local surroundings and objects. One important characteristic of the context tag is to tell the mobile computer where it is. A context tag is basically a miniaturised computer that has some means of wireless communication. It can be visibly mounted in the surroundings, or hidden away in things and furniture. It might communicate via Bluetooth or WLAN to the mobile computer. It is used to distribute relevant content to the right surroundings. Examples of ambient content services using context tags: 1) An ambient content service called "BigCityEvents" has had 10000 users and populates 1000 context tags in the surroundings where the masses of users are or will be located. There are also 10 wireless networks, to which the mobile devices can be connected. In the backbone network there is a content server, which delivers content in terms of relevant news and events to each of the subscribing users. The subscription fees pay for the content, software licences, and the populated context tags. The wireless network access is partly paid by the users themselves, and partly paid by large venue owners. 2) Each 100 context tags are mounted under the tables in 5 local restaurants. The restaurant owners’ share a common content server and a WLAN network. A mobile computer is handed to the hungry customers as they are seated in the restaurant. The device can be passed around the table, and the content that the restaurant owners provide to their customers can be accessed only when the customers appear close to each


IST 2001- 34244

table (i.e. context tags mounted under the table). The interactive restaurant menu (which takes the order), the financial newspaper, and the local city guide can all be read on the mobile computer. As soon as the user moves away from the table, the computer display fades to black. Hence the content can only be read while they are seated because the restaurant owners wants their customers to sit longer at the table to (hopefully) spent more money and increase the chance of customer return. 3) An airport has deployed 200 context tags in the public areas such as departure and arrival halls, in the shopping area and at the airport entrance. Because the context tags are aware of their own physical location, the user can get airport information, ads, and special offers from the airport companies serving the location. One user might get an overview of the airport when appears in the entrance area. Another one might just get out of an airplane and enter the arrivals area to get information related to finding a taxi or bus. The relevant info can be tailored to the user’s context, e.g. the pending flight (for example by using the flight number).

ContextSoftware

Context Tag

MobileComputer

Content

InformationZone

runs on/linked to linked to

stored on/linked to stored on/linked to

occursin

User

accesses contenton

ContentServicemaintains

can communicate via wireless networkwith

can communicate wirelesslywith

Figure 28: Context tags

The figure above depicts the context tag’s relations with the other AmbieSense concepts at an overall level. In summary, context and content can be communicated between the context tag and the mobile computer in the hands of the user. The tag context, its content, and the eventual software needed can either be: 1) stored locally on the computer, or 2) linked to the ID of the context tag. In latter case, one must use a wireless network so that the mobile computer can communicate with other computers in the network in order to download the relevant content, context, or software – unless the required items are already located on the mobile computer.

5.1.8 Content items and info packages – meta-information about content

The goal of introducing meta-information for content is to enable ambient access to any kind of content stored anywhere in the world without changing the content or its repositories. The proposed meta-level for content enables flexible integration, distribution, and use of content in ambient and context-aware applications. Content means digital pictures, documents, music, films, books, web pages, and so on. See the figure below for the information structures called content item and info package that together comprise the meta-layer:


IST 2001- 34244

-Type-Topics-Content_URL-DateCreated-DateModified-AccessPeriod-Owner-Copyright_URL-Original-Interest rating-language-ID

Content item

-Period-Topics-Price-Currency-CopyRight_URL-Certificate-Owner-ContentProvider-ID

Info package

0..*0..*

-FileName-FileSystem-Input-Output-Certificate-Size

Content

Content Template

<- is metalayer for

1 1

1*

Useris used by

0..*

uses0..*

is used by0..*uses0..*

is used by

0..*

uses0..*

Figure 29: Content items and info packages

Ambient content services can benefit from the proposed meta-layer of content items and info packages, because it can:

1. Support the development of multi-lingual content services 2. Utilise content to be managed, indexed, and searched according to topics without the use of

advanced information retrieval and extraction techniques 3. Enable the reuse of the same content across content services with just-in-time delivery of the

actual content itself to the user 4. Integrate content with different content distribution and revenue models 5. Maintain digital rights control without burdening the content authors

The content item points to the actual content itself with Universal Resource Locators (URL). The info package refers indirectly to content via the content items. Both the content item and the info package are information structures inspired by the NewsML standard, which is an XML standard for packaging multimedia news resources (see www.newsml.org, the news item, topic set and the news envelope concepts). The content item is inspired by the news item, info package is influenced by the news envelope, and topics of both content item and info packages are inspired by the topic set of NewsML. The MPEG-21 standard for multimedia representation can also be integrated into the AmbieSense content structure. The info package can be related to the container concept, while the content item can be related to the digital item See http://mpeg.telecomitalialab.com/ for further details on MPEG-21. NewsML has been created under the auspices of the International Press Telecommunications Council (IPTC), and version 1.0 was approved by the IPTC on 6 October 2000. Since then, NewsML has become the de facto industry standard for representation of news content. A more detailed description can be found at http://www.newsml.org/ and in the textbox later in this section. The main weakness of NewsML is the rather complex and layered structure, which might appear difficult to understand, in addition to the weaknesses inherited from the XML standard itself. The similarity between the AmbieSense content structure and NewsML are the followings:

1. The content item of AmbieSense can be regarded as a super class of news item of NewsML


IST 2001- 34244

2. The info package of AmbieSense can be regarded as a super class which is the news envelope of NewsML

3. The topics, which are attributes of both content item and info package of AmbieSense, are simplifications of the topic set structure of NewsML

However, the AmbieSense content structure differs from NewsML, because it provides an abstraction layer beyond news service provision. The majority of digital music, films, e-books, text documents, web-pages and so on would be rather difficult to manage as news. In many circumstances, it would be odd to flag such content as news. Additionally, the content items and info packages of AmbieSense can be represented as abstract data structures implemented in functional programming languages, objects in object oriented programming languages, as XML files, and so on. Hence, defining a general object structure instead of an XML-structure can save computational overheads. Content is the lowest level in the content structure and is produced by content authors. Content is a group of physical files or folders that are arranged in a logical manner and can be accessed via a URL that is found within the Content Item (see class Content Item). These logical groups can be a single piece of content (a text file or a picture) or a collection of thematically coherent items (e.g. a map with textual descriptions of points of interest). Content is sometimes based upon a content template – for instance, the XML-files are based upon XML-schemas. Content item attaches identification and management information to content. The most important characteristics of the content item are the type, the topics that it is categorized under, and the URL pointing to the actual content itself. A Content Item can have zero or more topics. A search engine might fill-in automatically, or a content author might specify this after developing the actual content. The items are authored by the content service provider who is normally the legal owner and responsible of the content. Info packages are collections in which content items are bundled together with some extra administrative information. This information structure exists to be used for implementing different kinds of business and revenue models, which may vary among content services. It has the purpose of allowing a content provider to put a price on the content that they offer to the information market. Contexts can be indirectly linked to content via content items and info packages. Contexts, content items, and info packages can be populated in the network, on the PDAs of the mobile user, and on the context tags without moving or even changing the content repositories. The result is that relevant content can be distributed and rendered on the user's PDA only when needed. Hence, there is a minimum need to move content repositories around in the network when introducing a meta-layer of information structures above the content repositories. The AmbieSense content structure facilitates the management of a particular content’s lifecycle. Prior to the delivery of the content to the users, the content service provider packages the content into content items and info packages, associates with them the right users, a pricing model, and digital rights. In this sense, the info package can be regarded as the business layer in the information hierarchy. In its simplest form, it enables the provider to distribute smaller content items in advance around in the surroundings (networks) without moving the content itself.


IST 2001- 34244

5

Tscq CdoMi Wnt

NewsML concept in brief

At the heart of NewsML is the concept of the news item which can contain various different media – text, photos, graphics, and video - together with all the meta-information that enables the recipient to understand the relationship between components and understand the roles of each component.

Everything the recipient might need to know about the content of the news provided can be included in NewsML’s structure. For example, NewsML enables publishers to provide the same text in different languages; a video clip in different formats; or different resolutions of the same photograph. NewsML’s rich metadata concept can help with things like revision levels that make it easy to track the evolution of a NewsItem over time, status details (publishable, embargoed, etc.) and administrative details, such as acknowledgements or copyright details. NewsML has default metadata vocabularies to ease implementations but it does not dictate which metadata vocabulary is used (IPTC Subject Codes, ISO country codes etc.) – a providers just have to indicate which vocabulary they are using. Multiple vocabularies can be utilised within the same NewsItem. For text objects in a NewsItem, the IPTC’s News Industry Text Format (NITF) is recommended.

NewsML is flexible and extensible and uses standard Internet naming conventions for identifying the news objects in a NewsItem. As such, content does not have to actually be embedded within a NewsItem; pointers can be inserted to content held on a publisher’s web site instead. This means subscribers retrieve the data only when they need to and this makes NewsML bandwidth-efficient.

Structure of NewsML

Representation and management of news throughout its lifecycle is the aim with NewsML, while the standard has been designed to give considerable flexibility and allow for straightforward extension to suit individual user needs. Inevitably this has resulted in a rather complex and layered structure that can appear difficult to understand. However, there is no need to use all the features - so it would be possible to have a relatively simple implementation for, say, text handling - and the underlying logic is straightforward.

NewsML takes the form of an XML document, which has a series of components, or elements, that are used to structure and process the actual news content. These elements may have attributes to specify their properties and can carry content in the form of other elements (sub elements) and/or character data or external references.

(NewsML™ is a registered Trademark of the IPTC)

(Source: www.newsml.org, 6 Jan 2004)

.1.9 Context-aware access to content via calendars

his section presents one of many possible ways to integrate context technology into existing information ystems without adding extra burdens to the user or changing the user interface. The rationale in adding ontext-awareness to a system should always be to add some value to the user by improving certain ualities of the system.

ontext is an extra information object used in a system to make it context-aware. In some cases, the esigner will choose to present the context as an explicit concept for the user to interact with, whilst in ther cases the designer would need to hide it away from the user by integrating it behind the scenes. aking a system context-aware should be a solution either to enable users interact with more relevant

nformation than otherwise possible, or to optimise system performance.

e should be concerned about why we should add context technology a system at all, because: 1) there is o common way of defining, populating, and deploying context-aware applications and services, and 2) here are many approaches to and definitions of what context is. Consequently there is no common way of


IST 2001- 34244

describing a context visually to people. This is actually why the context as a data structure in AmbieSense is proposed to be an agile and flexible structure that can be tailored to each application by the designer or programmer. Hence, implementing context-awareness actually implies the use of extra technology on top of existing information infrastructures, which might lead to more complex solutions than necessary. Adding complexity to the user interaction is known sometimes to lead to less usability and a decrease in the usefulness of the system. Therefore, the potential benefits of adding extra technology should always be higher than the actual costs of adding it. However, if you still would like to make context-aware technology despite the concerns above there are two general solutions for it when it comes to user interaction design. These are to either:

1. Let the user interact with the context as an explicit object in the user interface 2. Hide away the context objects from the users, and let them believe it is something else

When it comes to the first approach a designer should really let the person understand the concept of a context, and let the user perform tasks in the system like add, edit, print, show attributes, share or delete contexts - or link content to context for instance. This can be done through the use of menus and labelled buttons. When it comes to the latter approach, assuming that we would have to present some context parts (such as attributes and values) to the user, we should seek to integrate context with existing information objects and apply useful metaphors. Hence, this solution is not to mention the term ‘context’ anywhere in the user interface at all. The digital content that a person consumes or produces can always be regarded as part of the situation in which the person was, is, or will be in. Situations, and consequentially contexts, are always related to time, and content should be linked to the context to preserve the nature and the meaningfulness of the content for each person in the situation.

Calendar Context

User

**

Content1 0..* * *

Situation* *uses

+getPeriod()+setPeriod()+getName()+setName()+getType()+setType()

«interface»Activity

1 1

Figure 30: Context-aware access to contexts via calendars

One common metaphor that might work in many cases is the concept of a calendar (i.e. a list of activities presented chronologically in time). The reason is because situations are always related to a point of time or period (recall that context describes aspects of a situation). Calendar components are found in many systems, and the concept of a calendar is well known to people. When we add a new appointment to the personal calendar, all of the attributes of the new appointment can actually be regarded as a description of a future context that we will probably encounter. Already at this stage we can link content to the appointment (e.g. such as the slide set to be presented, the business cards), which actually would be the same as linking content to a context. Hence, users could make an activity (e.g. a meeting) in the personal calendar and then drag and drop a business card and the slide set into to include them in the meeting (i.e. link the relevant content to the context). Another example would be that the system automatically adds all the web pages


IST 2001- 34244

that the user is reading during the meeting. A third example would be that the user later drops the pictures taken of the whiteboard over the meeting object. Five years later, the user remembers that there was a meeting, and the name of a person, and would like to find all the relevant content from the meeting. Therefore the person searches for the terms "meeting" and "person name.”. The system retrieves the meeting together with a list of the content items linked to it, which are business cards, a slide set, a few web pages, and some pictures of the whiteboard. As a result content can beneficially be accessed via the use of context-aware calendars. However, there are many more ways to implicitly present and interact with context objects for the users, because one can to some extent argue that many dialog boxes in a system can be regarded as describing a specific context.

5.2 INFORMATION PROCESSING VIEWPOINTS This section presents information on how to process content and context together in order to provide relevant content for ambient, personalised, and context-sensitive systems. This builds upon the static information structures that were presented in the previous section and contains the following information processing viewpoints:

• Information retrieval in general • Using context in context-aware information retrieval • Using context in personalised information retrieval • Acquiring and capturing contexts • The linking and matching of content and context • The matching and retrieval of similar contexts

The first three parts introduce the discipline of information retrieval and demonstrate how it contributes to dynamic extraction of relevant content. The next three parts exemplify the context gathering process as well as the process of how static linking and matching is supported by the architecture.

5.2.1 Information retrieval in general

This section is intended to survey overall concepts of information retrieval in general. It is beyond the scope of this document to identify and describe its techniques. These will be elaborated in more detail in the forthcoming deliverable D6. The Internet is the largest information resource in existence. The importance of finding relevant information becomes clearer when the enormous amount of web pages, books, journals, newspapers, audio, images, etc. is considered.

Figure 31: Information retrieval in general

In the simplest sense information retrieval is the process of matching the query against the information objects that are indexed (see figure 1). An index is an optimised data structure that is built on top of the information objects allowing faster access for the search process. The indexer tokenises the text (parsing), removes words with little semantic value (so called stop-words) and unifies word families (so called


IST 2001- 34244

stemming). The same is done for the query as well. Users express their information need as a request and it is formulised as a query for the retrieval system. The information system responds by matching information objects, which are relevant to this query. Information retrieval focuses on finding relevant information rather than simple pattern matching. It is also important to note that Relevance is a subjective notion since different users may make various judgments about the relevance or non-relevance of particular documents to given questions. A retrieval strategy (model) is an algorithm and related structures that takes a query and a set of documents and assigns a similarity measure between the query and each document. This similarity represents relevance to the user query. Documents are then ranked based on their similarity to the query and presented to the user. This process can be repeated and the query can be modified. Figure 47 depicts the concepts that are usually provided by an information retrieval system.

Figure 32: Information retrieval processes

Information retrieval has a number of models. The three main models are the Boolean Model, the Vector Space Model and the Probabilistic Model. The Boolean model is built on binary relevance (documents are treated either as relevant or non-relevant). It uses exact match search strategy based on Boolean expressions (like AND, OR, NOT). The vector space model maps both query and documents in a vector space and uses spatial distance as similarity measure. On the other hand, the probabilistic model estimates document relevance as probability using user feedback for iterative improvement. Both the vector space and the probabilistic model support ranking. In practice, pure information retrieval models can hardly be found as implementations. Google (www.google.com) for example is based on a vector space model with an incorporated Boolean query language. Information retrieval requires huge storage spaces and computational power since pre-processing of documents and related model computations can be highly resource demanding. Searches of relevant document from storage units and indexes require computationally effective and efficient algorithms. Much of the research and development in information retrieval is aimed at improving retrieval efficiency. Usually precision and recall are used to measure effectiveness. Precision is the ratio of the number of relevant documents retrieved in relation to the total number of documents retrieved. Recall is the ratio of the number of relevant documents retrieved in relation to the total number of relevant documents. One important initiative towards information retrieval evaluation is the Text REtrieval Conference (TREC). Its purpose is “to support research within the information retrieval community by providing the infrastructure necessary for large-scale evaluation of text retrieval methodologies.” A TREC workshop consists of a set of so called tracks. A track creates the necessary infrastructure (test collections, evaluation methodology, etc.) to support research on its task. The tracks also demonstrate the robustness of core retrieval technology in that the same techniques are frequently appropriate for a variety of tasks. Some of the tracks are as follows: Cross-Language Track, Filtering Track, Interactive Track, Question Answering Track, Web Track and so on. Further information can be obtained from http://trec.nist.gov/ .


IST 2001- 34244

Context-aware and mobile information retrieval are emerging fields, though sufficient studies and investigations on user behaviour and retrieval strategies aimed at this field are not done yet. The challenges of this new environment are manifold. The information that is consumed in the mobile environment is different in nature. This difference has an affect on the way information is retrieved. User feedback as part of the information retrieval process needs to be less obtrusive and integrated. Accuracy is more important since users do not want to browse large lists or simple do not have the time for that.

5.2.2 Using context in context-aware information retrieval

Today, the main problem confronting ambient computing filed is the information provision. For a decade, context-awareness has become a critical part of mobile computing. Being mobile brings the challenges of information need, typically a consequence of the situation, in which the user is involved or because of context changes. However, usually the crucial concept “content” (which the context awareness is exists for) is forgotten or less considered when such systems are designed. Context aware systems are means of “support” for meeting the information need in the user’s changing situations. Context is a bridge between knowing the mobile user's current situation, and delivering related content to that situation. Providing the right information at the right time requires various considerations and robust techniques from the information retrieval discipline. The targeted context aware system should be considered in a much broader vision including content repositories/management, effective retrieval strategies and placing them in the core of the system. Content service providers should not be neglected (since they know the nature of Content) and should be involved in the process, thus giving strength to context aware systems Conventional content repositories are built on the assumption of users not being a part of a mobile system in daily life. Daily life interaction and subsequent information needs are instant by nature. The system has to examine various behaviours and features of the collection of users in order to identify relevant content. In order to provide the best cognitive support for the user, the system must observe and model the user’s internal and external states. We should also bear in mind the constraints of the ambient context sensitive systems together with information retrieval when looking for a solution for information provision.

• Context changes rapidly and continuously, thus information seeking and matching is continuous

and proactive as a background activity. • Not every context change necessarily means an information request; user behaviour should be

identified and considered in that particular “application domain”. Typically, this brings the problem of “intrusion” into the user’s activities when the user doesn’t want any information. The system should not interrupt foreground activity unless explicitly specified.

• When proactive information provision is allowed, the user’s trust of the system also can be broken easily when unrelated items are displayed. The information is regarded as a “critical incident” and will be consumed immediately by the user. The system must only provide appropriate information, which requires a high precision of information selection.

• The system requires fast retrieval. The user should not have to wait as a result of retrieval process. • When mobile, the information that is provided will be displayed in a limited screen size. Device

limitations should be considered from the “information visualization” point of view. Is it possible to display all the results? Even if so, what portion of information gathered should be provided in order for the user to understand and reason whether the content item is relevant or not?

• Unless it is a domain specific application, which maintains its own information structure, application developers will face a high volume of unstructured and dynamic content that needs to be processed. The nature of the content may suggest various possibilities for processing.

The following figure shows the information retrieval processes as general with respect to using context.


IST 2001- 34244

Application developers should consider the “capture and representation” issues and furthermore the “form of matching” with respect to representation of both content and context. There are three general directions that can be followed: Context linking, structured content matching, and unstructured content matching. Contextualization of content can be done by linking contexts to content items and/or info packages. Context and content linking can be seen as an abstraction mechanism that allows information objects to be contextualised while residing in the content base. This approach is a mechanism to reorganize, link and view information from different perspectives. Content can be designed and organized by the content author to pop up in certain situations. The system designer should bear in mind the implicit contexts created by the author during the editorial process of creating content. Stylistic issues of the content should be examined and document contexts should be considered. The user context is matched with a “context attached to a particular content.” This approach is also referred to as Context Triggering. When the context attached to a document matches the user context then the document is presented. The “Linking and matching of content and context” section will give more details about this context-content linking. There lies a significant difference between context triggering and information retrieval. The context linking approach needs intensive human effort, although automatic tools may also be used which attaches context according to some rules and under certain conditions the particular information can be presented to the user. Structured matching is particularly suitable to a domain where the content is relatively small in volume and structurally well organized by experts. Context attributes and content fields (tags) can be mapped to each other for value matching. This approach can increase retrieval speed and, if well designed, accuracy can also be improved. For unstructured retrieval, the developer should consider how to use context in information retrieval strategies to get the right content into user’s device. The following are four possible approaches for effective retrieval:

1. Context itself is used as the query: attributes and values are used for the query formulation 2. The query can be extracted from the context by using various inference techniques 3. The query can be explicitly stated by the user and can be amplified by context 4. Information retrieval system can be developed in such a way that contexts are treated specially and

are matched against information objects by developing similarity measures. The first approach treats the context as the query itself without doing any pre processing. The second approach is convenient when the user gives no explicit information request. Context attributes and values are well populated and a query is derived. The context may consist of an enormous and diverse set of attributes. Inference should be made whether the information need is related to current, past or future contexts. It can be difficult to differentiate these requests in which context they have been made. For example, being in a particular location, which is captured and set in the user’s current context as a value,


IST 2001- 34244

may not mean a particular information need for this location. The user might query another location as an interest that can be a part of the context future. In this respect, it is also useful to bear in mind that context may be followed by some other rapidly changing contexts. In these circumstances, the source context should be traced to where the need is formulated. In the third approach the query is pre-processed and context attributes/values are used to amplify it. This approach may be needed when context attributes are scarce and the user is using a search tool (Pull). It is important to note that the user’s context is not always treated as the query. The fourth approach utilizes diverse structures and constructs together. Different aspects and techniques should be used. It may be a bit time consuming if comprehensiveness and abstraction is required. All these approaches should be considered together with performance factors with respect to content repositories, retrieval systems and the form of capture of context attributes. The performance depends on how context is formulated and what information retrieval strategies are used. The developer is strongly advised to consider the affects of context attributes and dependency upon each other. In certain situations, particular attributes can be dominant and more deterministic than the other ones. So this feature should be reflected to the retrieval system by means of some weighting functions. The query may be derived from highly weighted attributes or alternatively a proactive approach is chosen. The contexts attached to the information object can be searched proactively according to these highly weighted attributes. The matching score or similarity can then be calculated. Usage of a rule engine can increase effectiveness for explicitly specifying weights of context attributes and the conditions for context triggering. Although the first two approaches described have several features in common, the results they produce may differ because of the additional strategies used by each approach. Another approach might be to use context variables indirectly to rank the results of the system. A system may emphasise the usage of location attribute rather than others and do the matching on it. Despite the fact that results can be relevant conceptually, the ranking might be considered as the “physical closeness to a particular location.” Thus, the relevance can be interpreted differently in some circumstances. It becomes important to know the characteristics of each variable in the context and the requirements of the intended application will reveal their usage. Regarding the “physical closeness”, taxonomy is well used for granularity checking in this sense. Since the users are mobile, it is likely that relative information needs will be correlated with location they are in or are interested in. Location taxonomies therefore play a crucial part in identifying the granularity of information needed and can have significant impact. In addition, one might need to build taxonomy and/or synonym bases in conjunction to check whether other meanings of a particular term might be used in the context to describe the same or similar situations. Application developer should consider how to deal with these implicit descriptions. The general framework for the use of context in context-aware retrieval can be seen in Figure 33 below.

Figure 33: A content service with focus on context-aware information retrieval


IST 2001- 34244

5.2.3 Using context in personalised information retrieval

Personalisation as described in section 3.3.1, is about tailoring products and services to better fit the user. The main approaches have been identified in D1 – Requirements Report. Content-based approaches work with information objects whereas collaborative approaches work with user opinions and similarities between them. Information Retrieval is a content-based approach. AmbieSense personalisation will build on the top of information retrieval techniques and allow application developers to model the personalisation process rather than to fit in one existing process. A personalisation process maps a workflow of information tailoring stages. The following diagram illustrates the important components around the personalisation process and their connections with each other.

Figure 34: Using context in personalised information retrieval

The Content Service uses a personalisation process to provide information-tailoring services for its users. This process is instantiated by the content service and its workflow structure is highly dependent on what the content service wants to provide. This personalisation process applies user information modelled in the user context together with the underlying information retrieval methods to extract information objects from the content base. One or more indices are generated (presumably prior to this point) and optimised dependent on the retrieval tasks. The information request from the application is parsed, and common words which are too general for the domain may be removed from the query as it is inferred that they do not contribute to the retrieval process. Word families can be reduced to their stem using a method called stemming. The query is composed and the matching with information objects is performed. The results are then ranked according to their similarity to the query and presented to the user. These steps can be repeated and the query can be modified and developed to improve retrieval performance. All this is modelled in the personalisation process. User context in the personalisation process User context is a key element in any AmbieSense personalisation process. User context has many facets and can contain information about social connections between people, user tasks, personal context, and information about the environment as well as spatial and time related context information. From all these context attribute groups situated in the general context information structure, the personal context is of most importance for developing personalisation processes. This is because it contains information about the user


IST 2001- 34244

himself in the most direct way. This is the reason why personal context is the most important source for retrieving personalised information for the user. Attributes from the personal context can be used to augment each information retrieval step in the personalisation process. Exploiting personal context attributes transforms the wider context-aware information retrieval process forward to the personalised context-aware level to make the information retrieved individual. The following list shows some more general ways of how personal context can be used in the process of personalised information retrieval:

• Indexing: An index can be generated based on personal context. Contextual attributes can be integrated as additional information in the index structure. Query logs can be analysed statistically to determine which context attributes could be integrated in the future. This can speed up access as well as improve recall in future personalised queries.

• Parsing: Parsing is strongly related to index and query generation because it is usually performed to “clean” the content for indexing or the query before matching it with the content. Personal context can be used to perform user group based parsing. The parsing process would then be different for each of these user groups. With this technique it would be possible to implement different personal views to the content. The tokenising style, usage of stop-word list and stemming could be adapted to the user group based for example on the type of user (e.g. backpacker or business traveller).

• Matching: The choice of search process can be adapted to the demands resulting from the personal context. If for example, the user is under stress, a quicker search process can be triggered. If the user is in a more relaxed mode the comprehensive search method could be used.

• Query generation and modification: Personal context attributes can be used directly as queries. Attributes with a very strong indication for relevance, like user interest, are particularly good candidates for this. Combinations with other context attributes can refine and focus the matching process. Boolean expressions between one or more context attribute values like the Boolean AND can be used to improve precision. The Boolean OR can improve recall of relevant information objects. Query modification can extend existing context-aware queries with personal context attributes.

• Ranking: Personal context can help to rank the retrieved list of information objects according to the user’s priorities. Rather then filtering out entities, ranking can be less restrictive and still leave the user the option to look up some less relevant items later on.

This list is not intended to be exhaustive and the use of each part depends greatly upon the content service it is made for. One example, using some of these possibilities, is given below: Example of user context in the personalisation process - The city event content service The content service could be a city event service, which provides city leisure-time event information for travellers provided in a structured form. In this case, the content accessed is a set of up-to-date city events. The content service uses a personalisation process made to retrieve relevant city events for its users. The index is optimised for accelerated access of today’s events enabling faster retrieval. The query is composed with keywords from the user interest attribute organised within the personal context of the user context. Common event domain related words (stop-words) like “event” or “attraction” are removed from index and query since they are too general and do not add any value to the retrieval performance. Word families are reduced to their stem. The parsed query is automatically expanded with closely related terms from a special thesaurus for the event and news domain and combined into a Boolean search expression. Matching is performed by using a search method. For our event service, a search algorithm optimised for the event data structure is used, perhaps combined with document clustering to find closely related events. The search algorithm used depends on the user stress level context attribute. If the stress level is high (organised as an attribute of personal context) a simpler but much quicker search algorithm is used to produce results, ore rapidly. Query expansion with user feedback is only performed if the stress level is low. The results are ranked according to their similarity to the query and presented to the user. The ranking is influenced by


IST 2001- 34244

contextual attributes. If the user is in tourist mode and have not been to the city before, “must-see” events are ranked higher than other events. The example thus shows how personalised information retrieval can both be adapted to one domain and connected and augmented with personal context.

5.2.4 Acquiring and capturing contexts

In AmbieSense, the goal of acquiring and capturing context is to add value for end-users and/or the content service providers. Both people and software can acquire and capture contexts. The context template is central to defining how the context technology can be integrated with the content repositories of the content service. Acquiring contexts by creating context templates The application developers of the involved software house (e.g. the search engine provider), content service provider staff, or other content experts (such as librarians) should create the context template for the content service that will be made context-aware. If possible, one should ask existing customers to fill in questionnaires to elicit their information needs related to various situations in which they would like to access the content service. A good way to create a context template for an application is to base it upon data generated and maintained by the search engine of the content service and/or content management system. A search engine typically produces:

• Indices for the terms found in the content • Word-lists and stop-word lists • Ranked terms found in the content (e.g. occurrence, frequency, usage etc.) • Meta-information about the content (e.g. topics, categories) • Queries from the users

Having knowledge about these, an application can automatically suggest links between content and contexts. For instance, some of the ranked terms can be specified by the application developer to be part of a value set (see context template) for an attribute of a context template. Content can then be analysed for the terms, which are equal to one or more of the values from the value set. If there is a match between the value of a context and one or more terms, a link can either be proposed or automatically registered by the system. However, if one as the context template developer don't have such information available - either because one doesn’t have a search engine, or because the search engine provider discloses the information - one can still create a context template that can be useful. The clue then is to think about the various types of situations where content should and should not appear in. Capturing contexts by software and user input Capturing context should always be regarded as extra overhead for both software and end-users. The ideal situation is that content repositories are self-organising mechanisms capable of providing the end-user with appropriate information at any point in time. This is, however, rarely the case in a content service where the amount of content and the user population is large and diverse. We argue that larger content services have so many individual information needs to be meet, that they are only partially able to satisfy each individual customer. As a result, the content service limits itself by the nature of the content and how it is organised. In this way context can be used to satisfy a greater percentage of the information needs, and hence enable the content service to scale up further in terms of users and content. Both software and people can use context templates to capture contexts while the application is being used. People generally prefer to have software or sensors to fill in as much of the context attributes as possible.


IST 2001- 34244

An example of this is the AmbieSense project's own tag context, made to enrich/fill in the user context as automatically as possible when the user encounters a new situation in the vicinity of a context tag. Note, however, that the manual approach to inputting values into the various context attributes is not necessarily a problem. For example, a professional photographer can index his hundreds of digital pictures taken at a certain sports event by creating and editing one context for all pictures, an extra context for a subset of the pictures, and two individual contexts for two respective images. Note that his motivation for filling in the extra contextual information regarding the pictures is to make the pictures searchable for himself and perhaps his employer. Hence the individual information need should be the motivation that makes users of context-aware services manually input contextual information. As long as the context structure is useful for later retrieval or content sharing purposes then people will fill in the context’s contents. The only obstacle is to find the best way to do it in the user interface in terms of interaction, usability and usefulness. In summary, one can achieve this by to following user interface design principles:

• Embed the interaction with context at places in the user interface where meta-information about the content already is being input by the users

• Make additional views to the content which focus only upon context and content linking • Use another metaphor for context in the user interface (e.g. visualise contexts as activities in a

personal calendar – see earlier this chapter) • Make the users aware of contexts as an information structure they must edit (e.g. add a menu

called "Context" to the menu bar of the application with menu items like: "New...", "Properties...", "Link to...", "Delete..." etc.)

5.2.5 Linking and matching of content and context

AmbieSense is about bringing relevant information to a situation (context). One way to achieve this is to establish links between individual contexts (e.g. user context, tag context) and to content. We suggest the use of several types of links, all of which can relate contexts to content in order to extend the possibilities for the matching of content and context. Hence context and content can be linked to each other in the following ways:

1. A context can be linked to content items 2. A context can be linked to info packages 3. An attribute of a context can be linked to content items 4. An attribute of a context can be linked to info packages 5. The value of an attribute of a context can be linked to content items 6. The value of an attribute of a context can be linked to info packages 7. A content item can be linked to content items 8. An info package can be linked to content items

How the search can be done by using links? Given a context-aware content service that includes a content base, and a context space, the user queries the content service at a certain point in time. The content service then starts a matching process, where it searches the content base and/or the context space. The intermediate result is a list of matching content and/or contexts that match. The result is then the sole basis upon which to retrieve the set of links, which are then sorted and returned to the user and presented as relevant content (see figure below).


IST 2001- 34244

-from: entity-to: entity-relevance: number

Link

ContentBaseContext Space

Content Service

Matching

User Query

Figure 35: Linking and matching of content and context

Note that links must be given a relevance rating when they are created. The data type of the relevance should normally be a number; relevance should never be changed, because the relevance is the only reason that the link is created. Only the link itself should be deleted once it is found obsolete. The relevance between a context and content (see 1-6 in the above list), and furthermore from content to content (see 7-8 in the above list), can be computed in the following ways:

1. Automatically when indexing the content 2. Manually by the end-users 3. Manually by the content service provider

The linking mechanisms open many new ways to find relevant information, all of them based upon the use of contexts and their links to content. See below for two examples regarding how one can search for information via the use of context: Example A – finding relevant content via context via links: A user queries "Scotch whisky shop" on the mobile computer. The search engine (matching) first looks up in the context space if there are any contexts with the values "whisky" and "shop". It finds three contexts with "whisky", and one context with "whisky" and "shop". The search engine then looks up to see if there are links from these contexts (at context, attribute, and value level) and to some content. It finds ten links to content items and info packages, sorts them according to the relevance specified in each link, and informs the user about the search results. Example B – finding relevant content via topics and links: The computer shows a halibut and a fisherman on the screen, and the user queries "halibut" and "restaurant" on the mobile computer. The search engine (matching) first looks up in the context space if there are contexts with topics "halibut" and "restaurant", then searches for the same topics in the content base. It finds five contexts, seven content items, and one info package with both topics included. It then finds all links that involves the contexts, content item, and info packages, sorts them according to relevance, and presents the result to the user. The word ‘halibut’ is stored with the stem word ‘fish’, so the results presented to the user include details of several fish restaurants nearby.


IST 2001- 34244

5.2.6 Matching and retrieval of similar contexts

With the use of the AmbieSense context structure, content can be retrieved without the use of standard information retrieval techniques. The condition that must be satisfied in order to enable this is that there exist links between contexts and content. Retrieval of relevant content can then be achieved via the matching of user queries directly with the contexts. If there is a match between the query and some contexts, the links from the contexts can be followed and the result is that the user can retrieve all the content related to the contexts satisfying the query. Another way to retrieve content is via the sole use of context matching – in other words not by the use of any information retrieval technique at all. For example, a user declares what he wants by specifying an incomplete context or a query like "find content of similar situations like this". This incomplete context is matched with other contexts. The system retrieves a set of similar contexts, and presents all the links to content from the retrieved set of contexts. Again this assumes that links exist between contexts and content. A third way is to let the user specify a complete context as an example context to the system. The system can then find more or less similar contexts stored in the context space above a certain similarity threshold. The content related to the resulting set of similar contexts are then retrieved and presented to the user. Assuming, however, that there is one context space on which the computer is accessed and used by several applications, a context should only be compared with other contexts of the same type and application. If any type of context can be compared with any other type of context, we runs the risk of: 1) radically slowing down the context retrieval technique, and 2) comparing contexts that should never be compared with each other at all. The result can be the retrieval of completely irrelevant content, and subsequently the context technology that was supposed to help the user and/or content service provider is obsolete. Hence, the advice is to only match contexts of the same context template with each other.

5.3 DETAILED CLASS DESCRIPTIONS This last section in this chapter about the AmbieSense information structures presents the detailed class descriptions for the core classes and interfaces found in the UML class diagrams presented earlier in this chapter. Note that these class descriptions still at a conceptual level – and not implementation-specific although the syntax of the methods and attributes are Java, Pascal or C++ like. We chose to do this because the majority of software houses are familiar with these languages. Each of class and interface descriptions tables adheres to best practice UML notations and guidelines regarding how to model classes, interfaces, and associations at a semantic level – although we in most of the descriptions have actually proposed a Java or C++ like data types for the attributes, and the input and output parameters to the class methods. The project chose to implement these detailed specifications as classes and objects in Java.


IST 2001- 34244

Interface: Activity

Stereotype(s):

Definition An activity describes what an actor has done in the past, is presently doing, or will likely do in the future. Activities are often thought of as either happening at a certain point of time, or during a period. Sometimes one can say that an activity is recurring in subsequent points of time, or in periods. Other words for an activity are: event, to do, task, event, act, action, happening, phase, process, and so on. One can sometimes discuss whether an activity happens at a certain point of time, or if it has a more or less clear period. Example of this might be a milestone, a two hour-long meeting - or a 7-days travel. The milestone is more regarded as a point of time, the meeting with a shorter period, and the travel with a longer period. Activities are often referred to with names like "the travel to Brussels", "the meeting in October" and so on. Hence, people often describe their activities with ad hoc names. Also, people normally refer to activities as being of a certain type like: "appointment", "meeting", "dinner", "sleep", "travel" and so on. Describing a situation - or context - in terns of an activity seems to be frequent. It is natural to describe a situation as an activity. Examples are: "The situation in the airport", "the situation in the restaurant", and "when I was at home yesterday evening". Situations are therefore indeed related to a point of time, or to a (recurring) period. A context describes aspects of a situation. For these common sense reasons it seems therefore a good idea to describe contexts with activity as the metaphor. We therefore recommend that contexts can be rendered as activities to the user. Activities are often presented to people as activity lists, task list, things to do, part of calendars, or part of plans. Sometimes, a activity can be rendered having several subsequent periods or milestones – like in Gantt diagrams for instance. In summary, activities are more or less distinct in time. An event or a milestone has for instance a very small relative distance between the start and the end of it, while other activities are relatively long but diffuse like the period "October - November 2003". Some activities or events can be described as recurring and precise to the minute, regarding the start and stop time - like the lunch at 13:00-13:30 every workday.

Methods Return type, name and attributes Definition String GetName () Returns the name of the activity. Examples can be "the travel to

London", "Project meeting", "The Nova Bar" and so on. Void SetName (String theName) Sets the name of the activity String GetType () Returns the type of the activity as a string Void SetType (String theType) Sets the type of the Activity. Examples can be: "appointment",

"meeting", "travel", "eat", "do", "walk", "sleep" and so on. Period GetPeriod () Returns the overall period of the activity. A period has a start and

a stop date, which might be accurate down to the millisecond. The start and the stop date might be the same as per a point in time.

Void SetPeriod (Period thePeriod) Sets the period of the activity with the start and stop. Void AddPeriod (Period thePeriod) Adds a period to the activity (e.g. a recurring period) Void RemovePeriod (Period thePeriod)

Removes a period from the activity (e.g. a recurring period)


IST 2001- 34244

Associations No. Role Target Cardinality 1. An activity can be part of zero or many calendars (plans/activity lists) Calendar 0..* 2. A context can be regarded as an activity. (The context implements

the activity interface. The context can be regarded as a kind of activity).

Context 1

Implemented by classes Context


IST 2001- 34244

Class: Content

Stereotype(s):

Definition Content is a group of physical files or folder arranged in a logical manner and can be accessed via URL that is found within the Content Item (see class Content Item). These logical groups can be a single piece of content (a text file or a picture) or a collection of those thematically coherent (e.g. a map with textual descriptions of points of interest). Content exist both with and without the Content Items. However, one can argue that content will remain quite locally distributed and more locally used in an ambient and context-aware application - in practice. Examples of Content are plain text files, word-documents, mpeg-files, data-records in databases, digital travel guides, e-books, and personal pictures.

Attributes Name and type Definition FileName: String Name of the file.

IsFolder: Boolean An indicator whether the URL pointing at is a folder or a file Attributes : Hash Table Attributes of the content Input : Stream Input Stream to read the content's of the file. Output :Stream Output Stream to write the content's to a file. Certificate Certificate for the content. Size : Long Integer Size information about the content.

Associations No. Role Target Cardinality 1. A Content can be linked to zero or many Content Item Content Item 0..*

Generalisation

Super-class N/A

Sub-classes N/A

Implemented interfaces N/A


IST 2001- 34244

Class: Content Base

Stereotype(s):

Definition A Content Base is an abstraction to facilitate the maintenance of Content Items, Info Packages, and their collections. This can be regarded as a distributed content repository where content, Content Items and Info Packages can be retrieved and stored independent of the underlying systems via read or written input/output streams. This gives flexibility when the system components are distributed, and consist of heterogeneous content repositories. This class should also be regarded as a both a distributed and a virtual file system. Hence, think of it as virtual content repository that gives access to content independent of the underlying file- or file-system types from anywhere in the world to any content in the world. It basically contains Content Items and Info Packages that point to the physical content with a URL. Hence, the actual content can be stored any place in the world as long as one can identify it with a URL.

Attributes Name and type Definition ID: Integer Unique identifier for this Content Base. User :User The user name to use the Content Base. Password: String The password to use the Content Base. FileSystem: URL File System Name, which the Content Base uses.

Associations No. Role Target Cardinality 1. A Content Base can store zero or many Content Items Content Item 0..* 2. A Content Base can store zero and many Info Packages Info Package 0..* 3. A Content Base can be used by zero or many Users User 0..* 4. A Content Base can be associated with zero or many instances of

Content Service Content Service

0..*

Generalisation

Super-class N/A

Sub-classes N/A



IST 2001- 34244

Class: Content Item

Stereotype(s):

Definition The Content Item conveys the necessary administrative and descriptive meta information that enables the retrieval, storage and search of particular pieces of content. Content Item attaches identification and management information to content. The Content Item exists because of the following reasons: 1) Unfortunate effects if changing the content. Data like digital pictures, music, and videos, for instance, are difficult to index and search for by the computer without requiring the exhaustive use of several intelligent techniques for image, video and, sound and voice recognition analysis. Sometimes it can be unfortunate to change the actual content itself, due to increased costs, technical side effects, or digital rights problems. 2) Ambient and universal access. Content is owned by individuals or institutions, and in general can exist at any computer in the world. In order to provide ambient and universal access to these distributed Content Bases, one should have a common way to access the diverse file types and files that exist around the globe. In that case, it seems suitable to define a Content Item as a means of encapsulating any kind of content, and let it refer with a URL of the actual content itself. Moreover, it is extensible. 3) Contexts can be linked to content without changing the content. Some content that might not easily be indexed can be still indexed and made searchable by the explicit use of context structure as describing the content itself (e.g. files, emails, free text). There can be directed links from a context to content. However, the content might move around internally in a computer or to another computer - and the protocols for accessing the content might change (e.g. http, https, or ftp). For maintenance reasons, it would therefore be easier to update an indirect reference to actual content itself. The Content Item can be regarded as an indirect reference to the content – i.e. a URL is one attribute of the Content Item. In general, it is easier to also maintain the links to the contexts because only need to establish links to Content Items instead of several protocols, file types, access rights, input/output streaming of the physical content etc. A content item can have zero or more topics, which a search engine might fill-in automatically, or a content author might specify after developing the actual content (see the Content class above). Content Items are authored by content authors and likely owned by content provider, which is responsible from quality of the content. It provides functionalities to manage access periods and usage rights of particular content. Content service providers can store Content Items in the Content Base and choose to pack them into Info Packages, which then can be delivered to the users.

Attributes Name and type Definition Type: String Type information about the Content Item. Some possible types might be News,

Events, infotainment, offer, brochure, map, shop, point of interest, Airway company, Lounge, My Flight, Today's Flight, Eat, Stay, See & Do, Shopping, Entertainment, place of interest and so on. The types should be defined by the application developer.

Topics: String A string of topics that describe the Content Item (can of course another data type than string of needed).

Content URL: URL URL to content.


IST 2001- 34244

Date Created Date of creation. Date Modified Date of modified. AccessPeriod: Period Period, which this Info Package can be consumed. Owner:String Owner Information. Copyright URL: URL URL to copyright information. Original: Boolean This attribute identifies whether this Content Item is original or not. Interest Rating: Integer Rating information about the Content Item.

Associations No. Role Target Cardinality 1. A Content Item can contain one Content Content 1 2. A Content Item can be a part of zero or many Info Packages Info Package 0..* 3. A Content Item can be stored in a Content Base Content

Base 1

4. A Content Item can be associated with zero or many instances of Context

Context 0..*

5. A Content Item can be part of zero or many content services Content service

0..*

Generalisation

Super-class N/A

Sub-classes N/A



IST 2001- 34244

Interface: Content Service

Stereotype(s):

Definition A content service accessed via a mobile computer is a bundle of system components offered by the content service providers to their customers that in total utilises the distribution of content. Users (and software/agents acting on behalf of them) can subscribe and have access the content services either for free or according to a certain payment model. The mobile computer is either borrowed from the content service provider by the customers, or owned by the customers themselves. Ambient content services can be realised in terms of AmbieSense by integrating: a set of context tags, a user community, a content base, a context space, a search engine, push/pull technology, and software available for installation on the mobile computers. Hence, each content service provider should provide the following interface for the mobile computers:

• Available context space • Available content base • Available context tags • Available information zones • Available search engine • Available push/pull • Available application software for installation • Information access for users and user groups

Available push/pull technology can be accessed utilising the methods for distributing the content between the content service providers and customers. Available application software is also available for installation and information access purposes.

Methods Name, attributes, and return type Definition GetName() Returns the name of the content service. GetType() Returns the type of the content service. GetProvider() Returns the name of the content service provider. GetAgreement() Returns the agreement text for accessing the content of the

content service, installing and using the involved software etc. GetContextSpace() Returns a reference to the available context space of the content

service. GetContentBase() Returns a reference to the available content base of the content

service. GetContextTags() Returns a reference to the set of available context tags that

provides access to the content service. GetInformationZones() Returns a reference to the available information zones of the

content service. An information zone is linked to a context tag. GetSearchEngine() Returns a reference to the available search engine that supports

searching for relevant content within the content base. (Sometimes a part of the content management system).

GetPush() Returns a reference to the available push service of the content service. (Sometimes a part of the content management system).


IST 2001- 34244

GetPull() Returns a reference to the available pull service of the content

service. (Sometimes a part of the content management system). GetApplicationSoftware() Returns a reference to the available application software. Allows

the installation of application software and access to the content service.

Subscribe(User, Boolean) Subscribes/ un-subscribes a user from the content service. Include(User, User group, Boolean) Includes a user to a user group, or un-includes the user from the

user group. SignIn(User, User group, password, certificate)

Signs in a user to the content service.

SignOut(User, User group, password, certificate)

Signs out a user from the content service.

Associations No. Role Target Cardinali

ty 1. A content service maintains zero or more information zones Information

zone 0..*

2. A content service can be distributed on zero or many context tags. In case of zero tags the content service is centralised and not available on the tag.

Context Tag 0..*

3. A content service can provide access to zero or many context spaces – both its own and the customer's context space.

Context Space 0..*

4. A content service can provide access to zero or many content bases. Content Base 0..* 5. The content service can have zero or many users User 0..* 6. The content service can have zero or many user groups User group 0..* 7. The content service can implement several push and pull mechanisms

for content distribution. Push/Pull 0..*

Implemented by classes N/A


IST 2001- 34244

Class: Context

Stereotype(s):

Definition A context can be defined as a description of aspects of a situation. Context is a data structure, which is capable of describing the aspects of an everyday situation for an actor, whether it is for humans, natural species, software, or hardware. The context is describing the aspects of the situation seen from one actor’s point of view. Context can be argued to always have a time span – although sometimes the period of the context might be more or less unclear. Context might therefore be presented to a person as something that is related in time. Therefore, in many applications one can choose to present a context as a kind of activity; with a specific name and a period with a start and a stop time. It will be impossible to define a context structure that is common for all context-aware applications. However, it is still possible to define something that can be common for all contexts: A context can have attributes and sub-contexts. Additionally it should have links to content, because context should be able to capture/identify the available information/data resources in the situation that it describes. In software applications, this is either software or hardware, but most importantly the information (content) that occurred in the situation. Therefore, it is possible to suggest a kind of Context Template that can be extended for more specific application purposes, to better meet the needs and requirements for the application user and domain. A context confirms to a Context Template and should be regarded as an instance of a Context Template. The only way to construct a context is to define a Context and use this to make the Context. The entire context structure (context with sub contexts) will all have a reference to the same Context Template. Every context in the context structure keeps a reference to a Context Template. Attributes in a context can have values. Values are either text or numbers. The values of an attribute can be constrained by the definition of ranges and value sets. A range is the range between two numbers. A value set is a discrete set of text or number values. There can be zero to many ranges or value sets constraining the possible values of an attribute of a context. These are defined in the Context Template. An example of an attribute can be “name”. The value of “name” can be “Naomi”. Another example of an attribute is “time of day”. The values might be constrained be the value set {morning, afternoon, evening, night}. In this day, one legal value of the attribute “time of day” can be “morning”.

Attributes Name and type Definition ID: String The ID of the context making this context unique and easily accessible by using

the specific ID Name: String The name of the context describing this context with as few words as possible Contexts: Contexts A context may consist of many context, these will be listed in this list. This list

will consist of Context object references. Attributes: Attributes Each context may have a set of attributes, those will be listed here Type: String The type or category this context is part of

Associations No. Role Target Cardinality


IST 2001- 34244

1. A context can be part of the context history, which can contain zero

or many contexts of the past. Context History

1

2. A context can be part of the context future, which can contain zero or many contexts upcoming contexts (for instance planned or anticipated).

Context Future

1

3. The context is describing the aspects of the situation seen from one actor’s point of view.

Actor 1

4. Context can in general be changed and used by any kind of software components

Software 0..*

5. A context can be linked to zero or many Content Items and Info Packages, which refers to actual content and business logic (e.g. various files and documents)

Content Item 0..*

6. When a context is changed, this can be observed by any kind of software component that would like to observe the change.

Observer 1

7. Context can in general be linked to zero or many content, just like it can be linked to the meta-level data structures for content that is called Content Item and Info Package.

Content 0..*

8. A context implements (is a kind of) an activity, so that each context has a period with a start and stop time, and a name. Activities can be part of zero or many Calendars. Therefore, a context can inherently be part of a Calendar.

Calendar 0..*

Generalisation

Super-class N/A

Sub-classes User Context Tag Context Other kinds of contexts…

Implemented interfaces Activity


IST 2001- 34244

Class: Context Space

Stereotype(s):

Definition The context space is capable of containing contexts based upon any kind of context template. This means that any kind of context-aware application can store, update, and retrieve their specific types of contexts from the same context space. It can have one or more users. The context history contains all past contexts. The context history contains contexts that have been created and explicitly stored in context history. The current context is automatically moved into the context history when a new context is set as current. The current context contains information about the current context. The current context is where applications get information concerning the current context of the involved entity/actor. Various context sources can feed information into the current context (e.g. people, sensors, software etc.). The context future is a set of contexts that systems or users can plan or predict. The context future contains contexts that are created and explicitly stored in context future. Note that the Context Middleware is the AmbieSense project's implementation of the Context Space (see [AmbieSense-D5])

Attributes Name and type Definition Current Context The current context is part of the context space. The current context is where

applications read and write the updated values of the context attributes (see Context class above). The user(s) and the application can access and change information of the current context.

ID Unique ID of a context space. Used to separate context spaces when several context spaces exist

Context history: Contexts

The context history is a part of the context space.

Context future: Contexts

The context history is a part of the context space.

Associations No. Role Target Cardinality 1. A context space can have one or many users User 1..*

Generalisation

Super-class N/A

Sub-classes N/A



IST 2001- 34244

Class: Context Tag

Stereotype(s):

Definition A context tag exists primarily in order to help mobile users automatically describe the various situations (i.e. contexts) that they encounter. It is meant to communicate important aspects of the surroundings. These aspects of the situation (i.e. the context attributes) enable the users to automatically link content to situations that they were, are, or will be in. The result is that they can search for content that existed in past situations, without having to do the time-consuming task of describing meta information for the content - for later retrieval purposes. Another achievement is that one can search for content without specifying terms that occur in the actual content, but occurred in the situation. Hence, the user can in general find content by stating "give me content that occur in that situation", as an alternative to the traditional way of stating "give me the content that contains these words", which assumes you know actual parts of the content. However, context tags can also be regarded as info tags, because content can be stored on some advanced context tags prior to the distribution of it to the user. Less advanced context tags can only have reference to content that must be uploaded from the wireless network by client software running on the handheld computer. Context tags are normally bought and installed by content service providers or physical infrastructure owners. Each context tag can be linked to one or more content services. Some types of context tags can have software (including agents) running on them, while more tiny context tags can have links to software resources in the network that might either be installed on the mobile computer, or be accessed via the wireless network. Each context tag can be hidden in furniture or be mounted visible in the surroundings, making the area around act like local and miniaturised information channels. It can be part of an information zone together with other context tags. Secure context tags can be achieved by adding and removing users and administrators to each context tag. With users we mean those who subscribe to a content service, or who should be able to access the tag. Each context tag has its own geo-position. This is described with a single geo-coordinate. The location of a context tag can also be described with text like "at home", "in the restaurant", "in the table" and so on. Advanced context tags can be administered from remote via the (wireless) network, while more simple tags must be administered locally when the administrator is in the vicinity of it. The administrator can set the vicinity of the tags. This can vary from approximately 30 metres and to a few millimetres. This proximity threshold defines the inner zone of the context tag, while the outer zone is limited to the signal hemisphere defined by the wireless transceivers at the context tag, and at the mobile computer. This may vary from 10-30 metres depending on the hardware used.

Attributes Name and type Definition Name: String Specifies the name of the context tag Description: String Describes the tag and the surroundings with text


IST 2001- 34244

geo-position: Geo-coordinate

Contains the current geo-position of the context tag. Any kind of geo-position should be given as a string that should be interpreted with the right geo-positioning software.

Location: String Specifies the location of the context tag by some text. Vicinity: Integer Specifies the vicinity radius from the antenna of the context tag receiver and to

the mobile computer. This threshold defines the rim of the inner zone. Note that connection between the tag and the mobile computer can exist even if the mobile computer is outside the vicinity. The legal value is an integer between 0..100, where 100 mean 100% pct signal strength and 0 means no connection.

IP address Contains the current IP-number of the context tag, if it is a client in a network. DHCP-address Contains the DHCP-address of the context tag, if it is has a DHCP server

installed to provide the mobile clients with IP-numbers. Connected clients A list of IP-numbers for the connected clients (mobile computers). The IP-

numbers are provided by the DHCP-server on the tag, if installed. Content Base A reference to the content base for the context tag. It can be installed locally on

the context tag, or remotely in the network Context Space A reference to the context space for the context tag. It can be installed locally on

the context tag, or remotely in the network Administrator: User Specifies an administrator for the context tag

Associations No. Role Target Cardinality 1. Content can be linked to/stored on the context tag, depending on the

features of the context tag. Content is usually stored in the content base.

Content 0..*

2. Context can be linked to/ stored on the context tag, depending of the features of the context tag.

Context 0..*

3. Software can run on/ be associated with the context tag, depending on the features of the context tag. An agent is a kind of software.

Software 0..*

4. Users and can be registered in order to connect to the context tag, depending on the features of the context tag.

User 0..*

5. A context tag is a part of zero or more content services. Content service

0..*

6. A context tag can be linked to zero or more information zones. Information zone

0..*

Generalisation

Super-class

N/A

Sub-classes

N/A

Implemented interfaces

N/A


IST 2001- 34244

Class: Context Template

Stereotype(s):

Definition The proposal is that contexts are made from context templates. This means that there can literally be thousands of contexts adhering to a certain context template. Context templates should be used in order to guide the creation and exchange of contexts both within and between applications. The application designer or programmer together with the content service provider should develop the context template. It can be viewed as describing aspects of a general/typical situation in which an actor/entity can encounter. A Context Template is used to constrain context representations. All contexts that exist in a context space must comply with a Context Template. Contexts are validated towards the Context Template. Context templates are different from the contexts, because contexts made during application use either manually by the user, or automatically by the system. Context templates can't and shouldn't therefore be linked to content at all. They also differ from contexts, because they constrain them regarding the structure of sub-contexts and attributes, in addition to constraining the set of legal value sets and value ranges for each of the attributes.

Attributes Name and type Definition Name: String Constrains that all contexts should have a name. Type: String Constrains that each context should have a type. Context Templates A Context Template can consist of sub context templates that the corresponding

sub-contexts of a context should be compared and validated with. Attribute Attributes can be part of a context template.

Associations No. Role Target Cardinality 1. ValueSets are used to constrain the set of legal values that an

attribute can have in a context. Value Set 0..*

2. ValueRanges are used to define the valid values of attributes that complies to a Context Template

ValueRange 0..*

3. Context Templates are used to constrain the structure of a certain type of contexts stored in a context space.

Context Space 0..*

4. A context template constrains a context. Context 1

Generalisation

Super-class N/A

Sub-classes N/A



IST 2001- 34244

Class: Info Package

Stereotype(s):

Definition The Info Package is a conceptual container for a collection of Content Items. Info Package defines and gives idea about properties and descriptions of Content Item collection, which are logically organized for a specific purpose. Thus, Info Packages and its content become easily discoverable from out side by this enriched Meta data. This information can be used to get: 1) Inside knowledge about content, 2) Usage rights 3) Usage Period. Topics, which can also be attached to give overall description and help searching, and retrieving to both the user and search engines. The information is aggregated and published by Content Service Provider, who can be a person or organisation offering a coherent set of information services and takes care of quality assurance of the content. This approach helps to facilitate the complete administration of a particular content’s lifecycle. The content service provider packages the content into Info Packages, associate them with a pricing model, security verification and Digital Rights Management facilities. In this sense, Info Package can be regarded as the business layer in the information hierarchy, which is the convenient way of managing different models. In it’s simplest form, this approach allows a content service provider to set price and usage rights on collections of Content Items. Info Package is delivered to the user free of charge or because of a purchase. The package can be used in a valid period of time, which is defined by the Content Service Provider as a part of the usage agreement. Hence, an info package can be regarded as a bundle of trading units at an info market, where content is the trading unit. Context can be linked to and Content Items can be added/remove and so on to Info Packages. These prepared Info Packages are stored, retrieved and maintained in the content base.

Attributes Name and type Definition Period Period, which this Info Package can be consumed. Topics A set of topics, which describes Info Package. Price Price of the Info Package. Currency This attribute specifies the currency for the price of the Info Package. Copyright URL URL to copyright information. Certificate Certificate for the Info Package Owner Owner of the Info Package Content provider Contains the name of the content service provider ID This is a unique identification number, which is assigned to each Info Package.

Associations No. Role Target Cardinality 1. An Info Package can contain zero or many Content Items ContentItem 0..* 2. An Info Package can be used by users. User 0..* 3. An Info Package can be stored in a Content Base ContentBase 1 4. An Info Package can be linked with zero or many of contexts Context 0..* 5. An Info Package can be part of zero or many content services Content

service 0..*


IST 2001- 34244

Generalisation

Super-class N/A

Sub-classes N/A



IST 2001- 34244

Class: Information Zone

Stereotype(s):

Definition An information zone refers to a physical zone in which some information should occur. The content service provider and venue owners normally decide this. It is geographically located by a geometric anchor point and a geometric shape. Providing information to locations and users, require the content service provider to know of and refer to the physical zone where the users will encounter. The context tags combined with wireless networks are in AmbieSense the vehicle in providing content to locations, situations, and users. This is why information zones can be linked to zero or many context tags or wireless networks. Ambient content service providers will give such information zones with names like "Room 232", "The business lounges" and so on. When a person need to update three context tags for an information zone, a description of the information zone would be needed to find the physical location. Secure information zones can be achieved by restricting the set of users and administrators that can interact with content in certain surroundings. An information zone is linked to some content. This relation could in practice be implemented either by linking the information zone to zero or many info packages and Content Items. An institution may purchase several context tags. Managing the context tags indirectly via information zones can be beneficially, because one is able to combine the context tags and other related equipment with wireless networks without tailoring any of those - except at the access level. Administering each tag individually would be cumbersome and have poor scalability. Hence, we suggest the information zones the central concept in managing digital content that should occur in specific physical spaces.

Attributes Name and type Definition Name: String Contains the name of the information zone. Description: String Contains the description of the information zone (e.g. pure text which might

describe the physical environment of the information zone). Area: Shape Captures the geometric area (shape) of the information zone. When a user is

within the zone, the content/information related to the zone should be distributed to the user. The area is always specified relative to the anchor point (see the next attribute).

Anchor point: Geo-code (String)

Captures the geographic anchor point of the information zone. It should follow one of the existing geo-code standards. The area (shape) of the information zone is specified relative to this anchor point.

Associations No. Role Target Cardinality 1. Information zones are maintained by the content service. Content

Service 0..*

2. An information zone is linked to zero or many context tags. Context tag 0..* 3. Content occurs in information zone Content 0..*


IST 2001- 34244

Generalisation

Super-class N/A

Sub-classes N/A



IST 2001- 34244

Class: Tag Context

Stereotype(s):

Definition A tag context is a type of context. Can be located on a context tag, and provides information of the context of that tag. A tag context in AmbieSense consists of four sub-contexts:

1. Environment context – this part of the tag context captures the entities that surround the tag. 2. Task context – this context describes what the persons (actors) are doing around the tag. 3. Social context – describes the social aspects around the current tag context. It can contain

information about people around the specific context tag. 4. Spatio-temporal context – this context type describes aspects of the tag context relating to its

spatio-temporal extent. It can contain attributes like: time, location, direction, speed, shape of the thing that the tag is mounted on, track, and place.

Attributes Name and type Definition Environment context: Context

Can contain attributes and new sub-contexts related to the environment/surroundings around the context tag.

Task context: Context Can contain attributes and new sub-contexts related to what persons (actors) are doing around the tag.

Social context: Context Can contain attributes and new sub-contexts related to the social setting around the context tag. It can contain information about people around the specific context tag

Spatio-temporal context: Context

Can contain attributes and new sub-contexts related to the spatio-temporal situation for the context tag.

Associations No. Role Target Cardinality 1. The tag context must be validated towards the general tag context

template. Tag Context Template

1

Generalisation

Super-class Context

Sub-classes N/A



IST 2001- 34244

Class: User

Stereotype(s):

Definition This class describes a user. A user has a password and a unique username. Adhering to security and privacy principles is important when building systems that are personalised and/or context-aware. The authentication of users and user groups, and the access control when using content, context, or software components is needed. Therefore it is necessary with a common understanding of what a user is and can do to access content in an application.

Attributes Name and type Definition Name The user's name Password The password of the user Login Login of the user Certificates The certificates of the user

Associations No. Role Target Cardinality 1. A user can subscribe to or access content, content items, and info

packages in zero or more content services Content Service

0..*

2. A user can own or subscribe to zero or more context spaces Context Space

0..*

3. A user can have access rights to software Software 0..*

Generalisation

Super-class N/A

Sub-classes N/A



IST 2001- 34244

Class: User Context

Stereotype(s):

Definition A user context is a type of context. The user context consists of five sub-contexts:

1. Environment context – this part of the user context captures the entities that surround the user. 2. Personal context– this sub-context consists of two further sub-contexts: the physiological context

and the mental context. 3. Task context – this sub-context describes what the user and the persons around are doing in the

vicinity of the user 4. Social context – describes the social aspects around the user. It can contain information about

people and friends etc. 5. Spatio-temporal context – this sub-context describes aspects of the user relating to its spatio-

temporal extent.

Attributes Name and type Definition EnvironmentContext: Context

Can contain attributes and new sub-contexts related to the environment/surroundings around the user.

PersonalContext: Context

Can contain attributes and new sub-contexts related to the personal context of the user. It already contains two sub-contexts, in which the needed attributes should be added. These are called the mental and physiological contexts.

TaskContext: Context Can contain attributes and new sub-contexts related to what both the user himself and other persons (actors) are doing around the user.

SocialContext: Context Can contain attributes and new sub-contexts related to the social setting around the user. It can contain information about persons around the individual user.

SpatioTemporal Context: Context

Can contain attributes and new sub-contexts related to the spatio-temporal situation for the user himself.

Associations No. Role Target Cardinality 1. The user context must be validated towards the general user context

template. User Context Template

1

Generalisation

Super-class Context

Sub-classes N/A



IST 2001- 34244

Class: User Group

Stereotype(s):

Definition A user group is a set of users that have common access rights to content, context, and software. This allows for more scalable access control. A user group should be created and users should be added to it if one needs to define the same the access rights for many users. An example of this can be that a context space should be available for a set of users, “my friends and me” for instance.

Attributes Name and type Definition Users A User Group will consist of potentially many users; they are collected in a list

with a reference to each user. ID Each user group has an ID that is unique Name Each user group has a name describing the group.

Associations No. Role Target Cardinality 1. A user can subscribe to or access content, content items, and info

packages in zero or more content services Content Service

0..*

2. A user can own or subscribe to zero or more context spaces Context Space

0..*

3. A user can have access rights to software Software 0..*

Generalisation

Super-class N/A

Sub-classes N/A



IST 2001- 34244

6 Appendixes

6.1 CONTACT INFORMATION Name of Institution/Organisation Postal Code / City Country

SINTEF Telecom and Informatics NO-7465 Trondheim No

Name Mr Hans Inge Myrhaug Address: SP Andersens vei 15

Tel: +47 73 59 70 72 Fax: +47 73 59 29 77

E-mail: [email protected]

6.2 GLOSSARY Access point Any connection to AmbieSense Services, typically a Context Tag

Actor An actor is a human part of the system.

Agent “A program that performs some information gathering or processing task in the background. Typically, an agent is given a very small and well-defined task.” (http://www.webopedia.com/TERM/a/agent.html)

Ambient Intelligence Infrastructure

Technical infrastructure to enable intelligent ambient systems.

AmbieSense system The overall goal of the AmbieSense project: A system offering personalized, context sensitive information services to mobile users

AmbieSense system concepts

The concepts that are found vital for the AmbieSense system. The four system concepts are: content, context, users, and context tags. A fully implemented AmbieSense system will always contain these concepts.

AmbieSense Technology The core technology providing a platform for the AmbieSense context-aware products and services

Component The physical entities in the AmbieSense system

Concept An abstract entity and role in the AmbieSense system

Content Any data that the user can download to his storage on the mobile device. We here often think of content as what the Content Providers create as part of the AmbieSense system, although any data on the PDA and in the information-space really is content.

Content Author Author of content items

Content Item The Content Item conveys the necessary administrative and descriptive meta information that enables the retrieval, storage, and search of particular pieces of content. Content Item attaches identification and management information to content.


IST 2001- 34244

Content Management System

A system that manages content. In the case of AmbieSense, the emphasis is on integrating content from different sources (publishers/authors) by developers/editors.

Content Owner Legal owner of content items, responsible for quality of content

Content Provider Person or organization hiring the Content Author

Content Service Provider Person or organization offering a coherent set of information services

Context A context can be defined as a description of aspects of a situation. The period of a context can range from being a very short moment to many years. It is possible to identify several types of contexts depending on your application needs. A context as an internal representation in the computer should be a structure of data and information units. It is also natural to refer to contexts that are more or less similar to other contexts. See chapter 2

Context change trigger A condition that causes a change in context.

Context History The sum of contexts a mobile user has been subject to in the past. The context history holds all previous contexts the user has been in, and the context future stores possible future contexts in which the user may experience.

Context intrusion Change of context from one to another by the effect of external factors or triggers

Context Management System

A context management system deals with collecting any particular form of context, creating new templates, matching, managing and sustaining the interactivity with context space (past, current and future context) which will support and enhance content.

Context sensitivity Akin to reacting to its environment. An example is a news service that gives you news depending on which country you are in

Context sharing Having identical or similar contexts or having shared a context with other people

Context space With context space, it is meant the complete set of contexts that is stored together in an electronic repository. The context space can be viewed as a database of past context, future contexts, and the current context.

Context Tag The context tag is an entity that enables the binding of location to a context (or a set of contexts). A context tag may be a concrete computer running software or just the software itself.

Context Tag Administrator Technical administrator of one or more Context Tags

Context Template A set of common user tasks that are believed many users within the same area would like information on. On an airport people usually arrive, depart, pick up people or are in transfer. Common needs amongst departing people can be structured together in a context template, making search for valuable information easier.


IST 2001- 34244

Context-sensitive services Information services in AmbieSense, that provide context-aware distribution of information to mobile users

CORPORUM CORPORUM is a generic name for a group of products supplied by CognIT a.s, helping to increase access to and the sorting of relevant information. CORPORUM uses advanced language and knowledge technology developed in Norway. This technology is based on the semantic analysis of text and cognitive models. (http://www.cognit.no)

Creek Case-based Reasoning through Extensive Explicit Knowledge. Creek: • Is an architecture for integrated problem solving and machine

learning • Is a combined case-based and model-based reasoning system • Is targeted at user-interactive support for decision making and

human learning • Uses general domain knowledge (models) as explanatory support

for the CBR process • Is based on a flexible frame-based representation language (CreekL) (http://www.idi.ntnu.no/grupper/ai/cbr/)

Current Context The specific context a user is subject to at any given time. See chapter 2

Derived Context Future context synthesized from past and current context

Dynamic data Information that is, or could be, constantly changing. Example is gate numbers for departing flights. As opposed to static data.

Environment Context This part of the user context captures the entities that surround the user

Event Something that happens. This could be a soccer match or a plane changing the gate number. Used for example when the AmbieSense system 'triggers on an event' -> The user might want to have such information

Flight information Flight number, gate number, flight time, time to go to gate, data that are important to the traveller in order to not miss the plane.

Future context A setting that is supposed to happen in the future. Example: A planned flight to Amsterdam might trigger a future context of that, with downloading information on the city as a result. Even if the trip hasn't happened yet.

Info Package A set of information that has been packaged together. The package can be downloaded for storing and later use. A package may also be sold for a specific price.

Information structure Any model whose primary subject is the world that the computer system is supporting.


IST 2001- 34244

Information Zone A geographical location specified by a geometric anchor point and a geometric shape that provides information to locations and users. For instance, a context tag combined with a wireless network is in AmbieSense a vehicle for providing content to locations, situations, and users.

Logical Interface

Logical interfaces are virtual entities between sub-systems either present between two logical entities on the same component or as a general system concept (e.g. Client – Server)

Map service Service within the AmbieSense system that provides context-aware distribution of maps to mobile users

Mental Context It can contain information like mood, expertise, angriness, and stress etc.

Mobile computer Mobile computer is a device that is portable and is able to run software applications that supports an AmbieSense system. Mobile computers form a key element of the AmbieSense architecture. AmbieSense users on travel or during other non-stationary activities carry mobile computers, and we regard them as the user’s access point to information.

Mobile device See Mobile computer.

Mobile user See User.

NewsML An XML-based standard to represent and manage news throughout its lifecycle, including production, interchange, and consumer use. [http://www.newsml.org/NewsMLweb/webpage.xml]

Non-repudiation User taking a certain action cannot deny her/ his responsibility and liability

Payment models Several ways of providing payment within the system. Examples are payment per information package, per item, payment for a time limited use, etc. Discussed in Deliverable 1.

Personal agent A piece of software that is built to help the user with certain tasks. Described more thoroughly in 2.4

Personal Content Space Personal Content Space is the part of the Global Content Space that resides on the PDA. This could be unique data, or a replica of some of the data that are in the GCS.

Personal Context This part of the user context consists of two subparts: the physiological context and the mental context

Personal User Agent Software agent that initiates the distribution of personalized, context-sensitive information to the mobile users

Personalisation Personalisation is the use of technology and customer information to tailor interactions between a business and each individual user/customer. For a further description see D1 sec. 3.6


IST 2001- 34244

Physical Interface Physical interfaces are considered data transmission facilities between the major system components of AmbieSense

Physiological Context It can contain information like pulse, blood pressure, weight, glucose level, retinal pattern, and hair colour

Point of interest

Any place that might be of importance to the user within the environment, depending on the users wishes and needs. Typical point of interest might be restaurants, hotels, or ATMs. Content providers define many typical point of interest.

Quality of Service “…a networking term that specifies a guaranteed throughput level. One of the biggest advantages of ATM over competing technologies such as Frame Relay and Fast Ethernet is that it supports QoS levels. This allows ATM providers to guarantee to their customers that end-to-end latency will not exceed a specified level.” (http://www.webopedia.com/TERM/Q/QoS.html)

Role A role is defined by a set of tasks executed by an actor

Service

Within AmbieSense we think of a service the system offers to the user as any kind of information it can provide to the user. Examples are news/events service, map services, travel-guide services

Situation A situation is a real world situation where something can encounter, remain within, or leave.

Smartphone A smart phone is often characterized to be a wireless telephone with capabilities beyond an ordinary cellphone or mobile telephone. Often it got computer many computer-enabled features like: e-mail, Internet browsing capabilities, personal information manager (PIM), etc.

Social context It describes the social aspects of the current user context

Spatio-temporal context This context type describes aspects of the user context relating to the time and spatial extent for the user context

Static data

Data that are not constantly changed. Like the address of a pizza shop. As opposed to dynamic data.

System concepts See AmbieSense system concepts.

Tag context

This describes the situation around a context tag and includes the environment and people around the tag. However, it does not contain private or sensitive info about persons.

Task context

This context describes what the persons (actors) are doing in the user context

User An “end user” of the AmbieSense system. May accesses personalized context-sensitive information via her or his PDA, while being on the move.


IST 2001- 34244

User action

Action taken by the user. Normally used to denote part of the user’s interaction.

User context

A user context is a description of a user's situation, and generically, it consists of five parts: Environmental, Personal, Task, Social and Spatio-temporal context.

Virtual context tag A Context Tag that is emulated by software. See in addition Context Tag.

Web Server A Web server is a program that, using the client/server model and the World Wide Web's Hypertext Transfer Protocol (HTTP), serves the files that form Web pages to Web users (whose computers contain HTTP clients that forward their requests). Every computer on the Internet that contains a Web site must have a Web server program. (http://searchwebservices.techtarget.com)

6.3 ABBREVIATIONS 3G Third generation mobile network

ACL Agent Communication Language

AI Artificial Intelligence

A-MAS AmbieSense Multi-Agent System

API Application Programming Interface

ARA AmbieSense Reference Architecture

ARIM AmbieSense Reference Information Model

BT Bluetooth

CBR Case-Based Reasoning

CIP Content Integration Platform

CM Context Middleware

CMS Context Management System

CNN Cable News Network (http://www.cnn.com/)

CSP Content Service Provider

CT Context Tag

CTA Context Tag Administrator

FIPA Foundation for Intelligent Physical Agents


IST 2001- 34244

GPRS General Packet Radio Service

GSM Global System for Mobile Communications

GUI Graphical User Interface

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol (http://www.w3.org/Protocols/)

HTTPS Secure HyperText Transfer Protocol (http://www.w3.org/Protocols/)

ID Identification

IE Information Extraction

IIOP Internet Inter-Orb Protocol

IPTC International Press Telecommunications Council

IR Information Retrieval

ISO International Organization for Standardization

JADE Java Agent DEvelopment framework

LEAP Lightweight Extensible Agent Platform

MAS Multi-Agent System

MPEG Moving Picture Experts Group

NewsML News Markup Language (http://www.newsml.org)

NTNU Norwegian University of Science and Technology

OMG Object Management Group

OpenCMS Open Source Website Content Management System

PDA Personal Digital Assistant

QoS Quality of Service

RA Reference Architecture

RIM Reference Information Model

RM-ODP Reference Model - Open Distributed Processing

SSL Secure Sockets Layer

TCP/IP Transmission Control Protocol /Internet Protocol


IST 2001- 34244

TREC Text REtrieval Converence (http://trec.nist.gov/)

UI User Interface

UML Unified Modelling Language (http://www.uml.org)

URI Uniform Resource Identifiers (http://www.w3.org/Addressing/)

URL Uniform Resource Locators (http://www.w3.org/Addressing/)

WLAN Wireless Local-Area Network

WWW World Wide Web

XML eXtensible Markup Language

6.4 EXAMPLE INFORMATION STRUCTURES FOR APPLICATIONS This section provides four information structure examples that could be used to build applications based on the AmbieSense RIM. A key strength of the AmbieSense consortium is a strong group of content providers. In close cooperation with them, one has modelled four different information structures that exploit the core AmbieSense technology within the domain of each content provider. Here, the AmbieSense technology can be viewed as the enabling platform on which one can build applications for ambient, personalised and context-aware information provision. Each information structure is documented with use-cases, suggested tasks, and a combined application/context information structure. Together, they constitute a base information structure on which to build the applications.

6.4.1 News/Events/Information Services

Paul arrives at Aberdeen airport. He has never been in Aberdeen before. He takes up his PDA and activates the AmbieSense News/Events application. Paul accepts the recommendation to subscribe to the Aberdeen Leisure News, and agrees to the terms and conditions of using the service. Using the context tag at the airport arrival hall, he gets the current update on activities and special events in Aberdeen. His context, safely maintained by AmbieSense, is used to improve the selection of information received from the digital news channel. For example, particular topics of interest and the fact that this is his first time in Aberdeen are used as guides for the suggestions. He explicitly subscribes to the topics live music and exhibitions. Later, as he enters the hotel, the context tag mounted in the entrance area, supplies him with further suggestions of possible activities. He reads about a jazz concert held by one of his favourite sax-players at the Aberdeen Jazz Lounge this evening. The article also includes a short video. He continues his search for interesting events in his room. The articles have been downloaded to his PDA so that he can read it at his own convenience. The article contains a list of actual art exhibitions, selected according to his preferences. Most people want to know what’s going on in the world around them. They want to stay informed about global issues, their country and their city politics, sports, entertainment, and events. AmbieSense takes aim of providing a news/events/information service as one of four prototype applications. News and events, as kinds of content, has some particular characteristics. For example, its value is normally highly dependent on the timeliness of delivery. Therefore, using the user’s context to adapt the provision of news and events could increase its value further.


IST 2001- 34244

1. Information delivery in AmbieSense can be achieved using the push model. In this case, the user will automatically be given news/events that suit his preferences and interests. Thus, the user can get access to information faster and with less work than before.

2. The user’s language might also be used to increase the value of the information. The content can be automatically adapted to the language of the user.

3. The current location of the user, e.g. the city she is currently visiting, can be used to also provide local news/event, quite likely relevant for the user’s situation.

A challenge in the area of personalized and context aware news/events services are the sheer number of potential consumers. News and events information is a kind of service similar to e-mail and television, it is useful for all kind of users in all kind of areas.

Use Cases

Figure 36 illustrates, at a conceptual level, how the mobile user interacts with the news/events/information service.

Mobile user

Readnews/events/information

Recommendnews/events/information

Ratenews/events/information

Edit interests

Subscribe tonews/events/information

Discardnews/events/information

Figure 36: Use-Cases for mobile user

Figure 37 below illustrates the tasks of the Content Author. Naturally, his main objective is to produce content. This is a two-phase process: Content created may need revision upon comments from the Content Service Provider (see below).

Content Author

Createnews/events/information

Revisenews/events/information

Figure 37: Use-Cases for content author

The Content Service Provider is responsible for publishing acceptable content, i.e. content that satisfy overall requirements such as quality, policies etc. He/she is also responsible for compiling different pieces of information together, to form magazines, newsletters, newspapers etc. At last, the content must be packaged into Info Packages so that the content can be associated with a pricing model, security


IST 2001- 34244

verification and Digital Rights Management facilities. In addition, the content may be provided in special formats, suiting the particular needs of the customer.

Content Service Provider Publishnews/events/information

Verifynews/events/information

Compilenews/events/information

Create infopackages

Figure 38: Use-Case for Content Service Provider

News/events/information may ultimately be published through context tags. The Context Tag Administrator receives content from the Content Service Provider, and is thereafter responsible for maintaining the content on the context tag.

Context Tag Administrator

Maintainnews/events/information on Context

Tag

Receivenews/events/information

Figure 39: Use-Cases for Context Tag Administrator

Suggested tasks

The suggested task reveals and guides the action of the user those can be done while using the news/event guide service. Each section is one of the use cases, which the user can do. Also other entities like personal agent and travel guide its self is included to identify which task can be done in accordance.

MOBILE USER User context tasks: New context, edit context, delete context, merge contexts, match contexts, update interests.

•

• •

• •

Personal calendar tasks: new, edit, view, and delete activity Content tasks: Search for content, view content, set access rights for content, and download content. Context tag tasks: Accept/ignore context tag. Info Package tasks: search Info Package, delete Info Package, rate Info Package, Browse Info Packages, view news item, view event.

CONTEXT TAG ADMINISTRATOR There are no application specific tasks for the CTA. The suggested generic tasks are:


IST 2001- 34244

• • •

• • •

•

• •

• •

• •

•

•

•

•

•

• • •

•

t

User contexts tasks: new mode, select mode, delete mode, accept/ignore context change Tag context tasks: new context, edit context, delete context, merge contexts, match contexts Context trigger tasks: browse context triggers, view context trigger, new context trigger, delete context trigger Tag calendar tasks: view day, new activity, view activity, edit activity, delete activity Content template tasks: view content template, browse content templates Users and user groups tasks: new user, edit user, delete user, discharge user, new user group, add user in user group, remove user from user group. Context tag tasks: turn on/off system, local/Remote Logon, install/uninstall software, link software to user, link software to user group Context tag group tasks: group context tags, ungroup Context tags Content tasks: view content, upload content, edit content

CONTENT AUTHOR Create news/events/information. Revise news/events/information.

CONTENT SERVICE PROVIDER User context tasks: new mode, select mode, delete mode. Context template tasks: new context template, insert/remove contexts types, add/delete attribute, add/delete attribute values, delete context template Context trigger tasks: browse context triggers, view context trigger, new context trigger, choose condition/state, choose event. Info Package tasks: new Info Package, edit Info Package, browse Info Packages, link Info Package to contexts Content templates tasks: new content template, edit content template, delete content template, add/delete attribute, add/delete attribute values. Content tasks: new content, edit content, delete content, search for content, link content to contexts. Users and user group tasks: new user, edit user, delete user, new user group, add user in user group. Context tag tasks: edit Settings, edit content, and delete content. Verify news/events/information content created by content author. Develop Info Package with the following attributes: Copyright, News Item, Topics/Category, Location, Date, Provider, Event, Content Item, User, User groups Maintain Info Package

Information S ructures

As indicated in section 5.1.8, AmbieSense acknowledge NewsML as the de facto industry standard for representation of news. Thus, the project has adopted the central domain concepts from NewsML in our model of content. The concepts as News Identifier, Topic Set, Topic, News Envelope and Catalogue are encapsulated in NewsML model are associated with News Item. We have also included the concept Event Item in the model. Similar to the News Item concept, it is a specialisation of the Content Item and allows us to model event data. Event Item is the actualisation of model of Kalends service (a Reuters owned service)


IST 2001- 34244

-Login-Password-Name

User

-License number-Version-Manufacturer-Licensed to

Software

**

-Period-Topics-Price

Info package

*

*

-ContentItemID-ContentItemType-FirstCreated-ThisRevisionCreated-Status-RevisionHistory-Copyright-Interest rating-URL-Topic

Content item

1

*

-Provider-Location-Date

News Item

NewsML

**

-CategoryEvent

Kalends

*

*

Figure 40: News/Events/Information Services Content Model

Moreover, it is important to realise that a subscription for particular news/events/information is a continuous process. People may subscribe to any news/events/information provider. The information and price value of the Info Package can affect the subscription and payment model. This model can be


IST 2001- 34244

implemented as an attachment to the information package containing any news and events information. In addition, the type of the medium can be thought as a part of selecting a model. In some circumstances, visual information can be complementary for any other type. Even the time stamp of a particular news article may help identify its value. A financial news article from the 1970’s may be valuable or not in any context.

News/Events/Information Services and Context

As mentioned briefly above, there are strong contextual bindings to news/events and information services in general. Here, we focus primarily on the user context information structure (shown in Figure 41 below).


User

User context

-RoleSocial context Task context Personal context

-Topics-Category-Preferred language

Mental context Physiological context

-Location-Provider-User-Usergroup

Environment context-Start_time-End_time-Start_date-End_date-All_day

Spatio-temporal context

Figure 41: User Context information structure

Social context: Element Information (examples) Role Depending on the user’s role at work, different types of financial news may

be appropriate. For example, if Mary is an investment banker, she might receive news particularly related to the global equity market.

Task context: Element Information (examples) Travel destination Knowing the destination of a user’s journey, this fact can be used to find

news/events/information that is somehow bound to the destination, be it the country, the city or the area, such as local weather or politics.

Personal context, mental subgroup: Element Information (examples) Topics The user’s personal interests can be great indicator for which

news/events/information items are relevant. For example, hobbies, musical taste or sports.


IST 2001- 34244

Category Lower level categories of interests. Preferred language News/events/information is presented in the user’s native language.

Special topics, related to the nationality of the user might be considered, too. Environment context: Element Information (examples) Location Provide news/events/information relevant for the user’s current location. For

example, if the user is standing outside a bus-terminal, he might receive the digital bus-routes. Additionally, if the destination of the user’s journey is known, the most relevant bus-route might be presented first.

Provider Information about the providers of information in the environment. User Information about other users in the environment. Usergroup Information about other user groups in the environment.

Spatio-temporal context: Element Information (examples) Time Different “types” of news/events/information might be presented, depending

on the local time.

CONTEXT TEMPLATES Since the news and events will vary from one person to other specific reasons, creating context templates for these are difficult. As a whole, everybody wants to be informed of daily life politics (headlines), world news etc. However, news and events about sports may vary in terms of which team you support or whether you are interested in swimming or not. Nevertheless, we know that people sharing the same context and having similar profiles might need or be happy to receive same kind of news.

TAG CONTEXT INFORMATION STRUCTURE

Tag context

-Location-Provider-User-Usergroup

Environment context-RoleSocial context

-Start_time-End_time-Start_date-End_date-All_day

Spatio-temporal contextTask context

Figure 42: Tag context information structure

Environment context: Element Information (examples) Location Provide news/events/information relevant for the user’s current location. For

example, if the user is standing outside a bus-terminal, he might receive the digital bus-routes. Additionally, if the destination of the user’s journey is known, the most relevant bus-route might be presented first.

Provider Information about the providers of information in the environment. User Information about other users in the environment.


IST 2001- 34244

Usergroup Information about other user groups in the environment.

Social context: Element Information (examples) Role Depending on the user’s role at work, different types of financial news may

be appropriate. For example, if Mary is an investment banker, she might receive news particularly related to the global equity market.

Spatio-temporal context: Element Information (examples) Time Different “types” of news/events/information might be presented, depending

on the local time.

6.4.2 Context-aware airport services

Ole is a businessman living in Madrid. He travels a lot. This time he is catching an early flight to Seville, to meet his wife. He has spent the night at an airport hotel, and last night he told his personal agent in the AmbieSense system which flight he was taking. As he gets out of the hotel lobby and walks towards the airport, a map on his PDA directs him towards the correct check-in counter. He has access to numerous Info Packages describing the airport, including information on the specific flight he is catching. Passing through the security area he sees that his plane has been delayed by thirty minutes. As he has some extra time, and he is meeting his wife, he decides to check out the offers in the stores. His personal agent remembers what Ole was interested in during his previous visits, and suggests some special offers both in the whisky and flower shop. During his visit to the whisky shop, his PDA gently reminds him that it is time to go to the gate; he has totally forgotten the time. The gate number has changed due to the flight delay, but thanks to the map on the PDA, he is able to find the gate in time. Aboard the plane, he enjoys a variety of news bulletins and sports headlines, all downloaded to his PDA for off-line reading. People that are not working at the airport, normally have only a handful of reasons for being there. They are arriving by plane, leaving by plane, in transfer, or they are there to pick up someone else. Some help, for instance directions to toilets and flight information, is valuable to all these categories. The reason for coming to the area strongly influences the need for other kinds of information about the airport. This chapter describes the information structure for the airport (including the different kinds of data that exist on an airport), the relation to the AmbieSense context information structure (also detailed by different context templates that can be made according to the user types defined). For the AmbieSense project, the airport models are very important. They represent test cases for situations where users need static information like store location, as well as dynamic information like up to date arrival times. The information needed on an airport has many similarities with other travel dependant services. The following factors make airport services into a very interesting problem domain:

• The reasons for being at an airport are few, distinct and clear • The testing can take place within a confined space • A WLAN architecture is already existing at OSL Oslo Airport Gardermoen • At the airport we meet a lot of travellers, both businessmen and tourists

Use cases

The use case figure below describes what we assume people do on airports:


IST 2001- 34244

Mobile user

Arrive/Leave Transfer

ShopEntertainment

Find and useairport service

Figure 43: Context Aware Airport Service (Use Case Model)

• Find and use airport service: This includes getting directions to toilets, lost luggage claims,

customs, lounges, information desks etc. It also covers people looking for a quiet place to work, where to find a meeting arrangement, printers and Internet access.

• Arrive/Leave: This describes arriving and departing from the airport, either via public air or ground. Some information is important no matter if the person is arriving or departing via the airport. Information needed for departure would include gate number and location, flight time, up to date information on security control. Information needed when arriving via air would include public transportation, customs, handling of lost luggage etc. Lastly, this group includes people coming to pick up others. Information on delays, baggage retrieval etc.

• Transfer: People are quite often in transfer, and perhaps they need some special kind of information.

• Entertainment: Killing time is just as important as saving time, and getting information on what to do would prove valuable to a lot of passengers waiting.

• Shop: Getting information on shopping and the like is valuable, to customers and the airport alike. From the use cases the following task list (specific for the OSL domain) was created:

Suggested tasks

This subsection contains the parts of the suggested tasks that are special to the airport domain. We believe that users would want information, be it location or content specific on the following topics. Accordingly, the content service providers must provide this: (A closer description of the different tasks will be given in the next subsection)

MOBILE USER User context tasks: New context, edit context, delete context, merge contexts, match contexts, update interests.

•

• •

• •

Personal calendar tasks: new, edit, view, and delete activity. Content tasks: Search for content, view content, set access rights for content, and download content. Context tag tasks: Accept/ignore context tag. Info Package tasks: search Info Package, delete Info Package, rate Info Package, Browse Info Packages, view infotainment, view brochure, view offers, view airline company information, view lounge information, view my flight, view today’s flights, view shop information, view airport map.



IST 2001- 34244

• • •

• • •

•

• •

• •

• •

•

•

•

•

•

• • •

•

User contexts tasks: new mode, select mode, delete mode, accept/ignore context change Tag context tasks: new context, edit context, delete context, merge contexts, match contexts Context trigger tasks: browse context triggers, view context trigger, new context trigger, delete context trigger Tag calendar tasks: view day, new activity, view activity, edit activity, delete activity Content template tasks: view content template, browse content templates Users and user groups tasks: new user, edit user, delete user, discharge user, new user group, add user in user group, remove user from user group. Context tag tasks: turn on/off system, local/Remote Logon, install/uninstall software, link software to user, link software to user group Context tag group tasks: group context tags, ungroup Context tags Content tasks: view content, upload content, edit content

CONTENT AUTHOR Create airport content items and Info Package. Revise airport content items and Info Package.

CONTENT SERVICE PROVIDER User context tasks: new mode, select mode, delete mode. Context template tasks: new context template, insert/remove contexts types, add/delete attribute, add/delete attribute values, delete context template Context trigger tasks: browse context triggers, view context trigger, new context trigger, choose condition/state, choose event. Info Package tasks: new Info Package, edit Info Package, browse Info Packages, link Info Package to contexts Content templates tasks: new content template, edit content template, delete content template, add/delete attribute, add/delete attribute values. Content tasks: new content, edit content, delete content, search for content, link content to contexts. Users and user group tasks: new user, edit user, delete user, new user group, add user in user group. Context tag tasks: edit Settings, edit content, and delete content. Verify airport content created by content author. Develop Info Package with the following elements: infotainment, brochure, offers, airline company, lounge, my flight, today’s flights, shop, and map. Maintain Info Package

Information structures

The following information structure describes the application content for the airport. The following boxes are an instance of the generic AmbieSense content information structure, which is described in section 5: User, Context, Software, Content, Info Package and Content Item.

My flight The flight I am currently waiting for, be I arriving, departing or picking up

someone Today’s flight The list of flights that are shown on the large screens around on the airport

Travel related information is perhaps the data type that is most special for the airport situations. This is information about arriving and departing airplanes. The data contains for instance gate numbers, airplane number, time, status on the flight (go to gate, boarding e.g.), which luggage conveyor belts the airplanes are connected to. The special thing about this information is that it is very dynamic. The ever-changing gate numbers, check-in times and luggage conveyor belt numbers are currently days shown on monitors in the


IST 2001- 34244

airport. Having access to a personalised version of this will prove valuable to all passengers wanting to save some time finding their way.

Infotainment News, what happens in the area Brochure Leaflets and the like that you normally have picked up from a stand can now

be downloaded Lounge What and where are the lounges I have access to

Airport service content: The service related information is a more static information source. This applies to all room information, like where shops, toilets, restaurants and so are located. The current exhibitions are also static enough to be covered by this category, as well as customs handling and train routes. Offer Special offers from shops Shop Information on the shops on the airport. Opening hours, directions… Airway company All companies represented on the airport have some specific information,

like contact ways, luggage info, ticket offices and the like Airport commercial content: There are many commercial activities and partners on the airport. They run for instance shops and restaurants. There exists some service related information about shops at OSL at the moment, but nothing more than opening hours and a short description of the shops. The shops themselves would need, as content providers, to deliver information on the current sales offers, a complete list of what they sell, extra information on the shop and its products, current restaurant menu and so on. This information can both be static or very dynamic, but controlled by the shops themselves. Map Directions to any place you’d like to go: departure, shops etc

The maps are generated depending on the information the user wants to see.


IST 2001- 34244

Shop

Brochure

Infotaintment

Lounge Today's flightsMy flight

Offer

Map

Airway company

-ContentItemID-ContentItemType-FirstCreated-ThisRevisionCreated-Status-RevisionHistory-Copyright-Interest rating-Content identification-URI-Content data

Content item

Content


Info package

-ID-Name-Contexts-Attributes-Type

Context

-Login-Password-Name-Role

User


Software

Figure 44 Airport information structure

Content services, consisting of the elements mentioned above, feed content through the airport content service. The context tag, pre-programmed with tag contexts, provides this information to mobile users. Mobile users may choose to download Info Packages after having found interesting content. Points of interest are found after matching user context with tag context and airport content.


IST 2001- 34244

Airport Service and Context

Airport services can be improved by using context. This section discusses examples of how the elements of the context can be used to tailor the information.

USER CONTEXT INFORMATION STRUCTURE

User context

-RoleSocial context

-TaskTask context Personal context

-Interests: TopicsMental context Physiological context

-Services-Location

Environment context Spatio-temporal context

-Login-Password-Name-Role

User

Figure 45 User context information structure

Social context: Element Information (examples) Role The user has many roles in the environment. The roles’ shift in priority

depending. She is at the airport as a departing person. At the same time she is a consumer seeking products to buy. She is perhaps also in a work-related setting, as opposed to the leisure mode that would make her more willing to spend time at a local exhibition. The user being a foreigner might also add to making information on customs and security controls more important

Task context: Element Information (examples) Task The users might have many tasks they want to perform at the same time.

Some tasks have importance over others; Catching the flight is more important than buying that special bottle of whisky at the tax-free shop. We won’t describe the tasks here in detail, but a few examples are: Catching a flight, finding a restaurant, entering the right shops, knowing about customs regulations, and the ways of leaving the airport with public transportation.

Personal context: Element Information (examples)


IST 2001- 34244

History Help relative to been here before. What did he do last time Personal information Shops, recreation etc being stream-lined to user preferences User mode (leisure/work) Helps decide to what extent information is to be given

Environment context: Element Information (examples) Services Show the information on the closest tag Location Go to gate, route to point of interest, nearby shop and dining offers

Spatio-temporal context: Element Information (examples) Time Go to gate, transportation from airport, suggesting leisure activities

TAG CONTEXT INFORMATION STRUCTURE The tag context for airport services is very similar to the user’s context: Its main objective is to help the user achieve the tasks wanted at the airport. Figure 46 below illustrates the tag context for airport services.

Tag context

-Services-Location

Environment context-RoleSocial context Spatio-temporal context

-TaskTask context

Figure 46: Tag Context information structure

Social context:

Element Information (examples) Role The

Environment context:

Element Information (examples) Services The services the tags have to offer to the customers depend once again

on the needs of the user in the current environment and context. The tag might provide information on arrivals, departure, in transit information, or simply shopping assistance. Each tag can of course provide more than one service.

Location The different services are strongly related to the tags location, and distance to other services. The services closest to the tag area would be more interesting to provide information on.

Task context:

Element Information (examples) Tasks The tags’ primary task is of course to give the users the information they

need. Along with that they want to provide users with the information the tag owner wants potential customers to get. On an airport these tasks will primarily focus on helping with arrivals, departure, in transit and


IST 2001- 34244

shopping, possible with the use of maps. Spatio-temporal context:

Element Information (examples) Time Filtering of information depending on opening hours.

The local time. Since most people enter an airport area for very specific reasons, creating context templates for these are not that difficult as they might be in other places. These context templates describe different tasks that are typical in the situations, and the user thus is likely to want information on. We also, for each of the tasks, describe what type of data they belong to, and in what kind of context they are part of (refer to descriptions of social-, task-, personal-, environmental- or spatio-temporal context, section 5.1.3)

6.4.3 Travel-guide services

Naomi has arrived in Paris for the first time. While she is walking down the Champs Elysées, southwards from the “L’Arc De Triomphe”, she picks up signals from the AmbieSense tags installed in shops, hotels and in tourist information areas. As she passes them, they give her information on the different items the shops sell, and special sales. She also gets information on available hotel rooms near by. She is visiting a friend, and thus has no need of this information. Therefore, she specifies that she doesn’t want any such offers. She likes offers from shops and possible exhibitions, though. The rest of the time she spends down the street, she is only given information on these topics. In the AmbieSense project, the travelling domain is highly important. Using context-aware technology users can experience their travelling both more effective and fun. People seek to explore sights and places. People do various activities before, while and after travelling. In general, we believe that planning, booking, travelling, and reciprocating are the major activities that constitute travelling. We thus establish the basis of our travel domain on this. Expectations from Travel-Guide service should be general enough and extendable through different interfaces. When people arrive at a new place, they face the problem of getting to their accommodation, finding transportation etc. Although travelling can be from one city to another, it can also be between different places in the same city. The Travel-Guide service can be used to provide further information to other services like Airport service. Also, it’s obvious that Travel-Guide service depends on Map and Calendar services because most of the tasks involved in making travel plans make use of location and time-related features. Travel service will combine the information from these fundamental services. The rest of this section describes the use cases, the possible tasks, and information structures for the Travel Guide Service that can be implemented within AmbieSense.

Use-Cases

Figure 47 below shows the use cases for the travelling information structure.


IST 2001- 34244

Mobile user

Shop

StaySee

Getting there (andaway)

Facts

Eat

Doing

Night

Use travel guide

Planning

Being there

Figure 47: Context-aware travel guide service (Use case model)

As the use cases are obvious from their names, we won’t delve into a description on each one. The important point is that the travelling for the most part can be seen as three different user objectives:

• You want to go somewhere (planning) • You find a way to get there and go (Getting there) • You are there (Being there)

During these phases, the kind of information you like to get from a system equivalent to AmbieSense will vary. While you are planning, or even just pondering the topic of going somewhere special, you might want to check out what the place has to offer on a large scale. This could be what the weather is like during the particular period, what kind of large “tourist attractions” there are nearby. This is opposed to getting the information about the structure of the city centre when you are there, or have decided to go. Exactly where the good restaurants are, and where to get that special present for mom are issues that are more important as you are there. Thus, we believe that AmbieSense should support travelling in these phases.

Suggested tasks

The following user tasks can be supported in an AmbieSense-oriented application at an airport.

MOBILE USER • User context tasks: New context, edit context, delete context, merge contexts, match contexts,

update interests. • Personal calendar tasks: new, edit, view, and delete activity. • Content tasks: Search for content, view content, set access rights for content, and download

content. • Context tag tasks: Accept/ignore context tag.


IST 2001- 34244

• Info Package tasks: search Info Package, delete Info Package, rate Info Package, Browse Info Packages, view place of interest information, view eating information, view staying information, view see & do information, view shopping information, view entertainment information.


• User contexts tasks: new mode, select mode, delete mode, accept/ignore context change • Tag context tasks: new context, edit context, delete context, merge contexts, match contexts • Context trigger tasks: browse context triggers, view context trigger, new context trigger, delete

context trigger • Tag calendar tasks: view day, new activity, view activity, edit activity, delete activity • Content template tasks: view content template, browse content templates • Users and user groups tasks: new user, edit user, delete user, discharge user, new user group, add

user in user group, remove user from user group. • Context tag tasks: turn on/off system, local/Remote Logon, install/uninstall software, link software

to user, link software to user group • Context tag group tasks: group context tags, ungroup Context tags • Content tasks: view content, upload content, edit content

CONTENT AUTHOR • Create place of interest/eating/staying/see & do/shopping/entertainment information. • Revise place of interest/eating/staying/see & do/shopping/entertainment information.

CONTENT SERVICE PROVIDER This section is largely based on Lonely Planet’s description of how they work as information providers. It describes their tasks as content providers for travel guides in paper and electronic form. Additionally, the generic tasks for Content Service Providers are:

• User context tasks: new mode, select mode, delete mode. • Context template tasks: new context template, insert/remove contexts types, add/delete attribute,

add/delete attribute values, delete context template • Context trigger tasks: browse context triggers, view context trigger, new context trigger, choose

condition/state, choose event. • Info Package tasks: new Info Package, edit Info Package, browse Info Packages, link Info Package

to contexts • Content templates tasks: new content template, edit content template, delete content template,

add/delete attribute, add/delete attribute values. • Content tasks: new content, edit content, delete content, search for content, link content to

contexts. • Users and user group tasks: new user, edit user, delete user, new user group, add user in user

group. • Context tag tasks: edit Settings, edit content, and delete content.

The overall process of authoring in Lonely Planet can be described in the following phases:

• Briefing • Planning the trip • Acquisition of information • Data input to their Content Service • In-house editing


IST 2001- 34244

In AmbieSense the following application specific tasks have been defined:

• Develop Info Package (Place of Interest, Eat, Stay, See & Do, Shopping, Entertainment) • Maintain Info Package as above


As mentioned, making and instantiating a travel involves a series of entities. We’ll shortly describe these different phases of travelling first: The desire to go somewhere is often related to getting access to information about a site. While some of this might be out of scope for AmbieSense, experiencing things that are nearby is also a form of travelling. The information that is given about sites, either nearby or far away, can be given with such a system. The other important part of a travel plan is booking. This activity helps people investigate the actualisation of the plan in terms of availability. It is necessary of a travel instance. The travel instance of a plan includes several activities and tasks that can be done in run time. Information about sites, activity alternatives at night (restaurant recommendations), and help on critical emergency etc can be given related to a particular context. After the travel, people intent to tell people about their travel. How it was: good/bad, location and cultural details, activities so on. In addition, recommendations about the travel and travel organisations can be given to friends who also want to have the same experience and taste of a travel. Sharing the same ideas and experiences can be titled as “reciprocate”. Figure 48 shows the content model developed for the travel domain. Travel guide services are assumed to based on Activity concept. Eat, Stay, Night, Do, Sleep is the important concepts covered on the Activity. An activity is further described in relation to a Point of Interest (a different concept than geographical location, it is rather used to denote a certain museum or a particular railway station. However, a Point of Interest will have a geographical location as well). Calendar is another entity, which has associations with Activity, which by means a feedback or the schedule of the travel, or the activities, itself. Info Package and content Item concepts are developed for generic AmbieSense content model. Info Package is an abstract envelope, which may include many Content Items. It defines the properties and descriptions of the content. Here every individual Content Item can be any type of activity given.


IST 2001- 34244

-ContentItemID-ContentItemType-FirstCreated-ThisRevisionCreated-Status-RevisionHistory-Copyright-Interest rating-Topic-URL

Content item


Info package

-ID-Name-Contexts-Attributes-Type

Context


Software

-Instance of

*

Content


User

-Flash backCalendar

-OpenLate-Alcohol-Nightclub-Bar-Entertainment

Eat-bar-Pool-Gym-Parking

Stay-children-Eat

See&Do-sale-specialFeature-OpenLate

Shopping-openLate-entertainment

Entertainment

-ContextTagID-POI_ID-GeoCode

Place of interest

Figure 48: Travel Guide Services Content Model

Travel Guide Service and Context

These are the context information structures showing possible elements and where they fit into the different parts of the user’s and tag’s context.

USER CONTEXT INFORMATION STRUCTURE


IST 2001- 34244

User

User context

-RoleSocial context

-ActivityTask context Personal context

-Interests: Topics-Travel range

Mental context Physiological context

-Location-Traffic conditions-Weather

Environment context Spatio-temporal context

Figure 49: User Context information structure

Social context: Element Information (examples) Role We play different roles when we interact with each other. The travel guide

has another role than the tourist following the guide. Task context: Element Information (examples) Activity Eat Stay, Night, Sleep and Do… These are the different tasks users do while

travelling. While they do not always think about it while walking around, the system can know the persons preferences.

Mental context: Element Information (examples) Interests: Topics The users’ interests list describe preferences the user has for a variety of

things, from food to classical music. Other persons/users in the area might result in other selections for topics. Examples are Culture, Shopping, Food, and Accommodation preferences, Economy.

Travel range This is a particularly interesting part of the context. It denotes the current “range” that the user can accept to travel to see a PoI for example.

Environment context: Element Information (examples) Location The user’s current location might be significant when suggesting places to

visit etc. Weather conditions The weather conditions may impact the user’s willingness to see certain PoI. Traffic Similar to the weather conditions.

TAG CONTEXT INFORMATION STRUCTURE This is the tag context information structure that is specific for the travel guide services domain:


IST 2001- 34244

Tag context

-Location-Traffic conditions-Weather

Environment context-RoleSocial context Spatio-temporal context

-ActivityTask context

Figure 50:Tag context for travel guide services domain

Social context: Element Information (examples) Role We play different roles when we interact with each other. The travel guide

has another role than the tourist following the guide. Task context: Element Information (examples) Activity Eat Stay, Night, Sleep and Do… These are the different tasks users do while

travelling. While they do not always think about it while walking around, the system can know the persons preferences.

Environment context: Element Information (examples) Location The user’s current location might be significant when suggesting places to

visit etc. Weather conditions The weather conditions may impact the user’s willingness to see certain PoI. Traffic Similar to the weather conditions.

6.4.4 Context-aware map service

John visits Oslo for the first time. Standing in front of his hotel, he wonders if there is anything around he can visit, and he uses his PDA… This is a common situation for travelling people. John has the chance to gain quick and contenting assistance in this situation while using his AmbieSense-equipped mobile computer. The map service would be a good idea to display the desired information in a pleasant way. Mobile users are often interested in exact information about their surroundings. City maps, route planners, company addresses as well as shopping guides can be provided as map content. Thus, maps are useful in many situations for mobile users. AmbieSense expands the concept of digital maps by providing personalisation and context-awareness. Context-aware and personalised map service can help mobile users in many different ways. Not only the retrieval of the contextual information (e.g. where is the user right now? What does he do here?), also the personal information (e.g. what kind of shops is the user interested in?) is taken care of by the AmbieSense system and influences the results from the map service to increase the usability.

Use Cases

Figure 51 below describes the typical actions map users perform:


IST 2001- 34244

Mobile User

Calculate Route

Navigate in Map Execute POI Search

Generate Map

Show User LocationTag Meeting-Point

Figure 51: Context-Aware Map Service (Use Case Model)

• Calculate Route: This includes the specification of destination as well as their sequence. • Navigate in Map: Navigation includes Up- and Downscaling of maps and the handling of the

selected map clippings. • Execute Point of Interest Search: Selecting the PoI type, and subtype • Generate Map: Includes the specification of the map radius and centring as well as the selection

of cities and map layers. • Tag Meeting Point: This describes the selection of meeting points, the mobile users to meet, and

the selection of the transfer type (AmbieSense, email, MMS, etc) • Show location of other users: This includes selection the user to locate, specification and

maintenance of user lists.

Suggested tasks

This subsection gives an overview of all tasks that are performed in connection with the context-aware map service. The tasks listed here are not meant to be detailed, procedural descriptions of tasks. These will be detailed in our future work on the AmbieSense system.

MOBILE USER • User context tasks: New context, edit context, delete context, merge contexts, match contexts,

update interests. • Personal calendar tasks: new, edit, view, and delete activity. • Content tasks: Search for content, view content, set access rights for content, and download

content. • Context tag tasks: Accept/ignore context tag. • Info Package tasks: search Info Package, delete Info Package, rate Info Package, and browse Info

Packages. • Calculate route tasks: Specify destination/interstation address, select mobile users, add mobile

users to list of users, remove mobile user from list, assign sequence of interstations, determine destination/interstation point in map image, choose destination/interstation city from list, select best route, save route.

• Navigation tasks: Scale map, scale clipping, move/centre clipping. • Search in map tasks: Select Point of Interest type and subtypes (branches, sights, public buildings,

public utilities, infrastructure), fade in/out Point of Interest objects, save map.


IST 2001- 34244

• Generate map tasks: specify search radius, select type of centring (location, district, city, address), specify destination data (location, district, city, address), select city from map-Service generated list, save map

• Tag Meeting Point tasks: determine meeting point in map, select mobile users, add mobile user to list, remove mobile user from List, indicate type of transfer (email, AmbieSense push, MMS, etc), save map

• Show location of other users tasks: select mobile users, add mobile users to list, remove mobile users from list, save map.


• User contexts tasks: new mode, select mode, delete mode, accept/ignore context change • Tag context tasks: new context, edit context, delete context, merge contexts, match contexts • Context trigger tasks: browse context triggers, view context trigger, new context trigger, delete

context trigger • Tag calendar tasks: view day, new activity, view activity, edit activity, delete activity • Content template tasks: view content template, browse content templates • Users and user groups tasks: new user, edit user, delete user, discharge user, new user group, add

user in user group, remove user from user group. • Context tag tasks: turn on/off system, local/Remote Logon, install/uninstall software, link software

to user, link software to user group • Context tag group tasks: group context tags, ungroup Context tags • Content tasks: view content, upload content, edit content

CONTENT AUTHOR • Create map information. • Revise map information.

CONTENT SERVICE PROVIDER • User context tasks: new mode, select mode, delete mode. • Context template tasks: new context template, insert/remove contexts types, add/delete attribute,

add/delete attribute values, delete context template • Context trigger tasks: browse context triggers, view context trigger, new context trigger, choose

condition/state, choose event. • Info Package tasks: new Info Package, edit Info Package, browse Info Packages, link Info Package

to contexts • Content templates tasks: new content template, edit content template, delete content template,

add/delete attribute, add/delete attribute values. • Content tasks: new content, edit content, delete content, search for content, link content to

contexts. • Users and user group tasks: new user, edit user, delete user, new user group, add user in user

group. • Context tag tasks: edit Settings, edit content, and delete content. • Verify map content created by content author.


In the following, an overview of the map service domain is given.


IST 2001- 34244


Software


Info package

-ContentItemID-ContentItemType-FirstCreated-ThisRevisionCreated-Status-RevisionHistory-Copyright-Interest rating-Topic-URL

Content item


User

-Category-Location: Geocode

Point of interest

-Start-Interstation-Destination

Route

-Descriptions-Background

Calender

* *

-Scale-Rotation

Map context

-Personal-Task-Environment-Spatio-temporal-Social

User context

-Map elements-Layers

Map

Figure 52 Map application information structure.

A geographical map consists of different layers, where different geo-spatial content can get separated from each other. This technique has the advantage that each layer can be constructed and personalized individually. This includes the adjustment of the static layers like buildings, streets, backgrounds etc. via colours, labelling and so on, the addition or removal of extra static layers like orientation points, public buildings, restaurant guides etc. and last but not least the generation of dynamic content, e.g. routes or PoIs. Maps are graphical presentations of spatial realities. So, to obtain a map, spatial information like coordinates and radius must be passed to the map service. Further detailing of the map can be defined by a request for certain graphical objects. Such graphical objects can occur in a point of interest search where the relevant location will be marked by a special icon. Other graphical objects can include meeting points or other users.


IST 2001- 34244

Maps are not only static objects. A dynamic approach can be added for navigating within maps. Features like zooming or moving can be obtained by changing coordinates or radius of a given map.

Map Services and Context

Almost all defined AmbieSense context parts (environmental, personal etc., see section 5.1) can affect the appearance of a requested map. In fact, the way of transforming maps into context-aware maps has to be seen in close relation to the location aspect of the user context. In all aspects that form this context, some points can be found influencing the results expected from the map service. E.g. it is useful for the system to know about the user’s knowledge of the respective location. If a tourist comes to a city for the first time, he probably wants to know much more essential information about the city. When he visits the same city for the third time, he is probably looking for something more specific. According to this information, places of interest can be highlighted in different levels. Or consider the personal physiological context of being reliant on a wheelchair as biasing the calculation of a suitable route or the social context of a country as elimination criteria for certain transportation facilities.

Type of context Parameter Effect in map Region structure (city centre, environs etc.) - Focus of map Environment Weather - Distance of routing

- Vehicle for travelling - Route optimisation - Places to visit

Physical condition - Distance of routing - Places to visit

Physical abilities or disabilities - Vehicle for travelling - Places to visit

Mental condition (bad, good mood etc.) - Places to visit

Personal

Region knowledge - Places to visit - General, special map - Position tracking

Task Task - Places to visit - Places to meet - General, special map

Relations (people who share interests etc.) - Places to meet - Position tracking - Meeting point

Social

User group category - Places to meet

Steepness / high difference - Vehicle for travelling - Route optimisation

Movement tracking - Places to visit

Spatio-temporal

Travel time - Places to visit - Vehicle for travelling

Table 2: Context dependency of the map service

The crucial point of the map service would be a context aware map request (see Figure 53 below).


IST 2001- 34244

Map Agent

Request Handler

Map ServiceRequest

Result RequestRepresentationRequest

Analyzer

Result Manipulator

ContextAware App

Rules

Request

Result

Map Service

User Context

Figure 53: Context Aware Map Request

• Context Aware Application – User Context: every Context Aware Application is connected to the context of its actual user

• Context Aware Application – Request: Context Aware Application produce Requests for the Context Aware Map Service

• Request – Result Request: every Request consists of a request for a result • Request – Representation Request: every Request has a request for the representation of the result • User Context / Result Request / Representation Request – Analyser: see following model • Analyser – Rules: the Analyser uses different Rules to extract the location biasing information

from the input • Analyser – Request Handler: the Analyser delivers the location biasing information to the Request

Handler • Request Handler – Rules: the Request Handler creates a Request with appliance of the Rules • Request Handler – Map Service Request: the Request Handler puts out a Request understandable

by the Map Service Map Service Request – Map Service: the Map Service Request is passed to the Map Service

• Map Service – Result Manipulator: the Map Service gives the result to the Result Manipulator • Result Manipulator – Rules: the Result Manipulator checks whether there has to be adaptations on

behalf of the rules and commits them or just passes through the result • Result Manipulator – Result: the Result Manipulator produces the Result desired by the Context

Aware Application • Result – Context Aware Application: the Result is passed to the requesting Context Aware

Application The Request analyser itself is internally divided into three sub-analysers that deal with the given input.


IST 2001- 34244

ContextAnalyzer

ResultAnalyzer

Repres.Analyzer

Rules

UserContext

ResultRequest

RepresentationRequest

Request Handler

Figure 54: The sub-analysers

The Agents check the incoming data in terms of location relevant information and extract them using the rules. The output is passed to the Request Handler. The analysis of the two requests and the user context is necessary because all three of them can include information relevant for a context aware map. To clarify the functionality of the context-aware map service we revisit the example above: John for the first time visits Oslo. Standing in front of his hotel, he wonders if there is anything around he can visit, and he uses his AmbieSense-equipped PDA. Knowing John’s interests the system looks for matching data on behalf of the actual context John is in. This context includes John’s actual location, his favour for walking, his interest in French modern art, his relaxed state and the holiday mode the system is in (to name only a few points of context). Given this input the AmbieSense System looks for points of interest and wants the result displayed in a map (knowing that John prefers this kind of display). So it hands out the request to the Context-Aware map service. Within the service, the analysers look for information concerning location and extract them. In this case this information produces a nice little gallery as a result only a ten-minute walk away from the hotel, along with a picturesque route through a park. Changing the mood for example from relaxed to stress, the system may have proposed the same gallery, but a shorter route. So changing one parameter can influence parts of the result or even the whole result. The rules hereby take the specific role to acquire the relevant information and support the design of a request that can be evaluated by the map service itself.


IST 2001- 34244

6.5 REFERENCES

[AmbieSense-D1] IST-project 2001-34244 AmbieSense, D1 - Requirements and Overall system architecture report, 2002.

[AmbieSense-D3] IST-project 2001-34244 AmbieSense, D3 - Context tag technology report, 2003.

[AmbieSense-D5] IST-project 2001-34244 AmbieSense, D5 – Context Middleware Report, 2003, AmbieSense project report, restricted deliverable, send email to [email protected] or [email protected] for further contact/ info.

[DARPA2001] DARPA Workshop on Meaning of Context, 2001.

[Dey et al. 1999] Anind K. Dey, Daniel Salber, Masayasu Futakawa and Gregory D. Abowd. An Architecture to Support Context-Aware Applications. GVU Technical Report GIT-GVU-99-23, College of Computing, Georgia Institute of Technology. 1999. Available at ftp://ftp.cc.gatech.edu/pub/gvu/tr/1999/99-23.pdf

[DeyAbowd1999] Anind K. Dey and Gregory D. Abowd. Towards a better understanding of context and context-awareness. GVU Technical Report GIT-GVU-99-22, College of Computing, Georgia Institute of Technology. 1999. Available at ftp://ftp.cc.gatech.edu/pub/gvu/tr/1999/99-22.pdf (accessed 27.07.00)

[ISO 10746-1] Draft Recommendation ITU-T X.901 / ISO 10746-1: Basic Reference Model of Open Distributed Processing - Part-1: Overview.

[ISO 10746-2] Draft International Standard ITU-T X.902 / ISO 10746-2: Basic Reference Model of Open Distributed Processing - Part-2: Descriptive Model.

[ISO 10746-3] Draft International Standard ITU-T X.903 / ISO 10746-3: Basic Reference Model of Open Distributed Processing - Part-3: Prescriptive Model.

[Myrhaug et al.] Myrhaug, Hans I.; Moe, Nils B.; Winnem, Ole M. Combining Knowledge Acquisition with User Centered Design.

[MyrhaugGöker2002] Ayse Goker, Hans Inge Myrhaug, Invited speak/paper, User Context and Personalisation, ECCBR 2002.

[Oesterreich1999] Oestereich, Bernd. Developing Software with UML. Addison-Wesley 1999

[OMG] Introduction to OMG's Unified Modelling Language™ (UML™). http://www.omg.org/gettingstarted/what_is_uml.htm

[Rational] http://www.therationaledge.com/content/sep_02/m_bestPractices_pr.jsp

[SINTEF2001] LAMA, internal SINTEF report, version 1.2, Jan-2001

[Sunset] http://sunset.usc.edu/research/reference_architecture/ch2.html

[UM2001] User Modelling Conference, Sonthofen, Germany. Workshop on User Modelling for Context-Aware Applications, 2001. http://orgwis.gmd.de/gross/um2001ws/papers.

[UML] Introduction to OMG's Unified Modelling Language™ (UML™). http://www.omg.org/gettingstarted/what_is_uml.htm


IST 2001- 34244

[W3] http://www.w3.org/2002/ws/arch/2/wd-wsawg-reqs-03262002

[Weiser] Ubiquitous Computing, http://www.ubiq.com/hypertext/weiser/UbiHome.html


IST 2001- 34244

6.6 FIGURES Figure 1: The AmbieSense system presenting the value proposition ..............................................................9 Figure 2: AmbieSense innovation corner stones ...........................................................................................11 Figure 3: Users, actors and roles ...................................................................................................................17 Figure 4: Use case for the Mobile User .........................................................................................................20 Figure 5: Use case for the Context Tag Administrator ..................................................................................22 Figure 6: Use case for Content Service Provider (and content provision roles) ............................................24 Figure 7: Functional decomposition ..............................................................................................................28 Figure 8: User Interface Component interfaces .............................................................................................29 Figure 9: Application component interface ...................................................................................................30 Figure 10: Agents interface ...........................................................................................................................32 Figure 11: Pull component interface..............................................................................................................32 Figure 12: Push component interface ............................................................................................................33 Figure 13: Context Middleware interfaces ....................................................................................................34 Figure 14: CIP interfaces...............................................................................................................................35 Figure 15: Proximity Detection interface ......................................................................................................36 Figure 16: Principle interaction pattern User Interface, Application, and Agent ..........................................37 Figure 17: Application/Agent using the pull component...............................................................................37 Figure 18: Push component, defining publications and creating subscriptions .............................................38 Figure 19: Application/Agent notified by Push component ..........................................................................39 Figure 20: The AmbieSense Reference Architecture ....................................................................................40 Figure 21 Deployment configurations ...........................................................................................................41 Figure 22: Context.........................................................................................................................................45 Figure 23: Various types of contexts .............................................................................................................46 Figure 24: User context .................................................................................................................................47 Figure 25: Tag context...................................................................................................................................48 Figure 26: Context template ..........................................................................................................................50 Figure 27: Context space ...............................................................................................................................51 Figure 28: Context tags .................................................................................................................................53 Figure 29: Content items and info packages..................................................................................................54 Figure 30: Context-aware access to contexts via calendars...........................................................................57 Figure 31: Information retrieval in general....................................................................................................58 Figure 32: Information retrieval processes ....................................................................................................59 Figure 33: A content service with focus on context-aware information retrieval..........................................62 Figure 34: Using context in personalised information retrieval ....................................................................63 Figure 35: Linking and matching of content and context ..............................................................................67 Figure 36: Use-Cases for mobile user ...........................................................................................................99 Figure 37: Use-Cases for content author .......................................................................................................99 Figure 38: Use-Case for Content Service Provider......................................................................................100 Figure 39: Use-Cases for Context Tag Administrator .................................................................................100 Figure 40: News/Events/Information Services Content Model ...................................................................102 Figure 41: User Context information structure............................................................................................103 Figure 42: Tag context information structure ..............................................................................................104 Figure 43: Context Aware Airport Service (Use Case Model)....................................................................106 Figure 44 Airport information structure ......................................................................................................109 Figure 45 User context information structure..............................................................................................110 Figure 46: Tag Context information structure .............................................................................................111 Figure 47: Context-aware travel guide service (Use case model) ...............................................................113 Figure 48: Travel Guide Services Content Model .......................................................................................116 Figure 49: User Context information structure............................................................................................117 Figure 50:Tag context for travel guide services domain .............................................................................118


IST 2001- 34244

Figure 51: Context-Aware Map Service (Use Case Model) ........................................................................119 Figure 52 Map application information structure. .......................................................................................121 Figure 53: Context Aware Map Request .....................................................................................................123 Figure 54: The sub-analysers.......................................................................................................................124


IST 2001- 34244

6.7 TABLES Table 1: Roles and use-cases in the AmbieSense system..............................................................................18 Table 2: Context dependency of the map service ........................................................................................122
