Adaptive Hypermedia Systems (AHS) have long been mainly represented by domain- or application-specific systems. Few reference models exist and they provide only a brief overview of how to describe and organize the 'adaptation process' in a generic way. In this paper we consider the process aspects of AHS from the very first classical 'user modelling-adaptation' loop to a generic detailed flowchart of the adaptation in AHS. We introduce a Generic Adaptation Process and by aligning it with a layered (data-oriented) AHS architecture we show that it can serve as the process part of a new reference model for AHS.
Throughout the development of the Hypermedia and later Adaptive Hypermedia
(AH) research field people have been trying to create ‘reference’ models of these
categories of systems. Major reference models have been favouring a layered
architecture, starting with the Dexter Hypertext Model [
In the paper we examine the issue of aligning the adaptation process, based
on an extensive list of AH methods and techniques [
Adaptation Process Modelling
Hereafter by Generic Adaptation Process we mean the interaction in AHS which
starts with the goal statement, exploits features of the user and domain models in
different contexts and adapts various aspects of the information and presentation
to the user. Figure 1 shows this user modeling / adaptation loop as originally
presented in [
Considering a generic adaptive system one may think not only about defining a framework or reference (data) model but also about what the adaptation process within the system looks like, beyond what Fig. 1 shows. Fig. 2 shows some extensions of the classical loop, taking into account that selection of user information or reasoning about the user model to obtain answers about the user is an essential part of the adaptation process (Fig. 2a) and that either the user or an administrator (or both) need the ability to scrutinize the user model (Fig. 2b). S y s t e m
copom taadpA en ito tn n
A d a p itt a o n
A ilp Provides p c a it on Collects
S y s t e m
“ A d m ii n s ProvidesEdits ttrr”oa
s e r
(a) User model inference - adapta- (b) Collaborative user model editing tion loop (User and Administrator involved)
These updated ‘user-modelling - adaptation’ loops give a more extensive
overview of some aspects of the adaptation, however in [
When? Context
To What? User features
How?
Methods,
Conceptual level
Where? Application areas
Why? Adaptation goals
What?
Domain Model Adaptive Techniques classification Adaptation process
How?
Techniques, Implementation level
system
Although coupling the AH methods classification with the ‘adaptation process’ had a different purpose from what is shown in the classical (and later) loops of ‘user modelling - adaptation’ - our goal is to show the diversity of the adaptation process representation and the possibility of aligning not only the ‘user-adaptation’ loop into the adaptation process but the adaptation methods and techniques as well. Adaptation can be defined by posing and answering six major questions: – Why do we need adaptation? (Why? ) – What can we adapt? (What? ) – What can we adapt to? (To What? ) – When can we apply adaptation? (When? ) – Where can we apply adaptation? (Where? ) – How do we adapt? (How? )
This type of classification has been initially introduced in [
Fig. 3 considers the order in which the adaptation questions should be asked
(and answered), thus leading to a first informal definition of the adaptation
process. The classification of AH methods and techniques is outlined by the solid
lines representing the typical dimensions for the analysis of adaptive systems [
Taking into account user needs and system components (anticipating both
core and optionally available components) we would like to present the process
which explains the transitions, states, sequences and flows in a generic AHS. First
we revisit a few such systems. Then, based on the research and summarization
done in [
Considering the adaptation process in other systems we mention a few examples of how the authors tried to catch an idea of defining the adaptation processes (both implicitly or explicitly) in their systems and matching processes with the layered structure of their systems.
n o it a c li p p A
Event interface Question
Interface Application layer
Interface layer
Providing
Data Requiring
Data Integration layer
Push Reasoning
Pull Reasoning Reasoning layer
User model Domain models Rules Storage layer
In the GOMAWE system [
adaptation completed
Adjustments
System Adaptation User Model
Update observation completed
user interactivity Presentation user action / time-out non-adaptive
reaction
User Observation
Interaction adaptive reaction
The Munich model defined by Koch in [
To some extent most of the adaptation ‘loops’ fall under this classification. Most of these interactions are continuous and recursive when the user continues using the system and explores the knowledge base in depth. We should also mention that here we don’t consider any concurrent loops that may happen and influence each other in every aspect.
Adaptation Process Flowcharts In the following section we summarise the procedural knowledge of the data/control and other flows in AHS and come up with the generic representation of AHS processes.
Hereafter we present the adaptation process flowcharts, which generalize the
functionality of the AHS. In fact these flowcharts follow the system properties
summarization presented in [
We distinguish the following flowcharts: – abstract adaptive process flowchart (Fig. 6); – goal acquisition and adaptation (Fig. 7); – adaptation functionality (Fig. 8); – test-feedback functionality.
Each flowchart represents a certain aspect of the adaptation process, annotated to give more insight in the description of some blocks. On the right side of each chart we link parts of the process to the layers of the GAF model. The communication between the layers is illustrated in Fig. 9. We also mark with numbers the exact correspondence of Fig. 9 calls and transitions with the outlined blocks on the flowcharts (Figs. 7-8) in order to show the conformity of the sequence and flowchart approaches.
In the ‘Goal acquisition and adaptation flowchart’ (Fig. 7) we start with the group analysis, thus assigning the user to a group or acquiring group properties in order to take them into account while choosing the adaptation goals. Here we also make assumptions that the user can belong to only one group and may not switch to another group within a session. The user may have his/her own goal or be advised by the system to (also) use the group goal. In any case goal suitability is checked to determine whether the user can follow it. All suitable goals are elaborated in a sequence of concepts or the most appropriate ‘project’ (defined set of concepts to study) is chosen.
The ‘Adaptation functionality flowchart’ (Fig. 8) presents the main
Adaptation Engine (AE) functionality in a sequence of concept-content adaptation
steps for a particular user. In general we analyse conditions for a particular step
and execute adaptation rules which apply adaptation techniques and perform
presentation, content and navigation adaptation. After that UM attributes are
updated accordingly and the user proceeds with the next concept either on a
‘one-per-click’ or project-organized basis. This figure looks very similar to what
was done the in IMMPS model [
‘Test-feedback functionality’ goes in the end. Here if such a feedback is
required the user continues either with the external evaluation or internal
assessment which could be the part of a project or a separate questionary or test
instance. If this test is failed, user goals might be refined and he/she could be
requested start all over again.
4
‘Rotating’ the Layers of AHS: Adaptation Process and
the Layered Model
The conceptual structure of GAF [
Now, considering the generalized adaptation process flow- charts presented
in (Figs. 7-8) and the layered nature of AHS [
Thus we decided to rotate the anticipated layered structure representation by 90 degrees counter-clockwise and match it with the adaptation process flowchart. Fig. 9 shows such an abstraction of a generic adaptation process in terms of the system layers. (It has been rotated once more to fit on the page and be readable.)
We have marked the communication arrows with numbers to set up a correspondence with the flowcharts, where respective blocks are outlined and marked with the same numbers. This is done to show the coherence of the sequence and flowcharts. We should also note that not every connection in the adaptation proin case user doesn't have any goal and belongs to a certain group, goal can be restricted to a choice of group goals from a proposed set
yes goal proposal can be done in the following ways: either let user to choose a goal and then generate path to achieve it or analyse UM behaviour first and restrict number of goal choices narrowing goal
proposals a choice of system predefined goals; a set of available concepts is narrowed according to user suitability
function (and passed to goal proposition module)
yes assign user to a selected group for this adaptation process sequence / or create a new group consisting of this user
no (all available goals
are proposed) - goal is proposed/
recommended by the system/group
(all/narrowed) - align with pers. pref.
(if any) user is notified that his goal according to
the current knowledge state is not reachable or may mislead, so user is proposed to follow
the system generated or one of the predefined goals single concept
goal next concept (link) to follow
suitable goal selection?
end Fig. 7. Goal acquisition and adaptation flowchart
begin user state is analysed, UM retrieved, current user knowledge extracted and user domain indep. properties affecting goal choice does user belong to a group? (1) no use group goal?
no user has a goal?
yes proceed with a single user choose/define goal (goal/project repository, links represented on a current page, etc.)
begin (3) saving goal to follow in UM preparing instance of UM to work with and current goal (acquiring full user profile) acquiring next concept (void in case one-at-a-step
adaptation) + associated events acquiring corresponding content/frame/info unit processing information unit (content/links from frames/
pages/ etc.) presentation generation showing info/content to the
user update user knowledge/
properties store intermediate user
progress updating user goal progress are all concepts in a sequence/
project passed? proceed with concept/concept set (project) completion yes end going through all the concepts required to
fulfil project/ sequence, other multiple goals if any no (5)
Fig. 8. Adaptation functionality flowchart goal is interpreted into system internal terms like a new concept or a set of concepts to learn, a concept trail to follow and etc. current user goal is pre-stored
in UM Application
Model concept-content-adaptation interaction cess sequence exists in the above-mentioned flowcharts due to the more extensive description of the GAF process sequence chart. The marked connections are: 1. User goals are defined. In case the user doesn’t define any goal it can be proposed by the system or a group goal is used; 2. User goals are aligned with DM, considering the conceptual structure of the domain. According to the selected goal a suitable set of concepts to follow is chosen; 3. Adaptation is initiated and control is passed to the Application Model (AM); 4. Operations of UM properties such as acquisition and update are performed here (corresponds to a few places on the flowchart); 5. Operations mainly concerned working with the concepts from DM; 6. Appropriate adaptation methods and techniques are invoked; 7. Retrieved content is passed to the Presentation model to be rendered/generated and presented to the user; 8. Corresponding content (for concerned concepts) is retrieved from the Resource model and handed over back to AM; 9. Group related operations (assigning users, retrieving group properties, defining new groups, etc.). 5
Conclusions and Future Work
In this paper we defined and elaborated various aspects of the Generic
Adaptation Process, introduced its model, flowchart and sequence chart. To comply
with the layered model we anticipate that the aforementioned process structure
will influence the layered composition of the AHS in such a way that the process
defined by the system engineer will partially drive the order of the layers of such
AHS and define important inter-layer transitions. At the same time we anticipate
that the defined processes together with the reference model (e.g. emerging GAF
or well known AHAM) may serve as a foundation for the system design, defining
not only the system components but the system ‘functionality flow’ as well, or
even deviate into a separate branch of so-called ‘process-driven’ architectures
in the AH field. Moreover the formalized process driven approach gives more
insight on AH development methods and unifies this development approach and
system organization as it was first mentioned in [
We have started elaboration of the generic layered structure of AHS in [
In the future we plan to extend the adaptation process sequence with more details, elaborate the process description, particularly inter-layer interaction, sustaining the generic approach, at the same time emphasizing the interoperability p co nre y ilt a e ing ito u g s /u ta Presentation Model
Higher Order Adaptation Adaptation Model
Application Model Context Model
Usage Context ) 4 (
User Context MU vo tsa Fig. 9. Conceptual Generic Adaptation Process sequence chart Group Model ) 9 ( of a new AH developments (Ontologies, Open Corpus, Higher-Order Adaptation etc.) and the conventional AH approaches. This may lead to describing interoperable and alternative interaction in the system thus representing a generic view of an AH framework which includes all possible variations of adaptation functionality and techniques.
Acknowledgements This work has been supported by the NWO project GAF: Generic Adaptation Framework.