AWES

kettlecatelbowcornerAI and Robotics

Nov 7, 2013 (3 years and 7 months ago)

54 views


1

Forming and maintaining an accurate “image” of the user within adaptive educational
hypermedia systems


D. Vogiatzis
1

, A. Tzanavari, S. Retalis, A. Papasalouros, P. Avgeriou



Dimitrios Vogiatzis


Department of Computer Science

University of Cyprus

75 Ka
llipoleos St. P.O Box 20537

CY
-
1678, Nicosia Cyprus

Tel:+357
-
22892749

Fax¨+357 22892707

Email: dimitrv@cs.ucy.ac.cy

Aimilia Tzanavari


Department of Computer Science

University of Cyprus

75 Kallipoleos St. P.O Box 20537

CY
-
1678, Nicosia Cyprus

Tel:+357
-
228
92747

Fax¨+357 22892707

Email: aimilia@cs.ucy.ac.cy



Andreas Papasalouros


National Technical University of Athens

Department of Electrical and Computer
Engineering

Software Engineering Laboratory

15780 Zografou, Athens, Greece

Tel: ++301 7722487, Fax: +
+301 7722519

Email: andpapas@softlab.ntua.gr


Symeon Retalis


Department of Computer Science

University of Cyprus

75 Kallipoleos St., P.O. Box 20537

CY
-
1678 Nicosia, Cyprus

Tel: +357
-
22
892246, Fax: +357
-
2
2
-
339062

Email: retal@ucy.ac.cy



Abstract


Adapti
ve
hypermedia

Educational Systems represent an emerging technology that provides a
unique advantage over traditional Web
-
based Educational Systems; that is the ability to adapt to the
user's needs, goals, preferences etc. Adaptive
hypermedia

Educational Sy
stems
(AHES)
are
i
n
creasingly becoming part of the mainstream education, yet there does not exist a disciplined way
of designing them
-

most of the development is
ad
-
hoc
. This paper aims to fill this void, which is
the absence of disciplined design, by rec
ording the expertise of existing Adaptive Web
-
based
Educational Systems in the form of design patterns. We present a categorization of the patterns
accor
d
ing to an established paradigm in Adaptive Hypermedia, we examine the patterns in one of
these categor
ies and provide exemplary pattern
s for user modeling
.



1.
Introduction


An Adaptive
hypermedia Educational System (AH
ES)

is a dynamic web
-
based application, which
provides a tailored learning environment to its users, by adapting both the presentation and

the
navigation through the co
n
tent. Such a system is comprised of learning resources, as well as a set of
tools that facilitate the process of studying, such as exams/questionnaires, glossaries,
communication tools, etc. The learning content is dynamicall
y generated based on some
pedagogical rules that combine the (d
o
main) model of the content with the model of the user.
AHES

are currently a ‘hot’ topic of research in the broader field of adaptive hypermedia
applications and several
AHES

systems have been
built du
r
ing the past years [Brusilovsky 2001].




1

Corresponding author


2


Several educational institutions are nowadays designing and developing their own
AHES

due to the
fact that
AHES

leverage the shortcomings of non
-
adaptive web
-
based educational systems, also
known as Learning

Ma
n
agement Systems or Virtual Learning Environments. In contrast to the
latter,
AHES

can provide tailored, one
-
to
-
one tutoring, according to the specific characteristics of
each individual learner rather than serve the same content massively to all the le
arners.
Furthermore, some educ
a
tional or research institutions tend to develop their own
AHES

in order to
implement and test their own learning theories or instructional design methods.

However, the design and implementation of Adaptive Web
-
based Educati
onal Systems (
AHES
) is a
complex, if not overwhelming, task. This is due to the fact that it i
n
volves people from diverse
backgrounds, such as software developers, web application experts, content developers, domain
experts, instructional designers, user m
odeling experts and pedagogues, to name just a few.
Moreover, these systems have presentational, behavioral, pedagogical and architectural aspects that
need to be taken into a
c
count. To make matters worse, most
AHES

are designed and developed
from scratch,

