IST 2001- 34244
D2 - Reference I nformation Model ( RI M)
WP2 – Modelling and design of AmbieSense Technology
Editors:
Stein L. Tomassen ( SI NTEF)
Till C. Lech ( CognI T)
Juergen Pollich ( Yellow Map)
1
© 2004 The AmbieSense Consortium
IST 2001- 34244
Report
REPORT TI TLE
AmbieSense Reference Information Model
RESPONSI BLE WORK PACKAGE
WORK PACKAGE LEADER
WP 2
CognIT (Till C. Lech)
WRI TTEN 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
I NI TI ATED DATE
WRI TTEN DATE
27-06-2002
30-01-2004
FI LE CODE
CLASSI FI CATI ON
Public
ELECTRONI C FI LE CODE
https://project.sintef.no/eRoom/informatics/ambiesense/Final Deliverables/D2 revised prior to review.pdf
2
© 2004 The AmbieSense Consortium
IST 2001- 34244
Table of contents
1
EXECUTIVE SUMMARY ...................................................................................................................5
2
INTRODUCTION TO THE AMBIESENSE REFERENCE INFORMATION MODEL ..............6
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3
DOCUMENT OBJECTIVES ..................................................................................................................6
WHAT IS THE AMBIESENSE REFERENCE INFORMATION MODEL? .....................................................6
THE NEED FOR AN AMBIESENSE REFERENCE INFORMATION MODEL ...............................................6
HOW TO USE THE AMBIESENSE REFERENCE INFORMATION MODEL .................................................6
DOCUMENT ROADMAP .....................................................................................................................7
AUDIENCE ........................................................................................................................................7
RELATED PROJECT DOCUMENTS ......................................................................................................7
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
3
© 2004 The AmbieSense Consortium
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
4
© 2004 The AmbieSense Consortium
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.
5
© 2004 The AmbieSense Consortium
IST 2001- 34244
2 I ntroduction to the AmbieSense Reference I nformation
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 D OCUMENT OBJECTI VES
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 W HAT I S THE AMBI ESENSE REFERENCE I NFORMATI ON M ODEL?
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 AMBI ESENSE REFERENCE I NFORMATI ON M ODEL
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 H OW TO USE THE AMBI ESENSE REFERENCE I NFORMATI ON M ODEL
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
6
© 2004 The AmbieSense Consortium
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 D OCUMENT 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 AUDI ENCE
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, contextawareness, 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 D OCUMENTS
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
7
© 2004 The AmbieSense Consortium
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.
8
© 2004 The AmbieSense Consortium
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 I NTRODUCTI ON TO AMBI ESENSE
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:
Wireless
St at ue
communicat ion
Business lounge
Restaurant
Shopping center
Content service providers
Wireless
communicat ion
Context tags
Holds contextual info
about the current
situation around it
Personalised
inf o
Mobile/ traveling users
= Context tag m ount ed anywhere in order t o help t he m obile user get right inform at ion in the right sit uat ion
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.
9
© 2004 The AmbieSense Consortium
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
I nfrastructure, Framew ork 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.
10
© 2004 The AmbieSense Consortium
IST 2001- 34244
Application (examples)
Travel application
News application
Airport application
Map application
AmbieSense Framework (innovation elements)
New digital information channels
Context aware IR and extraction
Context Middleware
Context tags
Infrastructure
Wireless communications: BT, WLAN, GPRS, 3G, Utra WiFi
Handheld computers, PDA and smartphones
Content management infrastructure - OpenCMS, Central 2000
Server technologies - App. Servers, Web Services
Platform independence technologies - Java, agent
frameworks
Search 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. Contextaware 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.
11
© 2004 The AmbieSense Consortium
IST 2001- 34244
3.2 AMBI ESENSE 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.
12
© 2004 The AmbieSense Consortium
IST 2001- 34244
See sections 4.3.8, 4.4, 5.1.7, and 5.3 for more information of this topic.
3.3 AMBI ESENSE FUNCTI ONAL 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 I nformation 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 — I ntelligent 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.
13
© 2004 The AmbieSense Consortium
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-Aw areness
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-Aw are 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.
14
© 2004 The AmbieSense Consortium
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
15
© 2004 The AmbieSense Consortium
IST 2001- 34244
2.
3.
4.
5.
Distribution
Component-based development
Alignment with legacy systems and existing information value chains
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.
2.
3.
4.
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.
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.
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.
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.
16
© 2004 The AmbieSense Consortium
IST 2001- 34244
4.2 ENTERPRI SE VI EWPOI NT – USERS, ROLES AND FUNCTI ONALI TY
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.
Authorities
Trust brokers
Defines and follow up laws
and constraints
Content service providers/
software application providers
Provides content/ applications directly to the user
Content ow ners
Maintains the trust between
the various roles and actors
Own the content that the authors/ providers make
Content providers
Provides content to the owners
Context tag owner
Content authors
Owns the context tag, can hire
administration
Develop and maintain content
Needs to tag info to relevant situations
Context tag administrator
Updates the context tag data
(the description of the context,
,content or applications)
Wireless and wired
Commun icat ion
The mobile user
Traveling around
I ndoor and outdoor
I ndividuals and groups
St at ue
Business lounge
Restaurant
Shopping center
The building-/ area ow ners
Contracts with network owners and access
service providers
Have specific norms and constraints for
system use and visitors
The network ow ner, the netw ork provider, the
access service provider
Owns the network the user accesses at the moment
Provides access to the network
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
17
© 2004 The AmbieSense Consortium
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
Mobile User
Context Tag
Administrator (CTA)
Description
“End user” of the AmbieSense system.
Interacts with information services on
her mobile computer while being on
the move.
Technical administrator of one or more
Context Tags
Content Author
Author of content items
Content Service
Provider (CSP)
Person or organisation offering a
coherent set of information services
Use-Cases
• Retrieve, browse and edit
information on mobile computer
• Maintain personal interests
• Maintain contexts
• Build and maintain CT
infrastructure
• Update CT content
• Maintain CT context space
• Administer CT access rights
• Administer CT software
• Produce content items
•
•
•
•
•
•
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.
18
© 2004 The AmbieSense Consortium
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.
19
© 2004 The AmbieSense Consortium
IST 2001- 34244
Use context
management service
Context-aware
information retrieval
Share content,
context, user context
Use and maintain
user modes
Mark and annotate
interesting info packages
Mobile user
Set personal
interest options
Download content from
content service provider
User authentication
Subscribe to
content services
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 DOMAI N CONCEPTS ARE
20
© 2004 The AmbieSense Consortium
IST 2001- 34244
•
•
•
•
•
User context
Personal calendar
Content
Context tag
Info Package
TASKS FOR THE MOBI LE 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 I MPORTANT 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:
21
© 2004 The AmbieSense Consortium
IST 2001- 34244
Link information
to contexts
Maintain content
(info packages) on tags
Maintain contexts
for each context tag
Search for content
on tag
Context tag administrator
Administrate groups
of context tags
Handle software and
agents for the tag
Develop zones for
context tags
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 DOMAI N CONCEPTS ARE
• User context
• Tag context
• Context template
• Context tag calendar
• Info Package
22
© 2004 The AmbieSense Consortium
IST 2001- 34244
•
•
•
•
User and user group
Context tag
Information zones
Content
TASKS FOR THE CONTEXT TAG ADMI NI STRATOR
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
23
© 2004 The AmbieSense Consortium
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 I MPORTANT 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 [AmbieSenseD3]). 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].
Use content
management system
Link content to
context
Activate and use
payment models
Develop and
administrate contexts
Specify content
behavoiur
Provide content to
the mobile users
Develop and
administrate content/ info
packages
Develop and
administrate context templates
Content service provider
Content provider
Content author
Figure 6: Use case for Content Service Provider ( and content provision roles)
24
© 2004 The AmbieSense Consortium
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 DOMAI N CONCEPTS ARE
• User context
• Context template
• Info Package
• Content
• User and user groups
• Context tag
TASKS FOR THE CONTENT SERVI CE PROVI DER
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
25
© 2004 The AmbieSense Consortium
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 I MPORTANT 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.
26
© 2004 The AmbieSense Consortium
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 COMPUTATI ONAL VI EWPOI NT – AMBI ESENSE FUNCTI ONAL 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.
27
© 2004 The AmbieSense Consortium
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.
28
© 2004 The AmbieSense Consortium
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 I nterface)
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 I nterface 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.
29
© 2004 The AmbieSense Consortium
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 I ntelligence
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, componentbased 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 nonfunctional 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 I nfrastructure for the Distribution of Relevant
I nformation
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-ofthe-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.
30
© 2004 The AmbieSense Consortium
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 contextbased 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)
31
© 2004 The AmbieSense Consortium
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).
32
© 2004 The AmbieSense Consortium
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 Middlew are)
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
33
© 2004 The AmbieSense Consortium
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 Middlew are interfaces
XML I nterface
This interface contains functionality to marshal and unmarshal context representations to and from XML.
Time I nterface
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 I nter f ace
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 I nterface
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 I nterface
This interface contains misc. utility classes like collections that are frequently used in the context
middleware.
Synchronisation I nterface
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 I nterface
This interface defines all the possible events that are generated in the context middleware.
4.3.7
Content management and integration ( CI P)
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.
34
© 2004 The AmbieSense Consortium
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: CI P interfaces
Analysis inter f ace
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).
35
© 2004 The AmbieSense Consortium
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
Netw ork 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 I nterface, applicat ion, and agent interaction
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.
36
© 2004 The AmbieSense Consortium
IST 2001- 34244
Figure 16: Principle interaction pattern User I nterface, 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
37
© 2004 The AmbieSense Consortium
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.
38
© 2004 The AmbieSense Consortium
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 ENGI NEERI NG VI EWPOI NT – H OW
TO BUI LD
AMBI ESENSE APPLI CATI ONS
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.
39
© 2004 The AmbieSense Consortium
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).
40
© 2004 The AmbieSense Consortium
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).
41
© 2004 The AmbieSense Consortium
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.
42
© 2004 The AmbieSense Consortium
IST 2001- 34244
5 I nformation Structures and Processing
The goal of this chapter is to enable the implementation and use of ambient, personalised and contextsensitive 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.
2.
3.
The need for ambient access to relevant information while being mobile
The rapid change of the user's situation (context) imply the rapid change of information needs
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
43
© 2004 The AmbieSense Consortium
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 I NFORMATI ON STRUCTURE VI EWPOI NTS
This section contains the following information structure viewpoints:
•
•
•
•
•
•
•
•
•
5.1.1
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
Context – proposed as a general information structure
At the core of a context sensitive system there must be an information structure to store the contextsensitive 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.
44
© 2004 The AmbieSense Consortium
IST 2001- 34244
-can be part of
1
0..*
*
Content
can be linked to
*
Context
-name: string
-type:string
1
0..*
-can have sub-contexts
-is part of
-has
Attribute
-name: string
-type: data primitive (e.g. boolean, int, float, double, string,.. )
-value: type
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 subcontexts, 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.
45
© 2004 The AmbieSense Consortium
IST 2001- 34244
is described from the viewpoint of >
describes aspects of >
*
0..*
1
1
Context
*
User context
Entity/Actor
Situation
Tag context
< encounters, is within, leaves
*
Other types of contexts
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.
46
© 2004 The AmbieSense Consortium
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
1
0..*
User
context
part
of
Social
context
part
of
Task
context
Personal
context
Environment
context
Spatio-temporal
context
part
of
Mental
context
Physiological
context
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
47
© 2004 The AmbieSense Consortium
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 w ith user contexts
The tag context describes aspects of the situation seen from the context tag's point of view.
Context Tag
1
0..*
Tag context
part
of
Environment
context
part
of
Task
context
Social
context
Spatio-temporal
context
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.
48
© 2004 The AmbieSense Consortium
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.
2.
A shared understanding of what the context is as an information object
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
49
© 2004 The AmbieSense Consortium
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:
0..*
Context
-can consist of
-can be part of
Context template
0..*
-Constrains
-Made from
1
1
-is part of
1
0..*
-has
Attribute
0..*
0..*
0..*
0..*
ValueSet
ValueRange
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].
50
© 2004 The AmbieSense Consortium
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:
User
0..*
0..*
Context
Space
part of
1
>
1
1
< part
of
1
1
Context
History
1
1
Current
Context
< part
of
Future
contexts
part of
>
1
0..*
0..*
Context
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
51
© 2004 The AmbieSense Consortium
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
52
© 2004 The AmbieSense Consortium
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).
accesses content
on
User
can communicate via wireless network
with
Mobile
Computer
Content
can communicate wirelessly
Service
maintains
with
linked to
runs on/linked to
Context Tag
stored on/linked to
Software
Information
Zone
stored on/linked to
occurs
in
Content
Context
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:
53
© 2004 The AmbieSense Consortium
IST 2001- 34244
is used by
0..*
User
is used by
0..*
0..*
0..*
uses
0..*
is used by
uses
0..*
Content
-FileName
-FileSystem
-Input
-Output
-Certificate
-Size
<- is metalayer for
1
1*
Content Template
uses
Content item
1
-Type
-Topics
-Content_URL
-DateCreated
-DateModified
-AccessPeriod
-Owner
-Copyright_URL
-Original
-Interest rating
-language
-ID
Info package
0..*
0..*
-Period
-Topics
-Price
-Currency
-CopyRight_URL
-Certificate
-Owner
-ContentProvider
-ID
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.
2.
3.
4.
5.
Support the development of multi-lingual content services
Utilise content to be managed, indexed, and searched according to topics without the use of
advanced information retrieval and extraction techniques
Enable the reuse of the same content across content services with just-in-time delivery of the
actual content itself to the user
Integrate content with different content distribution and revenue models
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
54
© 2004 The AmbieSense Consortium
IST 2001- 34244
2.
3.
The info package of AmbieSense can be regarded as a super class which is the news envelope of
NewsML
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.
55
© 2004 The AmbieSense Consortium
IST 2001- 34244
N e w sM L con ce pt in br ie f
At t he heart of New sML is t he concept of t he news it em w hich can cont ain various different m edia –
t ext , phot os, graphics, and video - t oget her wit h all t he m et a- inform at ion t hat enables t he recipient
t o underst and t he r elat ionship bet w een com ponent s and under st and t he roles of each com ponent .
Everyt hing t he recipient m ight need t o know about t he cont ent of t he news provided can be included
in New sML’s st ruct ure. For ex am ple, New sML enables publisher s t o provide t he sam e t ex t in
different languages; a video clip in different form at s; or different resolut ions of t he sam e
phot ograph. NewsML’s rich m et adat a concept can help wit h t hings lik e rev ision levels t hat m ake it
easy t o t rack t he evolut ion of a New sI t em over t im e, st at us det ails ( publishable, em bar goed, et c.)
and adm inist rat ive det ails, such as acknow ledgem ent s or copyright det ails.
New sML has default m et adat a vocabular ies t o ease im plem ent at ions but it does not dict at e which
m et adat a vocabulary is used ( I PTC Subj ect Codes, I SO count ry codes et c.) – a providers j ust have
t o indicat e w hich vocabulary t hey ar e using. Mult iple vocabular ies can be ut ilised wit hin t he sam e
New sI t em . For t ext obj ect s in a New sI t em , t he I PTC’s New s I ndust ry Text Form at ( NI TF) is
recom m ended.
New sML is flexible and ext ensible and uses st andard I nt ernet nam ing conv ent ions for ident ify ing t he
news obj ect s in a New sI t em . As such, cont ent does not have t o act ually be em bedded wit hin a
NewsI t em ; point er s can be insert ed t o cont ent held on a publisher’s web sit e inst ead. This m eans
subscribers ret rieve t he dat a only when t hey need t o and t his m akes NewsML bandwidt h- efficient .
S t r u ct u r e o f N e w s M L
Repr esent at ion and m anagem ent of news t hr oughout it s lifecycle is t he aim wit h New sML, while t he
st andard has been designed t o give consider able flexibilit y and allow for st raight forward ext ension t o
suit indiv idual user needs. I nevit ably t his has result ed in a rat her com plex and lay ered st ruct ure t hat
can appear difficult t o underst and. How ever, t her e is no need t o use all t he feat ures - so it would be
possible t o hav e a relat iv ely sim ple im plem ent at ion for, say, t ex t handling - and t he underlying logic
is st raight forw ard.
New sML t akes t he for m of an XML docum ent , which has a series of com ponent s, or elem ent s, t hat
are used t o st r uct ure and process t he act ual news cont ent . These elem ent s m ay have at t ribut es t o
specify t heir propert ies and can carry cont ent in t he form of ot her elem ent s ( sub elem ent s) and/ or
charact er dat a or ext ernal references.
( NewsML™ is a regist er ed Tradem ark of t he I PTC)
( Source: www .new sm l.org, 6 Jan 2004)
5.1.9
Context-aw are access to content via calendars
This section presents one of many possible ways to integrate context technology into existing information
systems without adding extra burdens to the user or changing the user interface. The rationale in adding
context-awareness to a system should always be to add some value to the user by improving certain
qualities of the system.
Context is an extra information object used in a system to make it context-aware. In some cases, the
designer will choose to present the context as an explicit concept for the user to interact with, whilst in
other cases the designer would need to hide it away from the user by integrating it behind the scenes.
Making a system context-aware should be a solution either to enable users interact with more relevant
information than otherwise possible, or to optimise system performance.
We should be concerned about why we should add context technology a system at all, because: 1) there is
no common way of defining, populating, and deploying context-aware applications and services, and 2)
there are many approaches to and definitions of what context is. Consequently there is no common way of
56
© 2004 The AmbieSense Consortium
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.
2.
Let the user interact with the context as an explicit object in the user interface
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.
Situation
User
uses
*
*
Calendar
1
0..*
«interface»
Activity
+getPeriod()
+setPeriod()
+getName()
+setName()
+getType()
+setType()
*
*
Context
1
1
Content
*
*
Figure 30: Context-aw are 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
57
© 2004 The AmbieSense Consortium
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 I NFORMATI ON PROCESSI NG VI EWPOI NTS
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
I nformation 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: I nformation 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
58
© 2004 The AmbieSense Consortium
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: I nformation 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/ .
59
© 2004 The AmbieSense Consortium
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-aw are 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.
60
© 2004 The AmbieSense Consortium
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.
2.
3.
4.
Context itself is used as the query: attributes and values are used for the query formulation
The query can be extracted from the context by using various inference techniques
The query can be explicitly stated by the user and can be amplified by context
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,
61
© 2004 The AmbieSense Consortium
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 w ith focus on context-aw are information retrieval
62
© 2004 The AmbieSense Consortium
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
63
© 2004 The AmbieSense Consortium
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
64
© 2004 The AmbieSense Consortium
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.
65
© 2004 The AmbieSense Consortium
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:
•
•
•
•
5.2.5
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.)
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.
2.
3.
4.
5.
6.
7.
8.
A context can be linked to content items
A context can be linked to info packages
An attribute of a context can be linked to content items
An attribute of a context can be linked to info packages
The value of an attribute of a context can be linked to content items
The value of an attribute of a context can be linked to info packages
A content item can be linked to content items
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).
66
© 2004 The AmbieSense Consortium
IST 2001- 34244
User
Query
Content Service
Matching
Link
Context Space
-from: entity
-to: entity
-relevance: number
ContentBase
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.
2.
3.
Automatically when indexing the content
Manually by the end-users
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.
67
© 2004 The AmbieSense Consortium
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 D ETAI LED CLASS D ESCRI PTI ONS
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.
68
© 2004 The AmbieSense Consortium
IST 2001- 34244
I nterface: 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
String GetName ()
Void SetName (String theName)
String GetType ()
Void SetType (String theType)
Period GetPeriod ()
Void SetPeriod (Period thePeriod)
Void AddPeriod (Period thePeriod)
Void RemovePeriod (Period
thePeriod)
Definition
Returns the name of the activity. Examples can be "the travel to
London", "Project meeting", "The Nova Bar" and so on.
Sets the name of the activity
Returns the type of the activity as a string
Sets the type of the Activity. Examples can be: "appointment",
"meeting", "travel", "eat", "do", "walk", "sleep" and so on.
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.
Sets the period of the activity with the start and stop.
Adds a period to the activity (e.g. a recurring period)
Removes a period from the activity (e.g. a recurring period)
69
© 2004 The AmbieSense Consortium
IST 2001- 34244
Associations
No. Role
1.
An activity can be part of zero or many calendars (plans/activity lists)
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).
Target
Calendar
Context
Cardinality
0..*
1
I mplemented by classes
Context
70
© 2004 The AmbieSense Consortium
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
FileName: String
Definition
Name of the file.
IsFolder: Boolean
Attributes : Hash Table
Input : Stream
Output :Stream
Certificate
Size : Long Integer
An indicator whether the URL pointing at is a folder or a file
Attributes of the content
Input Stream to read the content's of the file.
Output Stream to write the content's to a file.
Certificate for the content.
Size information about the content.
Associations
No. Role
1.
A Content can be linked to zero or many Content Item
Target
Content Item
Cardinality
0..*
Generalisation
Super-class
N/A
Sub-classes
N/A
I mplemented interfaces
N/A
71
© 2004 The AmbieSense Consortium
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
ID: Integer
User :User
Password: String
FileSystem: URL
Definition
Unique identifier for this Content Base.
The user name to use the Content Base.
The password to use the Content Base.
File System Name, which the Content Base uses.
Associations
No. Role
1.
A Content Base can store zero or many Content Items
2.
A Content Base can store zero and many Info Packages
3.
A Content Base can be used by zero or many Users
4.
A Content Base can be associated with zero or many instances of
Content Service
Target
Content Item
Info Package
User
Content
Service
Cardinality
0..*
0..*
0..*
0..*
Generalisation
Super-class
N/A
Sub-classes
N/A
I mplemented interfaces
N/A
72
© 2004 The AmbieSense Consortium
IST 2001- 34244
Class: Content I tem
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
Type: String
Topics: String
Content URL: URL
Definition
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.
A string of topics that describe the Content Item (can of course another data type
than string of needed).
URL to content.
73
© 2004 The AmbieSense Consortium
IST 2001- 34244
Date Created
Date Modified
AccessPeriod: Period
Owner:String
Copyright URL: URL
Original: Boolean
Interest Rating: Integer
Date of creation.
Date of modified.
Period, which this Info Package can be consumed.
Owner Information.
URL to copyright information.
This attribute identifies whether this Content Item is original or not.
Rating information about the Content Item.
Associations
No. Role
1.
A Content Item can contain one Content
2.
A Content Item can be a part of zero or many Info Packages
3.
A Content Item can be stored in a Content Base
4.
5.
A Content Item can be associated with zero or many instances of
Context
A Content Item can be part of zero or many content services
Target
Content
Info Package
Content
Base
Context
Cardinality
1
0..*
1
Content
service
0..*
0..*
Generalisation
Super-class
N/A
Sub-classes
N/A
I mplemented interfaces
N/A
74
© 2004 The AmbieSense Consortium
IST 2001- 34244
I nterface: 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
GetName()
GetType()
GetProvider()
GetAgreement()
GetContextSpace()
GetContentBase()
GetContextTags()
GetInformationZones()
GetSearchEngine()
GetPush()
Definition
Returns the name of the content service.
Returns the type of the content service.
Returns the name of the content service provider.
Returns the agreement text for accessing the content of the
content service, installing and using the involved software etc.
Returns a reference to the available context space of the content
service.
Returns a reference to the available content base of the content
service.
Returns a reference to the set of available context tags that
provides access to the content service.
Returns a reference to the available information zones of the
content service. An information zone is linked to a context tag.
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).
Returns a reference to the available push service of the content
service. (Sometimes a part of the content management system).
75
© 2004 The AmbieSense Consortium
IST 2001- 34244
GetPull()
GetApplicationSoftware()
Subscribe(User, Boolean)
Include(User, User group, Boolean)
SignIn(User, User group, password,
certificate)
SignOut(User, User group, password,
certificate)
Returns a reference to the available pull service of the content
service. (Sometimes a part of the content management system).
Returns a reference to the available application software. Allows
the installation of application software and access to the content
service.
Subscribes/ un-subscribes a user from the content service.
Includes a user to a user group, or un-includes the user from the
user group.
Signs in a user to the content service.
Signs out a user from the content service.
Associations
No. Role
Target
1.
A content service maintains zero or more information zones
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.
A content service can provide access to zero or many context spaces
– both its own and the customer's context space.
A content service can provide access to zero or many content bases.
The content service can have zero or many users
The content service can have zero or many user groups
The content service can implement several push and pull mechanisms
for content distribution.
3.
4.
5.
6.
7.
Information
zone
Context Tag
Cardinali
ty
0..*
0..*
Context Space
0..*
Content Base
User
User group
Push/Pull
0..*
0..*
0..*
0..*
I mplemented by classes
N/A
76
© 2004 The AmbieSense Consortium
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
ID: String
Name: String
Contexts: Contexts
Attributes: Attributes
Type: String
Definition
The ID of the context making this context unique and easily accessible by using
the specific ID
The name of the context describing this context with as few words as possible
A context may consist of many context, these will be listed in this list. This list
will consist of Context object references.
Each context may have a set of attributes, those will be listed here
The type or category this context is part of
Associations
No. Role
Target
Cardinality
77
© 2004 The AmbieSense Consortium
IST 2001- 34244
1.
2.
3.
4.
5.
6.
7.
8.
A context can be part of the context history, which can contain zero
or many contexts of the past.
A context can be part of the context future, which can contain zero or
many contexts upcoming contexts (for instance planned or
anticipated).
The context is describing the aspects of the situation seen from one
actor’s point of view.
Context can in general be changed and used by any kind of software
components
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)
When a context is changed, this can be observed by any kind of
software component that would like to observe the change.
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.
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.
Context
History
Context
Future
1
Actor
1
Software
0..*
Content Item
0..*
Observer
1
Content
0..*
Calendar
0..*
1
Generalisation
Super-class
N/A
Sub-classes
User Context
Tag Context
Other kinds of contexts…
I mplemented interfaces
Activity
78
© 2004 The AmbieSense Consortium
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
Current Context
ID
Context history:
Contexts
Context future:
Contexts
Definition
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.
Unique ID of a context space. Used to separate context spaces when several
context spaces exist
The context history is a part of the context space.
The context history is a part of the context space.
Associations
No. Role
1.
A context space can have one or many users
Target
User
Cardinality
1..*
Generalisation
Super-class
N/A
Sub-classes
N/A
I mplemented interfaces
N/A
79
© 2004 The AmbieSense Consortium
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 1030 metres depending on the hardware used.
Attributes
Name and type
Name: String
Description: String
Definition
Specifies the name of the context tag
Describes the tag and the surroundings with text
80
© 2004 The AmbieSense Consortium
IST 2001- 34244
geo-position: Geocoordinate
Location: String
Vicinity: Integer
IP address
DHCP-address
Connected clients
Content Base
Context Space
Administrator: User
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 geopositioning software.
Specifies the location of the context tag by some text.
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.
Contains the current IP-number of the context tag, if it is a client in a network.
Contains the DHCP-address of the context tag, if it is has a DHCP server
installed to provide the mobile clients with IP-numbers.
A list of IP-numbers for the connected clients (mobile computers). The IPnumbers are provided by the DHCP-server on the tag, if installed.
A reference to the content base for the context tag. It can be installed locally on
the context tag, or remotely in the network
A reference to the context space for the context tag. It can be installed locally on
the context tag, or remotely in the network
Specifies an administrator for the context tag
Associations
No. Role
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.
2.
Context can be linked to/ stored on the context tag, depending of the
features of the context tag.
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.
4.
Users and can be registered in order to connect to the context tag,
depending on the features of the context tag.
5.
A context tag is a part of zero or more content services.
6.
A context tag can be linked to zero or more information zones.
Target
Content
Cardinality
0..*
Context
0..*
Software
0..*
User
0..*
Content
service
Information
zone
0..*
0..*
Generalisation
Super-class
N/A
Sub-classes
N/A
I mplemented interfaces
N/A
81
© 2004 The AmbieSense Consortium
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
Name: String
Type: String
Context Templates
Attribute
Definition
Constrains that all contexts should have a name.
Constrains that each context should have a type.
A Context Template can consist of sub context templates that the corresponding
sub-contexts of a context should be compared and validated with.
Attributes can be part of a context template.
Associations
No. Role
1.
ValueSets are used to constrain the set of legal values that an
attribute can have in a context.
2.
ValueRanges are used to define the valid values of attributes that
complies to a Context Template
3.
Context Templates are used to constrain the structure of a certain
type of contexts stored in a context space.
4.
A context template constrains a context.
Target
Value Set
Cardinality
0..*
ValueRange
0..*
Context Space
0..*
Context
1
Generalisation
Super-class
N/A
Sub-classes
N/A
I mplemented interfaces
N/A
82
© 2004 The AmbieSense Consortium
IST 2001- 34244
Class: I nfo 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
Period
Topics
Price
Currency
Copyright URL
Certificate
Owner
Content provider
ID
Definition
Period, which this Info Package can be consumed.
A set of topics, which describes Info Package.
Price of the Info Package.
This attribute specifies the currency for the price of the Info Package.
URL to copyright information.
Certificate for the Info Package
Owner of the Info Package
Contains the name of the content service provider
This is a unique identification number, which is assigned to each Info Package.
Associations
No. Role
1.
An Info Package can contain zero or many Content Items
2.
An Info Package can be used by users.
3.
An Info Package can be stored in a Content Base
4.
An Info Package can be linked with zero or many of contexts
5.
An Info Package can be part of zero or many content services
Target
ContentItem
User
ContentBase
Context
Content
service
Cardinality
0..*
0..*
1
0..*
0..*
83
© 2004 The AmbieSense Consortium
IST 2001- 34244
Generalisation
Super-class
N/A
Sub-classes
N/A
I mplemented interfaces
N/A
84
© 2004 The AmbieSense Consortium
IST 2001- 34244
Class: I nformation 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
Name: String
Description: String
Area: Shape
Anchor point: Geocode (String)
Definition
Contains the name of the information zone.
Contains the description of the information zone (e.g. pure text which might
describe the physical environment of the information zone).
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).
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
1.
Information zones are maintained by the content service.
2.
3.
An information zone is linked to zero or many context tags.
Content occurs in information zone
Target
Content
Service
Context tag
Content
Cardinality
0..*
0..*
0..*
85
© 2004 The AmbieSense Consortium
IST 2001- 34244
Generalisation
Super-class
N/A
Sub-classes
N/A
I mplemented interfaces
N/A
86
© 2004 The AmbieSense Consortium
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
Environment context:
Context
Task context: Context
Social context: Context
Spatio-temporal context:
Context
Definition
Can contain attributes and new sub-contexts related to the
environment/surroundings around the context tag.
Can contain attributes and new sub-contexts related to what persons (actors) are
doing around the tag.
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
Can contain attributes and new sub-contexts related to the spatio-temporal
situation for the context tag.
Associations
No. Role
1.
The tag context must be validated towards the general tag context
template.
Target
Tag Context
Template
Cardinality
1
Generalisation
Super-class
Context
Sub-classes
N/A
I mplemented interfaces
N/A
87
© 2004 The AmbieSense Consortium
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
Name
Password
Login
Certificates
Definition
The user's name
The password of the user
Login of the user
The certificates of the user
Associations
No. Role
1.
A user can subscribe to or access content, content items, and info
packages in zero or more content services
2.
A user can own or subscribe to zero or more context spaces
3.
A user can have access rights to software
Target
Content
Service
Context
Space
Software
Cardinality
0..*
0..*
0..*
Generalisation
Super-class
N/A
Sub-classes
N/A
I mplemented interfaces
N/A
88
© 2004 The AmbieSense Consortium
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 spatiotemporal extent.
Attributes
Name and type
EnvironmentContext:
Context
PersonalContext:
Context
TaskContext: Context
SocialContext: Context
SpatioTemporal
Context: Context
Definition
Can contain attributes and new sub-contexts related to the
environment/surroundings around the user.
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.
Can contain attributes and new sub-contexts related to what both the user himself
and other persons (actors) are doing around the user.
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.
Can contain attributes and new sub-contexts related to the spatio-temporal
situation for the user himself.
Associations
No. Role
1.
The user context must be validated towards the general user context
template.
Target
User
Context
Template
Cardinality
1
Generalisation
Super-class
Context
Sub-classes
N/A
I mplemented interfaces
N/A
89
© 2004 The AmbieSense Consortium
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
Users
ID
Name
Definition
A User Group will consist of potentially many users; they are collected in a list
with a reference to each user.
Each user group has an ID that is unique
Each user group has a name describing the group.
Associations
No. Role
1.
A user can subscribe to or access content, content items, and info
packages in zero or more content services
2.
A user can own or subscribe to zero or more context spaces
3.
A user can have access rights to software
Target
Content
Service
Context
Space
Software
Cardinality
0..*
0..*
0..*
Generalisation
Super-class
N/A
Sub-classes
N/A
I mplemented interfaces
N/A
90
© 2004 The AmbieSense Consortium
IST 2001- 34244
6 Appendixes
6.1 CONTACT I NFORMATI ON
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 welldefined task.” (http://www.webopedia.com/TERM/a/agent.html)
Ambient I ntelligence
I nfrastructure
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 contextaware 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 I tem
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.
91
© 2004 The AmbieSense Consortium
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 Ow ner
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.
92
© 2004 The AmbieSense Consortium
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.
I nfo 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.
I nformation structure
Any model whose primary subject is the world that the computer system
is supporting.
93
© 2004 The AmbieSense Consortium
IST 2001- 34244
I nformation 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 I nterface
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.
New sML
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, contextsensitive 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
94
© 2004 The AmbieSense Consortium
IST 2001- 34244
Physical I nterface
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.
95
© 2004 The AmbieSense Consortium
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 Spatiotemporal 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 ABBREVI ATI ONS
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
ARI M
AmbieSense Reference Information Model
BT
Bluetooth
CBR
Case-Based Reasoning
CI P
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
FI PA
Foundation for Intelligent Physical Agents
96
© 2004 The AmbieSense Consortium
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
I I OP
Internet Inter-Orb Protocol
I PTC
International Press Telecommunications Council
IR
Information Retrieval
I SO
International Organization for Standardization
JADE
Java Agent DEvelopment framework
LEAP
Lightweight Extensible Agent Platform
MAS
Multi-Agent System
MPEG
Moving Picture Experts Group
New sML
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
RI M
Reference Information Model
RM-ODP
Reference Model - Open Distributed Processing
SSL
Secure Sockets Layer
TCP/ I P
Transmission Control Protocol /Internet Protocol
97
© 2004 The AmbieSense Consortium
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 I NFORMATI ON STRUCTURES FOR APPLI CATI ONS
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
New s/ Events/ I nformation 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 saxplayers 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.
98
© 2004 The AmbieSense Consortium
IST 2001- 34244
1.
2.
3.
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.
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.
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.
Edit interests
Rate
news/events/information
Subscribe to
news/events/information
Mobile user
Recommend
news/events/information
Read
news/events/information
Discard
news/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).
Create
news/events/information
Revise
news/events/information
Content Author
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
99
© 2004 The AmbieSense Consortium
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.
Verify
news/events/information
Publish
news/events/information
Content Service Provider
Create info
packages
Compile
news/events/information
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.
Maintain
news/events/information on Context
Tag
Receive
news/events/information
Context Tag Administrator
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.
M OBI LE 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 ADMI NI STRATOR
There are no application specific tasks for the CTA. The suggested generic tasks are:
100
© 2004 The AmbieSense Consortium
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 news/events/information.
•
Revise news/events/information.
•
CONTENT SERVI CE PROVI DER
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
•
I nformation St 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)
101
© 2004 The AmbieSense Consortium
IST 2001- 34244
User
-Login
-Password
-Name
*
*
Software
-License number
-Version
-Manufacturer
-Licensed to
*
*
Info package
-Period
-Topics
-Price
1
*
Content item
-ContentItemID
-ContentItemType
-FirstCreated
-ThisRevisionCreated
-Status
-RevisionHistory
-Copyright
-Interest rating
-URL
-Topic
News Item
Event
-Provider
-Location
-Date
-Category
*
*
*
*
Kalends
NewsML
Figure 40: New s/ Events/ I nformation 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
102
© 2004 The AmbieSense Consortium
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/ I nformation 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
-Login
-Password
-Name
User context
Social context
Task context
Personal context
-Role
Mental context
Environment context
Spatio-temporal context
-Location
-Provider
-User
-Usergroup
-Start_time
-End_time
-Start_date
-End_date
-All_day
Physiological context
-Topics
-Category
-Preferred language
Figure 41: User Context information structure
Social context:
Element
Role
Task context:
Element
Travel destination
Information (examples)
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.
Information (examples)
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.
103
© 2004 The AmbieSense Consortium
IST 2001- 34244
Category
Preferred language
Environment context:
Element
Location
Provider
User
Usergroup
Spatio-temporal context:
Element
Time
Lower level categories of interests.
News/events/information is presented in the user’s native language.
Special topics, related to the nationality of the user might be considered, too.
Information (examples)
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.
Information about the providers of information in the environment.
Information about other users in the environment.
Information about other user groups in the environment.
Information (examples)
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 I NFORMATI ON STRUCTURE
Tag context
Environment context
-Location
-Provider
-User
-Usergroup
Task context
Social context
Spatio-temporal context
-Role
-Start_time
-End_time
-Start_date
-End_date
-All_day
Figure 42: Tag context information structure
Environment context:
Element
Location
Provider
User
Information (examples)
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.
Information about the providers of information in the environment.
Information about other users in the environment.
104
© 2004 The AmbieSense Consortium
IST 2001- 34244
Usergroup
Social context:
Element
Role
Spatio-temporal context:
Element
Time
6.4.2
Information about other user groups in the environment.
Information (examples)
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.
Information (examples)
Different “types” of news/events/information might be presented, depending
on the local time.
Context-aw are 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:
105
© 2004 The AmbieSense Consortium
IST 2001- 34244
Mobile user
Shop
Entertainment
Arrive/Leave
Find and use
airport service
Transfer
Figure 43: Context Aw are 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)
M OBI LE 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.
CONTEXT TAG ADMI NI STRATOR
There are no application specific tasks for the CTA. The suggested generic tasks are:
106
© 2004 The AmbieSense Consortium
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 SERVI CE PROVI DER
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
•
I nformation 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
Today’s flight
The flight I am currently waiting for, be I arriving, departing or picking up
someone
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
107
© 2004 The AmbieSense Consortium
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
Brochure
Lounge
News, what happens in the area
Leaflets and the like that you normally have picked up from a stand can now
be downloaded
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
Shop
Airway company
Special offers from shops
Information on the shops on the airport. Opening hours, directions…
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.
108
© 2004 The AmbieSense Consortium
IST 2001- 34244
User
-Login
-Password
-Name
-Role
Context
-ID
-Name
-Contexts
-Attributes
-Type
Software
-License number
-Version
-Manufacturer
-Licensed to
Content
Info package
-Period
-Topics
-Price
Content item
Infotaintment
Brochure
Offer
Airway company
-ContentItemID
-ContentItemType
-FirstCreated
-ThisRevisionCreated
-Status
-RevisionHistory
-Copyright
-Interest rating
-Content identification
-URI
-Content data
Lounge
Map
Shop
Today's flights
My flight
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.
109
© 2004 The AmbieSense Consortium
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 I NFORMATI ON STRUCTURE
User
-Login
-Password
-Name
-Role
User context
Social context
Task context
-Role
-Task
Personal context
Environment context
Spatio-temporal context
-Services
-Location
Mental context
Physiological context
-Interests: Topics
Figure 45 User context information structure
Social context:
Element
Role
Task context:
Element
Task
Personal context:
Element
Information (examples)
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 workrelated 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
Information (examples)
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.
Information (examples)
110
© 2004 The AmbieSense Consortium
IST 2001- 34244
History
Personal information
User mode (leisure/work)
Help relative to been here before. What did he do last time
Shops, recreation etc being stream-lined to user preferences
Helps decide to what extent information is to be given
Environment context:
Element
Services
Location
Information (examples)
Show the information on the closest tag
Go to gate, route to point of interest, nearby shop and dining offers
Spatio-temporal context:
Element
Time
Information (examples)
Go to gate, transportation from airport, suggesting leisure activities
TAG CONTEXT I NFORMATI ON 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
Social context
Environment context
Task context
-Role
-Services
-Location
-Task
Spatio-temporal context
Figure 46: Tag Context information structure
Social context:
Element
Role
Environment context:
Element
Services
Location
Task context:
Element
Tasks
Information (examples)
The
Information (examples)
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.
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.
Information (examples)
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
111
© 2004 The AmbieSense Consortium
IST 2001- 34244
shopping, possible with the use of maps.
Spatio-temporal context:
Element
Time
Information (examples)
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 timerelated 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.
112
© 2004 The AmbieSense Consortium
IST 2001- 34244
Stay
Night
See
Doing
Planning
Shop
Eat
Facts
Getting there (and
away)
Use travel guide
Being there
Mobile user
Figure 47: Context-aw are 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.
M OBI LE 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.
113
© 2004 The AmbieSense Consortium
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.
CONTEXT TAG ADMI NI STRATOR
There are no application specific tasks for the CTA. The suggested generic tasks are:
•
•
•
•
•
•
•
•
•
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 SERVI CE PROVI DER
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
114
© 2004 The AmbieSense Consortium
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
I nformation structures
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.
115
© 2004 The AmbieSense Consortium
IST 2001- 34244
User
-Login
-Password
-Name
Context
-ID
-Name
-Contexts
-Attributes
-Type
Software
-License number
-Version
-Manufacturer
-Licensed to
Content
Info package
-Period
-Topics
-Price
Calendar
-Flash back
Content item
-ContentItemID
-ContentItemType
-FirstCreated
-ThisRevisionCreated
-Status
-RevisionHistory
-Copyright
-Interest rating
-Topic
-URL
Place of interest
-ContextTagID
-POI_ID
-GeoCode
Eat
-OpenLate
-Alcohol
-Nightclub
-Bar
-Entertainment
-Instance of
*
Stay
See&Do
-bar
-Pool
-Gym
-Parking
-children
-Eat
Shopping
Entertainment
-sale
-specialFeature
-OpenLate
-openLate
-entertainment
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 I NFORMATI ON STRUCTURE
116
© 2004 The AmbieSense Consortium
IST 2001- 34244
User
User context
Social context
-Role
Task context
Personal context
Environment context
Spatio-temporal context
-Location
-Traffic conditions
-Weather
-Activity
Mental context
Physiological context
-Interests: Topics
-Travel range
Figure 49: User Context information structure
Social context:
Element
Role
Task context:
Element
Activity
Mental context:
Element
Interests: Topics
Travel range
Environment context:
Element
Location
Weather conditions
Traffic
Information (examples)
We play different roles when we interact with each other. The travel guide
has another role than the tourist following the guide.
Information (examples)
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.
Information (examples)
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.
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.
Information (examples)
The user’s current location might be significant when suggesting places to
visit etc.
The weather conditions may impact the user’s willingness to see certain PoI.
Similar to the weather conditions.
TAG CONTEXT I NFORMATI ON STRUCTURE
This is the tag context information structure that is specific for the travel guide services domain:
117
© 2004 The AmbieSense Consortium
IST 2001- 34244
Tag context
Social context
Task context
Environment context
-Role
-Activity
-Location
-Traffic conditions
-Weather
Spatio-temporal context
Figure 50:Tag context for travel guide services domain
Social context:
Element
Role
Task context:
Element
Activity
Environment context:
Element
Location
Weather conditions
Traffic
6.4.4
Information (examples)
We play different roles when we interact with each other. The travel guide
has another role than the tourist following the guide.
Information (examples)
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.
Information (examples)
The user’s current location might be significant when suggesting places to
visit etc.
The weather conditions may impact the user’s willingness to see certain PoI.
Similar to the weather conditions.
Context-aw are 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:
118
© 2004 The AmbieSense Consortium
IST 2001- 34244
Navigate in Map
Execute POI Search
Tag Meeting-Point
Show User Location
Calculate Route
Generate Map
Mobile User
Figure 51: Context-Aw are 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.
M OBI LE 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.
119
© 2004 The AmbieSense Consortium
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.
CONTEXT TAG ADMI NI STRATOR
There are no application specific tasks for the CTA. The suggested generic tasks are:
•
•
•
•
•
•
•
•
•
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 SERVI CE PROVI DER
• 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.
I nformation structures
In the following, an overview of the map service domain is given.
120
© 2004 The AmbieSense Consortium
IST 2001- 34244
User
-Login
-Password
-Name
Calender
User context
Software
-License number
-Version
-Manufacturer
-Licensed to
Info package
-Descriptions
-Background
-Personal
-Task
-Environment
-Spatio-temporal
-Social
Point of interest
Map context
-Period
-Topics
-Price
-Category
-Location: Geocode
-Scale
-Rotation
Content item
-ContentItemID
-ContentItemType
-FirstCreated
-ThisRevisionCreated
-Status
-RevisionHistory
-Copyright
-Interest rating
-Topic
-URL
Route
Map
-Map elements
-Layers
*
*
-Start
-Interstation
-Destination
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.
121
© 2004 The AmbieSense Consortium
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
Environment
Region structure (city centre, environs etc.)
Effect in map
Focus of map
Distance of routing
Vehicle for travelling
Route optimisation
Places to visit
Distance of routing
Places to visit
Vehicle for travelling
Places to visit
Places to visit
Weather
-
Physical condition
-
Physical abilities or disabilities
-
Mental condition (bad, good mood etc.)
-
Region knowledge
-
Task
Task
-
Social
Relations (people who share interests etc.)
-
User group category
-
Steepness / high difference
-
Movement tracking
-
Vehicle for travelling
Route optimisation
Places to visit
Travel time
-
Places to visit
Vehicle for travelling
Personal
Spatio-temporal
Places to visit
General, special map
Position tracking
Places to visit
Places to meet
General, special map
Places to meet
Position tracking
Meeting point
Places to meet
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).
122
© 2004 The AmbieSense Consortium
IST 2001- 34244
User Context
Map Agent
Context
Aware App
Analyzer
Request
Representation
Request
Request Handler
Rules
Result Request
Result Manipulator
Result
Map Service
Request
Map Service
Figure 53: Context Aw are 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.
123
© 2004 The AmbieSense Consortium
IST 2001- 34244
User
Context
Context
Analyzer
Rules
Result
Analyzer
Repres.
Analyzer
Request Handler
Result
Request
Representation
Request
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.
124
© 2004 The AmbieSense Consortium
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/9923.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 ContextAware 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
125
© 2004 The AmbieSense Consortium
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
126
© 2004 The AmbieSense Consortium
IST 2001- 34244
6.6 FI GURES
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
127
© 2004 The AmbieSense Consortium
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
128
© 2004 The AmbieSense Consortium
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
129
© 2004 The AmbieSense Consortium