=Paper=
{{Paper
|id=Vol-146/paper-4
|storemode=property
|title=A Layered Model for User Context Management with Controlled Aging and Imperfection Handling
|pdfUrl=https://ceur-ws.org/Vol-146/paper3.pdf
|volume=Vol-146
|dblpUrl=https://dblp.org/rec/conf/ijcai/Schmidt05
}}
==A Layered Model for User Context Management with Controlled Aging and Imperfection Handling==
https://ceur-ws.org/Vol-146/paper3.pdf
A Layered Model for User Context Management with
Controlled Aging and Imperfection Handling
Andreas Schmidt
FZI Research Center for Information Technologies, Karlsruhe, Germany
Andreas.Schmidt@fzi.de
Abstract. Current research in context-awareness is biased toward low-level con-
text information. High-level context information, however, poses several chal-
lenges to context management systems, which can be traced back to the asyn-
chronicity of context acquisition and use and the inherent dynamics and imperfec-
tion in that process. This paper presents a three layer model allowing for dealing
with the problems of imperfection and aging in a controlled way. It conceives the
problem of high-level user context management as an information management
problem with specific requirements.
1 Introduction
1.1 The Need for High-Level Context Information
With the ever-increasing volume of accessible information and the advent of ubiquitous
information access via mobile and wearable devices, the focus of information systems
research has shifted to increasing the efficiency of information access for the user. This
encompasses both simplifying the query formulation process and improving the rele-
vance of query results. In general, there is a trade-off between preciseness (and thus
selectivity) of queries and ease of query formulation. The most promising approach is
to incorporate information about the user and her current situation (i.e., her ”context”
[1]), which is the fundamental approach in context-aware and situation-aware systems.
The upsurge of interest in context-awareness has mainly occurred in the area of
low-level context information as defined by [2], which represents information about the
user’s context that can be directly sensed (or obtained) or aggregated from this sensor
data in a relatively straight forward way (although the concrete implementation may still
pose severe problems). The most prominent examples here are location-aware systems.
But recently, it has been discovered that the consideration of context is a key enabler
for next-generation information services on a much broader scale. One example are
e-learning and knowledge management systems ([3], [4]), which require rather high-
level context information like tasks, business process steps, or the information whether
a person currently is under time pressure or has some time to learn.
Apart from determining how the context influences the information need of a user,
the key problem in these systems is how to keep the user context information up to
date, which includes both the acquisition and the management of such information over
time. In general, only indirect methods can be used for high-level context information,
and several sources of context information have to be considered. Some information
27
can be derived from the user’s interaction with a specific applications, other pieces can
be obtained from data stored in other systems, e.g., in a corporate environment from
Human Resources data, Workflow Management Systems [5], or Personal Information
Managers (addresses, calendar etc.), still others can be retrieved on demand with spe-
cialized operations (e.g., localization in wireless networks). It has been realized (see
also [6]) that this complexity should be hidden from a context-aware application by es-
tablishing a ”user context management” middleware (or ”broker architecture” [7]) that
provides applications with an up-to-date view of the user’s current context, partially
materializing it, partially retrieving it dynamically from other sources.
1.2 Challenges for High-Level User Context Information Management
However, this idea faces several challenges, which cannot be adequately met by existing
information management solutions [8]:
– Dynamics. The context of a user continuously changes. Different features of the
context change at different pace; e.g., name and occupation change less frequently
than location or current task. Additionally, we have to distinguish between context
evolution and context switching. In the latter case, part of the context changes, but it
is quite likely that it later changes back again so that we should store the information
for later use. Typical examples are private and professional information, project-
specific context and role-specific context.
– Imperfection. User context information is typically collected via indirect meth-
ods that observe a user’s behavior and infer facts from these observations. These
methods do not yield certain results, in some case they are more, in other cases less
probable (uncertainty). Additionally, some of the information cannot be determined
exactly (imprecision). The most typical example here is location information. De-
pending on the method (GSM, GPS, etc.), the precision of the information can vary
a lot, which is particularly important for the most prominent examples of context-
aware services: location-based services. Additional aspects of imperfection in the
area of user context information are incompleteness and (as we collect it from sev-
eral sources and/or with a variety of methods) inconsistency.
1.3 Overview
In the remaining part of this paper, a context information architecture is presented that
is able to deal with these two challenges. First, the specific requirements posed by high-
level context information to the respective management infrastructure are briefly dis-
cussed. Then a basic layered context information architecture is introduced that deals
with the problems of aging and imperfection. In the following section, an extension
with the concept of subcontexts is introduced that improves the handling of the dy-
namic nature of user context information. In section 4, there will be an overview of the
prototypical implementation in the project ”Learning in Process”.
28
1.4 Specific Requirements for a Suitable Context Model
The context information architecture proposed in this paper focuses on the so far ne-
glected issue of high-level context information as defined by [2]. This differs from
mainstream context-awareness research because it poses special requirements to a con-
text management infrastructure. The differences can be traced back to a main distinc-
tion: Asynchronicity. In contrast to low-level context information, high-level context
information typically cannot be continuously monitored (via sensors) or determined on
demand at any instant in time (e.g. GPS positioning). Rather – due to the required com-
plex abstraction process –, the system has to collect in advance information about the
user and make it persistent over time. This ”materialized” approach introduces several
problems (which can be ignored in low-level context settings):
– Aging. It should be obvious that collected context is not valid indefinitely. If the
system gets to know about the current ”task” of the user, this information will only
be valid for a limited amount of time. As a consequence, the user context manage-
ment system needs to have some aging mechanism.
– Variability in dynamic behavior. The closer inspection of the ”aging” problem
reveals that aging is not uniform across the different aspects of user context infor-
mation. While information like name, birthdate changes infrequently to never, other
aspects like personal skills, interests goals evolve over time, and tasks or location
are highly volatile. So the aging support has to be specific for the different parts of
the context.
– Reasoning over time. The methods used to derive more abstract user context in-
formation typically do not solely rely on the current user’s context, but also on the
history in order to detect patterns.
– Scalability. If we want to materialize user context information, we have to select
methods that are scalable with respect to large numbers of users and long time
frames.
2 Layered Context Model
2.1 General Considerations
Current approaches to context modelling like [9] or [10] and to applying context aware-
ness to the e-learning and similar domains like [11], [12], [13] emphasize the potential
of applying Semantic Web technologies to user context management. It enables the
creation of more semantically aware processing methods, especially by introducing a
shared vocabulary, which can be used across different tools and systems, and by apply-
ing reasoning techniques based on domain knowledge. But Semantic Web technologies
have still quite a way to go for solutions that are comparable in terms of scalability with
traditional information management solutions. To take that into account, the context
model presented here was developed as a data model (in the tradition of relational or
object-oriented databases) whose core does not depend on those reasoning techniques,
but which can integrated smoothly with those techniques if a domain-specific schema
requires it.
29
The second issue is directly related to the architecture of user context information
management systems. For traditional database management systems, it has proven ef-
fective to divide the management functionality into different layers which are basically
independent of the internal logic of the lower layers. In that spirit, we want to present a
three layer model that allows for structuring the problem in a better way (see figure 1):
– External Layer. This layer represents the usage context of a particular application
at a certain instant of time. The context information in the schema the application
understands, and also certain quality criteria (like minimum confidence) are guar-
anteed.
– Logical Layer. This layer provides a complete view on the context of a user at
a specific instant in time together with the imperfection metadata that allows for
determining the reliability of the stored information.
– Internal Layer. The internal layer stores all collected information about users in a
time-dependent way.
External Layer
Usage Context application-specific
context schemas
View restricting to certain features and
quality criteria
Logical Layer
Context Feature Values
global context schema
View restricting to user and time instant
Context Information Base
Context facts Internal Layer
Fig. 1. Layered Context Model
In analogy to database systems, we begin with describing the logical layer (which
corresponds, e.g., to the relational data model), then explain the internal layer and how
the internal layer maps to the logical layer, before explaining the external layer (which
corresponds to the concept of views) and how the mapping to this layer is realized.
30
2.2 Logical Model
The primary construct of the data model to describe the context of a user is the context
feature, which corresponds to attributes (in case of the relational or object-oriented data
model) or properties (in case of RDF(S) and other conceptual data models like OWL).
Context features are described by a unique identifier (URI), a value space, and cardi-
nality constraints (whether it is multi-valued or not). The value space can either consist
of atomic data types (like numbers, dates etc.) or of concept or instance identifiers ref-
erencing elements from an ontology. That way, also inferencing on the value level is
possible by reusing description logics based reasoners and ontology management sys-
tems.
In order to allow for better reusing context information in different applications, the
model also offers the possibility to define a feature hierarchy via feature inheritance,
which directly corresponds to property hierarchies in RDF(S). This adds a basic infer-
encing capability to the model: if an applications requests the value(s) for a specific
feature, the values of sub-features can be also returned.
Feature values are tuples (U, f, v, α), where U is the user, f is the feature, v is the
value and α is the confidence level that the feature f currently has the value v for the
user U .
An example would be (Andreas, performs-task, literature-search, 0.8), which en-
codes that the user Andreas currently performs the tasks of literature-search with the
probability of 0.8, which could have been determined from monitoring his usage of a
web browser and the visited sites. literature-search could a reference to a concept in an
ontology that allows for generalizing this concept to search.
The operations supported at this layer are
– queries for specific context feature values of a user and for users having certain
feature values
– update operations that can set or delete feature values for a specific user
2.3 Internal Layer
In contrast to the logical layer, the internal layer does not only have to provide the
current view on the user context, but it also needs to store the history so that temporal
concepts need to be considered. The internal layer primarily consists of a fact base
(called context information base) with context facts as its entries:
A context fact is a tupel (U, v, t, valid, a) where
– U is a user
– f is context feature
– v is a value
– valid is the validity interval for the value
– t is the point in time at which the factum was added to the fact base.
– α is the probability that at point of time t the feature f has the value v for user U .
As additional schema-level information, the internal layer has aging functions at-
tached to each context feature, which allow for describing how the confidence in a cer-
tain value decreases over time. An aging function basically is a function f : T IM E →
31
[0, 1], which is multiplied with the initial confidence value in order to obtain the current
confidence value. These aging functions can be assigned heuristically or – preferably –
based on empirical results.
Taking the example from above, the context information base could contain (An-
dreas, performs-task, literature-search, [2005-04-15 10:00, ∞), 2005-04-15 10:00, 0.8),
and an entry (Andreas, performs-task, examine-students, [2005-04-14 14:00, ∞), 2005-
04-15 13:00, 0.9).
The operation on this layer are much more powerful as they can additionally exploit
the temporal perspective.
2.4 Mapping the Internal Layer to the Logical Layer
In order to map from the internal layer to the logical layer, the following issues need to
be taken care of:
– Restrict to a specific point in time. The set of context facts is restricted to those
context facts for which the validity interval contains the requested instant of time.
– Apply aging functions. With the help of aging functions, the current confidence
value needs to be calculated.
– Infer additional information. As the context facts only represent those values that
were explicitly added to the fact base, we provide also a feature hierarchy on the
logical layer, for which additional feature values need to be inferred.
– Resolve inconsistencies. Inconsistency occurs in our model if there are multiple
values for a feature for which the cardinality constraints enforce a single value.
There can be different strategies to resolve these inconsistencies. The most obvious
is to take the value with the highest confidence, but usually the strategy also needs
to take into account that facts can be reinforced by other facts (e.g. two independent
methods determine the same feature value within a limited time window).
If we apply this procedure to the example, it is clear that the restriction to a specific
instant in time (e.g. 2005-04-14 11:00) still provides two possible tasks. After apply-
ing the aging function, let’s suppose that the literature-search has confidence 0.7 and
examine-students has confidence 0.1. This would lead to the resolution strategy to take
the literature-search as the current feature value, because we have specified that the
performs-task feature is only single-valued.
2.5 External Layer and Mapping from the Logical Layer
The external layer is intended to be interface for application, providing an application-
specific view. On the one side, this consists of an application-specific context schema,
on the other side the application can specify a certain quality-level, which depends
on the usage strategy. This quality level is expressed as a minimum confidence level
for supplied user context information. Where user context information is only used as
a rough indication about the user, the confidence does not matter that much, but for
applications that involve legally binding transactions, certainty about values is crucial.
In order to perform the mapping from the logical layer, the following two issues
need to be taken care of:
32
– Apply quality criteria. This involves the filtering of the available feature values
according to the supplied minimum confidence.
– Perform a mapping. In this step, the global context schema used on the logical
layer is translated into an application-specific schema. In case of simple projections
and renamings, this can be done within the user context management system, but
for more powerful mapping features, external mapping services are the method of
choice (in spirit of [14]).
3 Subcontext Switching Support
3.1 The Concept of Subcontexts
The layered context model introduced so far supports the controlled forgetting of out-
dated context information and allows for representing different levels of certainty. How-
ever, it does not help with the problem of slow adaptation to a changed context. This
is due to the phenomenon that there are often dependencies between different features,
i.e. groups of values often change together. A typical example are different roles (e.g.
private role or business role). If a user currently has the private role, a wide range of
context information can be different, e.g. his payment preferences, contact information
etc. In order to cope with these dependencies, the concept of subcontexts is introduced.
Subcontexts are basically groups of feature values that change together and have the
following characteristics:
– Subcontexts can be nested.
– Subcontexts conform to a schema that defines (1) available features and (2) nesting
relationships.
– For each subcontext schema, there is at most one sub context active at a certain
instant of time. The others are present as inactive, ”parallel” sub contexts yielding
the same aspects about the user.
An example for a subcontext structure is given in figure 2. Here you have a user with
location-dependent, role and project-dependent information. Currently the user ”John
Smith” is at his office and thus has broadband network access, but no loud-speakers
(which could influence whether the system can deliver video or audio material). The
system also knows the characteristics of other locations, but those are represented as
currently inactive sub contexts. There is also role-specific information and within each
role project-specific information. In the case of corporate e-learning, this information
could in its majority be provided manually by a learning coordinator or human resources
department.
In our three layer model, the concept of subcontexts is located at the internal layer.
3.2 Heuristic Strategies for Subcontext Management
Although it is possible and in many cases also reasonable to have the user manually
indicate her current context, this limits the concept of subcontexts to a relatively coarse
granularity and less frequent context switching. Ongoing research therefore tries to
identify heuristic strategies how to automate the handling. The most crucial issues are:
33
name: John Smith
birthdate: 1974-02-15
Location Office Location Home Location Travelling
bandwidth: 2MBit/s bandwidth: 768 kBit/s bandwidth: 14 kBit/s
loud-speakers: no loud-speakers: yes loud-speakers: no
Role A Role B
Project A Project B
Inactive subcontext information
Subcontext belonging to the current context
Fig. 2. Sample sub context structure
– Detection of subcontext changes. The most crucial part of the research is how to
detect context changes, or to be more precise: how to distinguish context evolution
from context switching.
– Automatic construction of subcontexts. Although being quite practical for closed
environment like intranet e-learning solutions, the manual specification of schemas
for subcontexts limits the scope of a generic user context management service.
Therefore automatic methods for sub context detection are investigated. Promising
approaches here are Data Mining approaches, but they have to be adapted to (1) the
scarce amount of available data and (2) uncertainty aspects.
Currently, simple strategies have been implemented. For the detection of sub context
changes, the strategy works with pivot features, which serve as semantic keys for sub
contexts. If these features change, the rest of the feature value is also assumed to change.
For the construction of subcontexts, a method based on functional dependencies is used
(which is borrowed from schema normalization in relational database schemas. Further
strategies are under research.
4 Implementation
A context management system based on the model presented in this paper was im-
plemented in the project Learning in Process, which aimed at – among other things
– supporting a new type of learning process for workplace learning: context-steered
learning[15]. Instead of having human resource development experts assigning courses
to employees or leaving it to the employees to actively search for learning resources
34
satisfying their knowledge need, the LIP system continuously monitors the employee’s
working activity (i.e. her context) and deduces from it (with the help of domain knowl-
edge) the possible knowledge gap. Based on this gap, the system can recommend rele-
vant learning resources, which can (but need not) initiate learning processes. The con-
text schema used for that purpose incorporates the following:
– Personal characteristics: competencies, goals, learning preferences like interac-
tivity level and semantic density
– Organizational aspects: role, organizational unit, business process (step), task
– Technical aspects: user agent, available bandwidth, available multimedia equip-
ment
For more details on the context schema and how it was constructed see [4].
Learner Assistant
context-relevant
UI events recommendations
Aggregator context Matching
changes Service
context updates
External Layer
Administration
Logical Layer
strategies for
inconsistency handling
Internal Layer Reasoning
strategies for
sub context management Service
KAON
PostgreSQL
User Context Management Service
Fig. 3. Overview of the prototypical implementation in LIP
35
The basis for the service matching the current work situation and relevant learn-
ing resources is a user context management service that provides a view on the current
context of the employee (see figure 2). In order to be able to easily implement feature
inheritance and to smoothly work with moderately expressive ontologies used for en-
coding the domain knowledge, the implementation of the internal layer was based on
the ontology management system KAON[16]. KAON supports a variation of the RDFS
data model and is implemented ontop of relational databases that support (at least some
variation of) SQL-99. The operations of the internal layer were exposed both via spe-
cialized methods and via a descriptive query language (based on the KAON query lan-
guage). For the project prototype, however, only the specialized methods were used by
external applications.
Queries to the logical layer are also expressed in the KAON query language –
mainly because it allows for smoother interoperability with the rest of the system. The
user context features are mapped to virtual properties of the RDFS data model. The
queries are rewritten to queries to the lower layer. Inconsistency resolution is done by
postprocessing the results, but currently there is only a simple strategy in place (as de-
scribed above). In the prototype, the external layer was very thin and did not require
mapping services so far. As a consequence, there was only a confidence cut-off.
As context sources, on the one side there was a event-triggered update of more sta-
ble elements like name, role or organizational units. On the other side (Administration
in figure 2), there were desktop learning assistants monitoring the interactions of the
employee with her applications. For the two pilot installations, the following applica-
tions were observed: Internet Explorer, Microsoft Office (Excel, Word, Powerpoint),
and Microsoft Visual Studio. The user interface event were aggregated and translated
into context feature value changes.
In order to enable context-triggered actions, the service also supports notifications
about context changes. These notifications were used by the learner assistant to deter-
mine when to invoke the matching service that retrieves relevant learning resources and
compiles them into a personalized learning program based on the context of the user
and background domain knowledge (for more details see [15] and [4]).
The simple strategies for inconsistency handling and subcontext switching were
sufficient for the first prototypes. However, it is expected that with more context sources
connected more sophisticated strategies will be required. The prototype provides a good
basis for further experiments on this.
5 Related Work
There are plenty of models for dealing with user context information, both from the
traditional community of user modeling and the recently emerged communities for
context-awareness. A good overview of recent context modeling approaches gives [6].
In general, it can be stated that the data management problem is a neglected area of
research.
The consideration of the imperfection and dynamics of user context information is
also a relatively neglected area of research, especially for the case of high-level context
information. [17] investigate quality criteria for context information complementing
36
quality of service concepts. They define the following criteria: precision, confidence,
trust level (for context sources), granularity and up-to-dateness. [18] introduce meta at-
tributes like precision, certainty, last update and update rate. Only [19] has investigated
the role of imperfection in a more systematic way and identified the following types
of imperfection: unknown values, contradictory values, imprecise values, and incorrect
values. Feature values are further classified according to their source and persistence
into sensed, static, profiled and derived. The causes of imperfection are analyzed along
this classification.
6 Conclusions and Outlook
The proposed solution integrates the aspects of imperfection and dynamics into the
context model and structures provides a layered structure similar to traditional data
management applications. This allows for scalable solutions and appropriate decou-
pling of different management aspects. In addition to that it offers different interfaces to
context-aware applications at different levels of complexity. Dedicated context sources
or sophisticated context-aware services will access the context management infrastruc-
ture primarily on the internal layer, whereas applications that extend their traditional
functionality with some context-aware features and provide the user only with limited
interaction possibilities with the context information will primarily access the external
layer. The logical layer is for added-value services that do not want to deal with the
temporal perspective or inconsistent data.
Future research will explore the heuristic strategies used for inconsistency reso-
lution and for subcontext switching via simulations. This will lead to insights which
strategies are most suitable for specific domains characteristics.
References
1. Dey, A.K.: Understanding and using context. Personal and Ubiqutous Computing Journal 1
(2001) 4–7
2. Winograd, T.: Architectures for context. Human-Computer Interaction 16 (2001)
3. Schmidt, A., Winterhalter, C.: User context aware delivery of e-learning material: Approach
and architecture. Journal of Universal Computer Science (JUCS) 10 (2004) 28–36
4. Schmidt, A.: Bridging the gap between knowledge management and e-learning with context-
aware corporate learning solutions. In Althoff, K.D., Dengel, A., Bergmann, R., Nick, M.,
Roth-Berghofer, T., eds.: Post Conference Proceedings of the 3rd Conference on Professional
Knowledge Management - Experiences and Visions (WM05), Springer (2005)
5. Elst, L., Abecker, A., Maus, H.: Exploiting user and process context for knowledge man-
agement systems. In: Workshop on User Modelling for Context-Aware Applications at UM
2001. (2001)
6. Strang, T., Linnhoff-Popien, C.: A context modeling survey. In: Workshop on Advanced
Context Modelling, Reasoning and Management, UbiComp 2004 - The Sixth International
Conference on Ubiquitous Computing, Nottingham/England. (2004)
7. Chen, H., Finin, T., Anupam, J.: Semantic web in the context broker architecture. In: PerCom
2004. (2004)
37
8. Schmidt, A.: Management of dynamic and imperfect user context information. In Meersman,
R., Tari, Z., Corsaro, A., eds.: OTM Workshops. Volume 3292 of Lecture Notes in Computer
Science., Springer (2004) 779–786
9. Wang, X., Gu, T., Zhang, D., Pung, H.: Ontology based context modeling and reasoning
using owl. In: IEEE International Conference on Pervasive Computing and Communication
(PerCom’04), Orlando, Florida (2004)
10. Strang, T., Linnhoff-Popien, C., Frank, K.: CoOL: A Context Ontology Language to enable
Contextual Interoperability. In Stefani, J.B., Dameure, I., Hagimont, D., eds.: LNCS 2893:
Proceedings of 4th IFIP WG 6.1 International Conference on Distributed Applications and
Interoperable Systems (DAIS2003). Volume 2893 of Lecture Notes in Computer Science
(LNCS)., Paris/France, Springer Verlag (2003) 236–247
11. Nebel, I., Smith, B., Paschke, R.: A user profiling component with the aid of user ontologies.
In: Workshop Learning - Teaching - Knowledge - Adaptivity (LLWA 03), Karlsruhe (2003)
12. Heckmann, D.: A specialized representation for ubiquitous computing and user modeling.
In: First Workshop on User Modeling for Ubiquitous Computing, UM 2003. (2003)
13. Dolog, P., Nejdl, W.: Challenges and benefits of the semantic web for user modelling. In:
AH2003 Workshop at WWW2003. (2003)
14. Kazakos, W., Nagypal, G., Schmidt, A., Tomczyk, P.: Xi3 - towards an integration web.
In: 12th Workshop on Information Technology and Systems (WITS ’02), Barcelona, Spain
(2002)
15. Schmidt, A.: Context-steered learning: The learning in process approach. In: IEEE Inter-
national Conference on Advanced Learning Technologies (ICALT ’04), Joensuu, Finland,
IEEE Computer Society (2004) 684–686
16. Maedche, A., Motik, B., Stojanovic, L., Studer, R., Volz., R.: An infrastructure for searching,
reusing and evolving distributed ontologies. In: Proceedings of WWW 2003, Budapest,
Hungary. (2003)
17. Buchholz, T., Küpper, A., Schiffers, M.: Quality of context: What it is and why we need
it. In: 10th International Workshop of the HP OpenView University Association (HPOVUA
2003), Geneva, Switzerland. (2003)
18. Judd, G., Steenkiste, P.: Providing contextual information to ubiquitous computing applica-
tions. In: 1st IEEE Conference on Pervasive Computing and Communication (PerCom 03),
Fort Worth, 133-142 (2003)
19. Henricksen, K., Indulska, J.: A software engineering framework for context-aware pervasive
computing. In: PerCom, IEEE Computer Society (2004) 77–86
38