without taking advantage of the experience from previously developed Adaptive
Web
-
based Educational Systems, because the latter’s design is not codified or documented. As a
result, development teams are forced to ‘re
-
invent the wheel’.


Therefore, system
atic and disciplined approaches must be devised in order to overcome the
complexity and assor
t
ment of
AHES

and achieve overall product quality within specific time and
budget limits. One such approach is the use of
design patterns
[Alexander et al. 1977
]
,
so that
these systems are not designed and implemented from scratch, but based on r
e
usable design
experience gained over several years of trial
-
and
-
error attempts. Therefore good design can be made
explicit, and available to the whole community of designer
s, so that it becomes common practice. In
this way, designers of new or existing
AHES
, especially ine
x
perienced designers, can take
advantage of previous d
e
sign expertise and save precious time and resources.


Till now, the most systematic design approach
for
AHES

is the A
HAM
design model

[De Bra et al.
1999]
.
AHAM
is based on the
Dexter Model

reference model for hypermedia systems
. In order to
address the adoption issu
es of an AH system, AHAM proposes
three models
, as shown in
Figure 1:

t
he
Hypertext
Domai
n Model
, the
User Model
and the
Teaching Model
. The
Hypertext
Domain
Model
provides a conceptual view of the AH application defining the concepts and their
relationships that form the hypermedia content as they are considered by the author. The
User
Model

defines users


personal characteristics as well as his/her history of interaction with the
content that is conceptually described by the Domain Model. Thus, the User Model is closely tight
with the previous model.

The
Teaching Model

contains rules that tra
nsform the previous two
models into hypermedia content presented to the user and control the evolution of the user model
during the user’s navigation into the hypermedia content

[Papasalouros & Retalis 200
2
]
.




3


Figure
1

Overview of the
AHES

conceptual Model

according to AHAM


This paper aims to initiate a pattern language
in

the d
o
main of
AHES

for
the user model
component
. The structure of the rest of this paper is as follows: the second section
presents

the
overview conceptual model
of the patterns for the user model component,
where a categorization of
the pattern
s

into
2 main layers

(design oriented and implementation oriented)
. The third section
presents portrays an e
x
emplary pattern
s
. Finally, the f
o
urt
h section wraps up with conclusions and
ideas for future work.


2.
The map of the user model patterns


This section presents an initial set of design patterns
for user model component of the AHES.

The
organization of these patterns can be achieved acc
ording to how they reference each other in the
‘related patterns’ field of their description
.

Figure 2 depicts the relationships between the proposed
AHES

user model design patterns. The semantics of the arrows between the patterns is that the
pattern at
the beginning of the arrow is a prerequisite of the pattern at the end of the arrow. The
diagram also depicts the sequencing of the patterns, i.e. in what order they should be applied.

Figure
3 depicts an expanded version of the patterns for the AWES.


The

user model component plays a pivotal role in the adaptation that takes place as part of an
AHES
. It is responsible for forming and maintaining an accurate “image” of the user, which at the
same time has to be meaningful and useful to the system. This is s
ubsequently used in the
adaptation phase, where primarily content and presentation are tailored to the user’s needs

[Kav
čič
1999]
. The patterns presented here attempt to cover the entire user modelling process

(both at
design and run time)
.

More specifically, the patterns will try to capture the decisions that should be
made for
:


i)

the user model definition

which
shows what
information a user model
should have
.
Information about the user can be regarded as domain

independent and domain

dependent; or divided into knowledge component (user’s knowledge) and interfaces
component (user’s preferences); or as static (constant throug
h the learning process) and
dynamic (changes during the learning process).

ii)

the user model initialisation

addresses the problem of
deriving
the user model
at

the
beginning of the learning process. Most of the times users fill in a
short
questionnaire
with q
uestions that refer to a selection of the element of the user model
and then well

known methods from artificial intelligence and machine learning can be used
for
determining about his/her user model characteristics, in full. Such methods include
Bayesian n
etworks, rule learning, instance

based learning, learning of probabilities,
logic

based, d
ecision

theoretic, heuristic etc.
, as well as other general techniques and
principles (plan recognition),
and
pecifically developed computational, or specifically
Hypertext Domain Model

