Current research in context-awareness is biased toward low-level context information. High-level context information, however, poses several challenges to context management systems, which can be traced back to the asynchronicity of context acquisition and use and the inherent dynamics and imperfection 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.1
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
relevance 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”
[
The upsurge of interest in context-awareness has mainly occurred in the area of
low-level context information as defined by [
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
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 [
Challenges for High-Level User Context Information Management
However, this idea faces several challenges, which cannot be adequately met by existing
information management solutions [
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 highlevel context information to the respective management infrastructure are briefly discussed. 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 dynamic nature of user context information. In section 4, there will be an overview of the prototypical implementation in the project ”Learning in Process”. 1.4
Specific Requirements for a Suitable Context Model
The context information architecture proposed in this paper focuses on the so far
neglected issue of high-level context information as defined by [
Current approaches to context modelling like [
The second issue is directly related to the architecture of user context information management systems. For traditional database management systems, it has proven effective 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 guaranteed. – 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.
Context Feature Values
application-specific context schemas View restricting to certain features and quality criteria
global context schema View restricting to user and time instant
Context facts
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. 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 cardinality 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 referencing elements from an ontology. That way, also inferencing on the value level is possible by reusing description logics based reasoners and ontology management systems.
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 inferencing 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 encodes 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
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
attached to each context feature, which allow for describing how the confidence in a
certain value decreases over time. An aging function basically is a function f : T IM E →
[
Taking the example from above, the context information base could contain (Andreas, 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, ∞), 200504-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 applying 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 applicationspecific 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:
– 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 [
The layered context model introduced so far supports the controlled forgetting of outdated context information and allows for representing different levels of certainty. However, 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: Location Office bandwidth: 2MBit/s loud-speakers: no Role A Project A
Project B
Location Home bandwidth: 768 kBit/s loud-speakers: yes Role B
Location Travelling bandwidth: 14 kBit/s loud-speakers: no Inactive subcontext information Subcontext belonging to the current context – 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.
A context management system based on the model presented in this paper was
implemented 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[
UI events
Aggregator context updates
Learner Assistant context changes context-relevant recommendations Matching Service Administration
External Layer
Logical Layer
strategies for inconsistency handling Internal Layer
strategies for sub context management
KAON
PostgreSQL
Reasoning
Service
User Context Management Service Fig. 3. Overview of the prototypical implementation in LIP
The basis for the service matching the current work situation and relevant
learning 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
encoding the domain knowledge, the implementation of the internal layer was based on
the ontology management system KAON[
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 described 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 stable 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 applications 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
determine 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 [
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
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 [
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. [
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 decoupling 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 infrastructure 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 resolution and for subcontext switching via simulations. This will lead to insights which strategies are most suitable for specific domains characteristics.