Conceptual

Model

Navigation

Model

Presentation

Model

Learner Model

Teaching Model


4

dev
eloped qualitative rules and procedures (rules for selecting and evaluating examples,
rules for choosing adaptation type, rules for choosing questions)
[Jameson 1999].

iii)

the user model maintenance

addresses the pro
b
lem of maintaining an accurate user
model
.
Inputs for this part of the user model are gathered directly from user (willingness
to change his/her preferences), through tests and practice (test results, user history of
responses and problem solving behaviour), or user’s actions (browsing behaviour,
n
umber of nodes visited, visited concepts, time spent on page, total session time,
selection of links, searching for further info, queries to the help system). This
information is constantly being collected during the learning process and is also used for
u
pdating the user model.

iv)

the user model representation

that contain
s

definite design decisions for the
implementation of
the user model in
an AWES. These are depict
ed in the lower part of
figure 3
. In particular the user representation is divided into three

patterns,
corresponding to the three patterns of the upper level

of figure 3
. That
is,
there is
description representation
,
initialisation representation

and
maintenance
implementation

that correspond to user model definition, user model initialisation an
d
user model maintenance respectively. In particular the user model representation
solves
the problem of
choosing among the data types that can be used for
representing the
various elements

the user model
(e.g. triggers for knowledge level)
as well as meth
ods
for maintaining the user model. In practice, the elements of user model can be
represented as trees, lists, hash tables, etc. Concerning the methods, a combination of
two or more is frequently applied, especially when different methods are used for
ini
tialising and maintaining the user model. This assures more accurate modelling and
allows better exploitation of gathered information. These methods include Bayesian
methods,
m
achine learning methods (rule learning, learning of probabilities, instance

base
d learning),
l
ogic

based methods (first order predicate calculus), specifically
developed computational procedures (user’s expertise is calculated from their
navigational actions or time spent on documents),

etc
.



This paper will
deal with all the above c
ategories of patterns for the user model component except
from the user model representation. The main reason is that no firm results from evaluation studies
exist, as yet that could help us in deriving design patterns that hold the
distilled knowledge of
implementers.



User Model Component
User Model Definition
User Model Representation
User Model Maintenance
User Model Initialisation


Figure 2. The patterns for user
modelling



5


Figure 3

The expanded pattern language for the AHES

3.
Some

Patterns


6

Pattern Name: User model Definition

Problem

A user model in an AHES is essentially the information the system holds about
the
user and is mainly related to the learning process. This information has to be such that
the system can better adapt to the user’s individual needs. When observing the learner
c潭灵oe爠楮瑥牡c瑩潮Ⱐ獥ve牡氠慤a灴慴楯湳⁣p渠瑡ne 灬慣eⰠ獯Ie映睨楣栠摯hs

ex灬pc楴ly⁡湤⁳潭e⁩ 灬pc楴lyⰠ扡獥搠潮⁴de⁩湴e牡c瑩癥⁥癥湴猬⁴桥⁰ 瑨⁴桡t⁴桥
汥l牮r爠桡猠瑡步測⁴ne⁰ r景f浡湣e⁣潮oe牮楮g⁳ 浥ma牮楮g⁴慳歳Ⱐ 瑣⁛h潢獡′〰ㅝ⸠
䅮⁡摡灴p癥爠a摡灴慢汥⁥摵da瑩潮o氠ly灥牭r摩愠e湲楣桥猠瑨攠a灰汩ca瑩潮o
晵湣瑩潮o汩ty

by maintaining a “representation of the user” (or “user model”) and
灲潶楤楮p⁣畳瑯u楺a瑩潮散桡湩獭猠瑯潤楦y⁡灰汩ca瑩潮⁦oa瑵牥猠楮s牥s灯湳p⁴漠
畳u爠浯摥氠異摡瑥献sc潲oa摡灴p癥⁥摵ca瑩潮o氠lype牭r摩愬⁵獥爠浯摥氠異la瑥猠tre
a畴潭a瑩ca汬y 来湥ra瑥搠by

the system (by monitoring and interpreting the user’s
楮ie牡c瑩潮猩㬠o潲oa摡灴慢汥⁨ype牭r摩愬⁵de爠浯re氠異摡瑥猠sre⁵湤 爠瑨e 畳u爠
c潮瑲潬⸠周o⁡da灴p癩vyLa摡灴慢楬pty⁦ e摢dc欠k潵o搠扥⁲ 污瑥搠瑯⁴桥

orga湩z
a瑩潮o氠
a湤⁰ne獥湴a瑩潮o氠l獳略猠潦

瑨攠
汥lr
湩ng⁲e獯畲ses

⡰E牭楳r楯渠i漠浯癥⁦潲睡牤Ⱐ
e湣潵牡来浥湴⁴漠牥a搠d灥c楦楣⁳ c瑩潮猬⁵湤o牴rke⁳潭e⁴慳歳Ⱐ 瑣⸩⸠
周e⁩湦潲浡瑩潮m
related to learner’s profile and interaction
扡獥搠d渠睨楣栠瑨攠
䅈䕓

ca渠瑡步
摥c楳i潮猠
景f⁡da灴p癩vy⁡湤⁡摡灴慢楬ptyⰠ獨潵I
搠de⁳瑡湤 牤楳r搮d
p畣栠a
獴慮摡牤楳r瑩潮⁷楬o⁧reatly⁥湨a湣e⁴ e⁰潲瑡扩b楴y映瑨 ⁵獥爠浯摥氠摥lc物灴p潮⁡猠
睥汬⁡猠†s桥⁩湴e牯灥牡扩b楴y映 䡅p⁴桡琠畴 汩ze⁳畣栠摥獣物灴楯湳映汥a牮e牳r

周T 灲潢汥洠楳i睨楣栠ele浥湴猠獨潵s搠扥 c桯獥渠楮i潲摥爠瑯t桡
癥 a 睥汬 de晩湥搠畳ur
浯摥氠瑨慴t c潵汤oa汬潷ot桥 䅈䕓 瑯t 歮潷k睨漠瑨攠畳u爠楳i a湤n瑯t 步e瀠t牡c欠潦o瑨t
汥l牮楮g⁡c瑩癩v楥献i

Analysis

Data about a user serves for deriving contextual structures in an adaptive
environment. There have been attempts to stand
ardize a learner profile such as the
IEEE Personal and Private Information (PAPI) [IEEE PAPI] and the IMS Learner
Information Package (LIP) [IMS LIP]. These standards have been developed from
different points of view. The PAPI standard reflects ideas from
intelligent tutoring
systems where the performance information is considered as the most important
information about a learner. The PAPI standard also stresses the importance of inter
-
personal relationships discussed also in [Vassileva et al, 2002]. On the

other hand the
LIP standard is based on the classical notion of a CV and inter
-
personal relationships
are not considered at all.

PAPI distinguishes
personal
,
relations
,
security
,
preference
,
performance
, and
portfolio

information. The
personal

category co
ntains information about names,
contacts and addresses of a learner.
Relations

serve as a category for relationships of a
specific learner to other persons (e.g. classmate, teacheris, teacherof, instructoris,
instructorof, belongsto, belongswith).
Security

aims to provide slots for credentials
and access rights.
Preference

indicates the types of devices and objects, which the
learner is able to recognize.
Performance

is for storing information about measured
performance of a learner through learning materi
al (i.e. what does a learner know).
Portfolio

is for accessing previous experience of a user.

Similarly the IMS LIP standard contains several categories for data about a user.

The
identification

category represents demographic and biographic data about a
learner. The
goal

category represents learning, career and other objectives of a
learner. The
QCL

category is used for identification of qualifications, certifications,
and licenses from recognized authorities. The
activity

category can contain any

7

learnin
g related activity in any state of completion. The
interest

category can be any
information describing hobbies and recreational activities. The
relationship

category
aims for relationships between core data elements. The
competency

category serves as
slot
for skills, experience and knowledge acquired. The
accessibility

category aims for
general accessibility to learner information by means of language capabilities,
disabilities, eligibility, and learning preferences. The
transcript

category represents
insti
tutionally
-
based summary of academic achievements. The
affiliation

category
represents information records about membership in professional organizations. The
security

key is for setting passwords and keys assigned to a learner.

Although both IEEE PAPI an
d IMS LIP can be used as standalone schemata for
describing the user model, none of them have been explicitly proposed for AHES.
R&D groups are working on a blended approach should put into practice like
proposed model described in [Dolog & Nejdl 2003].

S
olution

IMS LIP provides with richer structures and various aspects. However, accessibility
policies to the data about different learner are not defined. Moreover, the IMS LIP
defines the activity category as a slot for any activity only somehow related to

a
learner. These data can not directly be used for personalization based on level of
knowledge. This can be solved in PAPI by introducing extensions and type of
performance or by considering activity at the portfolio level, because any portfolio
item is t
he result of some activity related to learning. PAPI also has a preference
category, which can be used for storing preferences about devices used. However,
PAPI does not cover the goal category at all, which can be used for recommendation
and filtering tec
hniques. PAPI does not deal with transcript category explicitly as
well. The competence category does not figure explicitly in PAPI as well.

As a result, a complete user model description should generally be comprised of the
following elements:



Demographi
c data
, which are relevant to the particular AHES (e.g. as age,
gender, etc.)



User goals
, which are related to the long term and short term learning goals
related to learning objectives of specific concepts to be learnt (e.g. “to
complete course X”)



User
preferences
with respect to the various dimensions of the learning
opportunity (e.g. the mode of delivery, accessibility requirements, or
assessment)



User knowledge,
which includes the knowledge level about concepts to be
learnt and weaknesses and strength
s on particular areas, sections or points of
the concepts



Usage data
, which include information like which pages were viewed, in what
order, etc.



The
stereotype
that applies to the user, which essentially is the group of users
s/he belongs to based on some

predefined presuppositions in terms of
knowledge level, learning and cognitive styles (e.g. the “Novice User”, the
“Expert User”, the “acoustic user”, the “activist user” stereotypes etc.).


乯瑥⁴桡琠瑨攠 扯癥 獴⁩猠湯s⁲ 獴物捴楮s


楴敲e汹 楮ie湤猠
瑯⁰牯癩摥⁴桥 浯牥
generic
elements with respect to the description of a learner. Designers are
encouraged to include other
specific
elements that would fit their custom AHES.


Related patterns:
User Model Representation, User Model Initiatilisation, User


8

Model Maintenance.


Known uses:
Interbook and BGP
-
MS mainly base the user model on the user
knowledge, usage data, user goals and stereotypes. ALE also maintains information
about usage data, including evaluation results, as well as user knowledge and goa
ls.
ISIS
-
Tutor incorporates user knowledge and usage data and ELM
-
ART II contains
instantiations of units from a knowledge base, which represents the topics the user has
learnt. Information kept in user models used by the I
-
Help system includes:
knowledge,

interests, cognitive style, interaction preferences and user actions. In
addition, the notion of a group (the one the user belongs to), is employed extensively.
The personal learner assistant developed within the ELENA project, is using the
proposed blend
ed approach which is represented with a RDF schema [
Dolog et al.,
2003
].






Pattern Name: User model Initialisation

Problem

Before a user starts interacting with the Adaptive Web based Educational System (AWES), her user
model must be initialised.
It

is the

designer
’s

job is to define the techniques that initialise the user
model. Various aspects need to be taken into account in the initalisation phase. For instance, what is
the minimum amount of information to kick start the system, or what kind of i
nformation and what
amount is the user capable or willing to provide? Naturally, the information stemming from
initialisation should conform to the user model definition specifications.

Analysis

Not all elements of the UM description have to be acquired in

order for the user to start interacting
with the AWES. There are two reasons for that. In the beginning of an interaction session, users do
not like spending a lot of time providing information about them, answering long questionnaires for
instance. Secon
d, it is not necessary to have a complete model of the user; a partial model (with
proper selection of a subset of UM elements) will be acceptable.

There are UM elements that can be acquired directly from the user and data that can be acquired
through the

AWES. For instance, demographic data can only provided by the user. On the other
hand, user knowledge can also be derived by the system

e.g. via the prehistory of user’s learning
activities in other educational environments
.

It is

also

important to initia
lise the user stereotype, because
according to the various groups of users
based on their
stereotypes

the learning tasks will be specified for each group separately
.

There are two options for the UM, it will be identified with certainty, or it will be spe
culated. The
first option is not usually the case in practical AWES systems.

Solution

The AWES designer should
create

fill
-
in forms with
questions that refer to a
desired subset of UM
elements. The desired subset is required to form an initial view of the
user model so as to kick start

9

the AWES. There are a number of ways whereby the desired elements can be derived. Below we
provide a list of plausible choices stemming from real AWES systems that a designer should take
into account:

The desired UM elements

could be obtained explicitly, by presenting to the user a questionnaire,
which she has to fill in. Typically, the user provides data, such as demographic data, user
preferences, and possibly other sorts of data that are compatible with the user model desc
ription
specification.

Another option is to assume values for the desired user model elements from previous training
sessions
/learning activities

of the user. For instance, a user having followed the prerequisites of the
current course is considered to hav
e enough knowledge to follow it.

Yet another option is to assume certain values (with nothing to backup this choice apart from being
plausible) for the desired user model elements, and then to proceed with the interaction, expecting
that the user model wil
l be corrected during the running time of the AWES. This is essentially a
trial and error approach.

Deriving the applicable stereotype requires that a minimum amount of knowledge and specifically a
minimum number of user model definition elements is availa
ble. The derivation of the applicable
stereotype can be performed in a number of ways (the following list is to be considered as
indicative rather than complete):

It can be user driven: For instance the user specifies explicitly that she belongs in the nov
ices’
stereotype.

Inferred by rules: Stereotypes are equipped with triggers, which activate them. Rules tell which UM
elements and with what values can activate a stereotype.

Speculated by rules: If it is the case that there is absolutely no information wh
ich can suggest a
certain stereotype, then the AWES designer should have some rules to allow selection of the
stereotype. For instance, a rule of this kind might be: if user does not specify her knowledge level,
then assume it is average.


Related Patterns
:
UM
Definition
.


Know uses

In Inspire
[Grigoriadou et al. 2001]
the user model is initialised, through a questionnaire filled in by
the user at the beginning, or by explicitly selecting the category she fits in according to some
general characteristics.

E
LM
-
ART II [Weber et al. 1997]
, requests from the users to declare
knowledge units, which are already known to them.

In DCG [Vassileva. 1997]
, the user model,
called student model, is initialized with a preliminary test. ACE

[Specht et al. 2000]

follo
ws
a
somewhat mixed approach
. The user model is initialised by explicit and implicit elicitation from
the users. The former is performed, by the user, which specifies her learning strategies and
stereotype; whereas the latter is done by a dynamically generat
ed test.


Pattern name: user model maintenance


Problem


10

With this pattern we provide a solution to the problem of h
ow
to maintain
an

accurate user model.

We assume that a

user model description and the relevant representation ha
ve been provided as well
as
the user model has been initialised. The user is interacting with the AWES with a

purpose of
learning something, during this process various aspects concerning the user
change;

the general idea
is to capture the
changes so as to maintain the user model.



Analysis

The assumption that the user model will remain the same as when it was acquired originally is in
most cases incorrect. As in tutoring between a human tutor and a stu
dent, where the student
constant
ly demonstrates changes, the user of an AWES also
changes and as a result
his

model has to
reflect this.

During the course of interaction, t
he
re is a leverage of

user’s knowledge develops and
the
usage data builds up. Since the adaptation is to a large extent based on user knowledge and
usage data, change
s should definitely be recorded

and be related to a cause
-
result effect

if the
system is to function effectively.

In fact,
information such as “demographic data”

does not change with a high frequency.
There is
also
, informa
tion like “topics covered” (part
of

user knowledge)
that
changes continuously.

It is
also
important for u
sers to be in control (to a degree acceptable to the AWES) of their model
for several reasons. They need to be able to modify information in their model if they feel that it is
inaccu
rate or incorrect.
Also, b
eing in control builds up their trust in the system.

Solution



The maintenance of an a
ccurate UM can be user driven or

system driven. In the former case
it the user who provides explicit information about changes in his
/her

UM. In
the latter case,
the AWES derives information by closely watching the user.



The AWES designer should define the conditions that govern the maintenance of the user
model. In particular the designer should define the scope of the maintenance changes. The
sco
pe defines the reason for updates. The reason is the
n

quantified in terms of choice of
elements to undergo change. For instance, if the scope says that only a minimal update of
the user knowledge is going to
occur
, then choice of elements is bound to user
knowledge
only. On the other hand a wider choice for the scope would allow updates of user knowledge
and user preferences

(e.g. to read theory and having links to examples)
. Finally, the
frequency of UM description elements updates should be defined.



The U
M maintenance module elicits data to update the UM description. Elicitation
of data
could take

many
forms;

next we provide some characteristic examples. The user is presented
with a form to fill in, whereby the update UM is derived. UM description update c
an
also
be
interactive, when the AWES opens for instance a pop
-
up form requesting the user to
explicitly answer a question. Finally, another option for UM update is through filtering the
stream of data that are produced through user interaction. A typical
example is the browsing
strategy which can be reduced to a small number of primitives, like ringiness, spikiness,
loopiness, pathiness. The raw data constitute the actual path that the user has followed, but
they must be filtered, process,
or
summarized to

be translated to

the predefined number of
primitives.


Related patterns:

User model representation, user model description
, user model initialisation
.



Known users:


In [Grigoriadou et al. 2001] there is an Interaction Monitoring Module, which

collects
information
and updates the learner model accordingly. The system allows the users to intervene, e
xpressing

11

their perspective. A similar approach is followed in [Weber et al. 1997], where the
update of
the
user model
is driven by the
system.
It is also pos
sible to inspect

and
to edit the user model.
Yet
another similar approach is followed in [Vassileva 1997].
Student model changes
are performed
according to student progress. Students can
also explicitly
modify their Pers
onal Traits and
Preferences.

In [Spe
cht et al. 2000] there is a diagnostic module for automated updates of the user
module. Learners can also modify their model anytime.



Conclusions


In this paper we proposed a disciplined approach for designing AHES which takes advandage of the
notion of
design patterns that capture the expertise, know
-
how and tacit knowledge of the
developers of such systems. This approach can be beneficial to inexperienced designers of AWES.
We have introduced a conceptual schema and some patterns for the user modeling c
omponent of the
AHES. The proposed set of patterns structured as a hierarchy will help an AWES designer to have a
broad view of this component, the problems that he/she has to solve as well as their
interdependencies. However, we have not tackled the diffi
cult problem of user model
representation, which means that we have not proposed solid solutions for the developers. As
mentioned in [Borchers 200
1
],
for
the design of interactive systems

(and in our case educational
systems)

instructional designers
,
human

computer interaction specialist, software engineers
,

and
subject

domain experts
, all

in
a project team
, should
express their expertise in the form of a pattern
language.


The future direction of our work is to propose s
oftware design patterns
for AHES whi
ch will be
considered

a useful language for communication among software developers, and a practical
vehicle for introducing less

experienced developers into the

fi
eld.
However, we will continue
towards creating patterns for the design of AHES, since we a
gree with Borchers that there is “
a
good chance to push the concept of participatory

design forward by introducing patterns
”.
This
is
what we are trying with a European funded project called ELEN (
http://www.tisip.n
o/ELEN
). We
are

involv
ing

user

representatives,
instructional designers, elearning specialists
,
domain experts,
in
the design

process to evaluate

prototypes

of elearning systems
, and participate in design

discussions.



Acknowledgement


This work was supp
orted by the “ELEN: A Network of elearning centers” project which is partly
sponsored by the European Commission under Socrates Minerva programme (ref nums: 101421
-
CP
-
1
-
2002
-
1
-
CY
-
MINERVA
-
M).



References


[Alexander et al. 1977] Alexander, C., Ishikawa, S.
, Silverstein, M., Jaco
b
son, M., Fiksdahl
-
King, I.
and Angel, S.
A Pattern La
n
guage

(Oxford University Press, 1977).

[Borchers 2001] Jan Borchers.

A Pattern Approach to Interaction Design, John Wiley & Sons,
ISBN: 0471498289
, 2001

[Brusilovsky 2001] Peter
Brusilovsky. Adaptive hypermedia. User Modeling and User Adapted
Interaction, Ten Year Anniversary Issue (Alfred Kobsa, ed.) 11 (1/2), 87
-
110


12

[De Bra et al.
1999].
Paul De Bra, Geert
-
Jan Houben, and Hongjing Wu. AHAM: A Dexter
-
based
Reference Model for Ada
ptive Hypermedia. Proc. of ACM Hypertext '99, Darmstadt, Germany,
147
-
156, February 1999

[Dolog et al., 2003] Peter Dolog, Rita Gavriloaie, Wolfgang Nejdl, and Jan Brase. Integrating
adaptive hypermedia techniques and open rdf
-
based environments. In
Proc.
of 12th International
World Wide Web Conference, Budapest, Hungary, May 2003.

[Grigoriadou et al. 2001] Grigoriadou, M., Papanikolaou, K., Kornilakis, H. and Magoulas, G.
(2001). INSPIRE: An Intelligent System for Personalized Instruction in a Remote Envir
onment. In:
Proc. of the 3rd Workshop on Adaptive Hypertext and Hypermedia, in User Modeling 2001, LNCS,
Springer


[Dolog & Nejdl 2003] Peter Dolog and Wolfgang Nejdl. Personalisation in Elena: How to cope
with personalisation in distributed eLearning Net
works. In Proceedings of the Conference on
Worldwide Coherent Workforce, Satisfied Users
-

New Services For Scientific Information,
Oldenburg, Germany, September 2003.

[IEEE PAPI 2002] IEEE. IEEE P1484.2/D7, 2000
-
11
-
28. draft standard for learning technolo
gy.
public and private information (papi) for learners (papi learner). Available at:
http://ltsc.ieee.org/wg2/. Accessed on October 25, 2002.

[IMS LIP 2002] IMS. IMS learner information package specification. Available at:
http://www.imsproject.org/profiles/index.cfm
. Accessed on October 25, 2002.

A. Jameson, “What Can the Rest of Us Learn From Research on Adaptive Hypermedia


and Vice

Versa?”, Comments on “Adaptive Hypertext and Hypermedia”, 19
99,
http://w5.cs.uni
-
sb.de/~jameson/ahh/ahh
-
comments.html
.

[Jameson 1999]. A. Jameson, “User

Adaptive Systems: An Integrative Overview”, Tutorial
presented at UM99, 7th International Co
nference on User Modeling, Banff, Canada, 1999

[Kavčič 1999]. Alenka Kavčič, "Adaptive Hypermedia Learning System on the Web",
EUROMEDIA'99, München, Germany, April 1999.

[Kobsa 2001] Alfred Kobsa. Generic user modeling systems. User Modeling and User
-
Adap
ted
Interaction, 11(49):49

63, 2001.

[Papasalouros & Retalis 2002]. Papasalouros, A. & Retalis, S. (2002). Ob
-
AHEM: A UML
-
enabled
model for Adaptive Educational Hypermedia Applications.
Interactive Educational Multimedia
, 4,
76
-
88.

[Specht et al. 2000] Sp
echt, M., Oppermann, R. (2000) ACE: Adaptive Courseware Environment,
Lecture Notes in Computer Science, Vol. 1892

[Vassileva. 1997] Vassileva J. Dynamic Courseware Generation, Communication and Information
Technologies, Vol. 5, Issue 2, pp. 87
-
102


[Vassileva et al, 2002] Julita Vassileva, Gordon McCalla, and Jim Greer. Multi
-
agent multi
-
user
modelling in I
-
Help. User Modeling and User
-
Adapted Interaction, 2002.

[Weber et al. 1997] Weber, G. and Specht M. (1997) User Modeling and Adaptive Navigation

Support in WWW
-
Based Tutoring Systems. In: Proc. of User Modeling 1997.