D42 - DSpace at Open Universiteit

flameluxuriantData Management

Dec 16, 2012 (4 years and 11 months ago)

378 views



Active Learning for Adaptive Internet

ALFANET IST
-
2001
-
33288



Project Deliverable Report

ALFANE
T

Active Learning for Adaptive Internet

IST
-
2001
-
33288


D4.2


Second System Prototype


Workpackage

WP4
-
WP5. LMS System

Task

T41, T42, T43, T44, T51, T52, T53, T54, T55

Date of delivery

Contractual

31
-
7
-
2004

Actual

22
-
9
-
2004

Code name

ALFANET_D42_v1_final


Version
1

draft


fi湡



Type of deliverable

Prototype

Security

(distribution level)

Internal

Contributors

SAGE, UNED, OUNL, ACE
-
CASE

Authors (Partner)

Mª del Mar Rodrigo, Carlos Fuentes, Mª José Carrión (SAGE);

Carmen Barrera, Olga Santos (UNED);

Hubert Vogten,
Slavi Sto
yanov, Rene van Es, John van der Baaren, Frans
Mofers, Harrie
Passier

(OUNL);

Luis Ferreira, Roberto Canada (ACE
-
CASE)

Contact Person

Carmen Barrera (UNED)



Tel: + 34 91 398 8507

Universidad Nacional de Educación a Distancia

Fax: + 34 91 398 66 97

Fran
cos Rodriguez, 77



Email: cbarrera@invi.uned.es

28039 Madrid


p灡in

WP/Task responsible

Software A.G. España

EC Project Officer

Mr. Colin Stewart

Abstract

(for dissemination)

This deliverable describes the functionality included in the second prototy
pe. In
order to situate to the reader, first the system architecture is shortly described.
Based on the identified modules, the second prototype functionality is explained,
in addition to the functions already provided for the first prototype. This
documen
t is intended for internal audience (users and developers).

Keywords List

Second Prototype, ALFANET, e
-
learning


ALFANET Project Coordination at: Software AG España, S.A.


Ronda de la Luna, 4



Tel: +34 91 8079411
-

fax: +34 91 8079447
-

email: car
ana@softwareag.es

Tres Cantos, E
-
28760 Madrid

Page
ii

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

Executive Summary


Introduction

This document describes the second prototype of Alfanet. It outlines the functionality contained in the
prototype and the used architecture.



Description of conclusions/result
s

Second prototype provides administration functions and advanced functionality regarding the courses
creation, publication and interpretation. But the main focus of the second prototype is the whole range of
adaptive capabilities covering different levels
:



Adaptation of learning routes (Authoring Tool, and IMS
-
LD Interpreter)



Adaptation coming from the interactions with the system (Adaptation Module)



Adaptation of Presentation (Presentation Layer)



Adaptive Questionnaires (QTI Interpreter)



Auditing: feedb
ack to the author (Audit)

The
Authoring

Tool provides support for the definition of different learning routes according to specific
conditions (properties) defined by the author. Different learning routes are supported by IMS
-
LD levels B and
C. The
IMS
-
LD
Interpreter

offers different learning routes to the learners according to their profile (mostly
based on users’ learning styles).

The
Adaptation
Module is in charge of providing run
-
time adaptations to cope with the learning needs and
unpredictable situat
ions that come across while interacting with the system. In other words, it identifies
relevant pedagogical situations to enhance learning experience based on previous users’ interactions.

The User Interface adapts to the particular user preferences (perso
nalisation) and context of the course for
each learner. The adaptation is based not only on what the user has explicitly customised, but also what has
been learnt from previous users’ interactions regarding the most efficient way of building the presentati
on
form the learning point of view.
The
Presentation

Layer presents different course related items in the way
that better suite with the learners’ preferences and interests, ordering, enphasising or remarking different
items. Moreover, this module allows a

user to select among a set of exiting presentation layouts, in order to
personalise the user interface.

The
QTI Interpreter

provides questionnaires adapted to the current learner situation (mainly based on
learning styles and the progress throught the cou
rse). As requirement, a bank of items are defined by the
author, characterised with the relevant information in IMS
-
QTI.

Authors are provided with templates for different learning scenarios (the concept learning template provided
by the
MAPM
) that facilit
ates the development of new IMS
-
LD compliant courses.

The goal of
auditing

is to observe the progress of students or a particular student with the aim of providing
sensible reports to authors, who can make improvements to the initial LD accordingly. To ac
hieve this goal
integrated reports on a course are compiled and the results are reported in relation to defined CSF’s (Critical
Success Factor) in order to help the authors to assess their design.

It must be mentioned that every adaptive module has been bu
ilt both on e
-
learning standards and
technological standards which provides a set of components capable of being integrated with other platforms.
For the purpose of adaptation, ALFANET has extended
-
in some cases
-

concrete e
-
learning related
standard. Also

to the same purpose ALFANET components share metadata through standards
interoperability.

To conclude, just remark that the development methodology and, in particular, the evaluation plan, are
intended to support a continuous updating process based on the

feedback from real users at the different
pilot sites.



Deliverable 4.2


Second System P
rototype

Page
iii

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

Table of Contents

1.

INTRODUCTION

________________________________
________________________________
_____________

1

1.1

Situation

________________________________
________________________________
_______________

1

1.2

Purpose

________________________________
________________________________
________________

1

1.3

Overview

________________________________
________________________________
_______________

2

2.

SYSTEM ARCHITECTURE

________________________________
________________________________
_____

3

2.1

Global architecture

________________________________
________________________________
_______

3

2.1.1

Server

________________________________
________________________________
__________

4

2.1.2

Services

________________________________
________________________________
________

4

2.1.3

Data

________________________________
________________________________
____________

4

2.1.4

Authoring Tool

________________________________
________________________________
____

5

2.2

Communication protocols and architecture
________________________________
_____________________

5

3.

SECOND PROTOTYPE INT
ERFACE

________________________________
_____________________________

7

4.

SECOND PROTOTYPE MOD
ULES. SERVER

________________________________
_____________________

10

4.1

Security layer

________________________________
________________________________
__________

10

4.2

Dispatcher

________________________________
________________________________
_____________

11

4.3

Presentation layer

________________________________
________________________________
_______

11

4.4

Tracker

________________________________
________________________________
_______________

12

4.4.1

Tracker engine

________________________________
________________________________
__

12

4.4.2

Events/Notifications

________________________________
_______________________________

13

5.

SECOND PROTOTYPE MOD
ULES. SERVICES

________________________________
___________________

14

5.1

Administration module

________________________________
________________________________
___

14

5.2

Course manager

________________________________
________________________________
________

15

5.3

IMS
-
LD Interpreter

________________________________
________________________________
______

16

5.4

IMS
-
QTI Interpreter

________________________________
________________________________
______

18

5.5

Adaptation Module

________________________________
________________________________
______

20

5.6

MultiAgent Pedagogical Model (MAPM)

________________________________
______________________

23

5.7

Audit module

________________________________
________________________________
___________

23

5.7.1

Situation

________________________________
________________________________
_______

23

5.7.2

Aim of this prototype

________________________________
______________________________

24

5.7.3

Description of functions of the second prototype

________________________________
________

24

5.7.4

The audit system archit
ecture

________________________________
_______________________

25

5.7.5

The course for the second pilot

________________________________
______________________

26

5.8

Interaction module

________________________________
________________________________
______

26

5.9

Content Server

________________________________
________________________________
_________

27

5.10

Common repositories

________________________________
________________________________
____

27

6.

AUTHORING TOOL

________________________________
________________________________
_________

29

7.

SYSTEM REQUIREMENTS

________________________________
________________________________
___

30

7.1

Server requirements

________________________________
________________________________
_____

30

7.1.1

Course Manager and IMS
-
LD Interpreter

________________________________
______________

30

7.1
.2

Learning tool

________________________________
________________________________
____

30

7.1.3

Agents requirements

________________________________
______________________________

30

7.1.4

JAXM Services

________________________________
________________________________
__

31

7.2

Client requirements

________________________________
________________________________
______

31

7.2.1

Editor tool (ACE
-
CASE will identify

the application requirements)

___________________________

31

7.2.2

Questionnaires tool

________________________________
_______________________________

32

7.2.3

Administration tool

________________________________
________________________________

32

7.2.4

Learning tool

________________________________
________________________________
____

32

APPENDIX 1

BIBLIOGRAPHY

________________________________
________________________________
_

33



Figures

Figure 1. Architecture diagram

________________________________
________________________________
_____

3

Figure 2. Communications architecture diagram

________________________________
_______________________

5

Figure 3. Main entrance to Alfanet learning s
ystem

________________________________
_____________________

7

Figure 4. Example of one course in Alfanet learning system

________________________________
______________

8

Figure 5. Other user interface template

________________________________
______________________________

9




Deliverable 4.2


Second System P
rototype

Page
1

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

1.

Introduction

1.1

Situation

ALFANET

concentrates
on the
e
-
l
earning market, an area that takes advantage of the new technologies
related to the Internet, Human Interaction, Learning Design and Machine Learning. More specifically:



ALFANET

will allow individuals to have an interactive and adaptive online learning sup
ported by effective
and efficient educational models, bringing them the opportunity to learn on those matters that are relevant

to perform and improve their work.



ALFANET

will allow service providers or educational centres to provide e
-
learning services a
dapted to
the individual’s background, experience and behaviour.



ALFANET

will allow learning content providers to produce contents based on advanced pedagogical
designs in a way that can be adapted to the personal needs
of the individual learner.

Concrete
objectives are:

1.

Combining machine learning & multi
-
agent technology for intelligent interactive e
-
learning.

2.

Defining of an e
-
learning standard for adaptive interactivity.

3.

Integrating competencies related concepts with the e
-
learning model through the XML
standard.

4.

Defining a business model for e
-
learning.

As result of the work done, the Consortium delivered the first prototype by February, 2004.

The first prototype provided an eLearning system which is made by two main components: (1) the Authoring
tool th
at supports the definition of the course’s learning scenarios in terms of Learning standards (IMS
-
LD for
the course flow, LOM for the Learning Object descriptions, etc); and (2) a Learning Management System
(LMS) which supports the interactive learning pro
cess. The LMS allows the learner to interact with the system
by going through a learning route with activities and contents specified at design
-
time by means of the IMS
-
LD standard. Furthermore, the LMS integrates interactive services (forums, file storage

area, agenda, etc)
that are also included in the course definition, and provides the baseline for individual and collaborative
adaptive capabilities which are the focus of the developments for the second prototype.

In summary, the first prototype offers a

modular, flexible and extendable architecture, allowing the integration
of new services, and facilitates the integration and exploitation of ALFANET components in other platforms
(e.g: LD engine) thanks to their standard
-
based approach.

Additionaly, some
basic adaptation functionality
was provided to prepare the framework for the adaptation functionality included in the second prototype.

Second prototype was delivered on August, 2004, providing administration functions and advanced
functionality regarding
the courses creation, publication and interpretation. But the main focus of the second
prototype are the adaptive capabilities along the full e
-
learning life
-
cycle, namelly: design, use and audit.

1.2

Purpose

The purpose of this document is to describe the fun
ctionality of the second prototype, making clear what is
available for internal user tests. In consequence, the document will be valid as base for next prototype
identification.

The document includes also the functionality already implemented in the first
prototype, in order to be a
complete document.

It is intended for an internal audience only, including developers and users.

Page
2

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

1.3

Overview

The document contains the following sections:



Chapter 2. System architecture

describes the Alfanet architecture and prot
ocols. It identifies the
communications between different modules, and the protocols to be used.



Chapter 3. Second Prototype interface
presents the appearance of the learning management system.



Chapter 4. Second prototype modules: Server

In this section, i
t is described the functionality included in the Server for the second prototype. It includes
Security layer (SAGE), Dispatcher (SAGE), Presentation layer (SAGE) and Tracker (SAGE and UNED).



Chapter 5. Second prototype modules: Services

This section descri
bes the services included in the second prototype. The modules included in this
section are: Administration module (UNED, SAGE), Course manager (OUNL, SAGE), IMS
-
LD interpreter
(OUNL), Adaptation module (UNED), Multi
-
agent Pedagogical Model (OUNL), Audit m
odule (OUNL),
IMS
-
QTI interpreter (SAGE), Interaction module (UNED, SAGE) and Content server (SAGE). Also the
Common repositories (SAGE) are described.



Chapter 6. Authoring tool

The Authoring Tool (ACE
-
CASE) is included in a separate section, since it is q
uite independent from the
rest of Alfanet. The Authoring tool allows to authors to create courses, meanwhile the rest of Alfanet
relates with the course publication and execution.



Chapter 7. System requirements
describes the application requirements, hardw
are and software,
identified both for the server and client side.



Appendix 1. Bibliography
includes the documents for reference.


For the reader that already knows the D41. First System Prototype, we recommend to skip chapter 2 (seeing
only updates of subs
ection 2.2) and concentrate on the description of the functionality of the second
prototype in each one of the modules (chapters 4, 5 and 6).



Deliverable 4.2


Second System P
rototype

Page
3

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

2.

System architecture

2.1

Global architecture

The following diagram shows the global architecture of ALFANET applicati
on.

Figure
1.

Architecture diagram


This architecture is a three layer composition where:



The
Server

layer is in charge of the user front
-
end, managing the application security, showing user
interface and tracing user interactions.



The
Services
l
ayer is a group of services, which provide the application functionality and main logic.



The
Data

layer comprises the data management and storage.



The
Authoring Tool

is an independent component that allows the user (authors and editors) to create the
cou
rses contents.

The architecture approach has been performed in order to allow the integration of any kind of services, both
in the first development and for future services. At the first time it will consider the integration of the
Interaction Module, IMS
-
LD Interpreter and new services developed in Java, but it is open to include any
other type of technology by the inclusion and configuration of new services interfaces.

Page
4

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

Next, they are described the different components of the application grouped by their
corresponding layer.

2.1.1

Server

Server

layer is in charge of the user front
-
end, managing the application security, showing user interface and
user interactions trace.

Security Layer:

It is in charge of the request retrieving and control. It should be able to
check the user
permissions and to be connected easily to any external security control.

Dispatcher:

It will take the request and distribute the work to the corresponding modules, taking the results
and giving them to the presentation layer. The dispatcher
represents also the interface to communicate the
client side with all the different services. Communication with the new components should be done based in
the object model. With IMS
-
LD Interpreter and Interaction Module it could be done in the best way to

integrate them according with their existing outputs. This component will call to the
Tracker
in order to extract
information about the user requests and to store them in the database.

Presentation Layer:

It will be in charge of taking the results of the
different components and of generating
an application response, taking into account the user profile in order to adapt the results presentation.

Tracker:

It manages the information about the user interactions storing the data that is useful for the
compon
ents operation, mainly for the adaptation modules.

2.1.2

Services

The
Services
layer is a group of services, which provide the application functionality and main logic.

Administration Module:

They are new components and they will be in charge of the application
configuration; mainly the centralization of the needed administration functionality for application services
(System Manager), and the users management (User Manager).

Courses Manager:

It will be in charge of the publication (creation of runs) of the avail
able courses. It will give
the IMS
-
LD and the users information to IMS
-
LD Interpreter. For this prototype, the communication will be
based on EJBs.

IMS
-
LD Interpreter:

It is the service that will be in charge of the courses interpretation.
The IMS
-
LD
inter
preter is based on an existing development but has been totally redesigned and implemented to fit the
overall ALFANET architecture
.

Interaction Module (IM):

It provides the different services that allows the learners to perform a course in the
system. It i
s based on an open source API called OpenACS not to start from scratch, but new code is being
added to OpenACS to adapt it to the specific requirements of Alfanet.

IMS
-
QTI Interpreter:

It is the service that will be in charge of the QTI interpretation, ass
essment and their
corresponding results reports.

Contents Server:

It will be in charge of serving the courses contents.

Audit Module:
It will be in charge of taking the database information and of generating the required reports.

Adaptation Module (AM)
1
:

I
t provides support for the adaptive functionality of IMS
-
LD Interpreter, the
Interaction Module and the Presentation Layer, by accepting requests from the Dispatcher and giving back a
response adapted to the current context and user. There exists a multi
-
a
gent architecture that works
autonomously to solve the adaptation tasks based on the knowledge that these agents can obtain. Internally,
it updates these knowledge by means of a learning process, which takes users’ interactions and apply
various machine le
arning techniques.

2.1.3

Data

The
Data

layer comprises the data management and storage.




1

It has been renamed from “Learning Adaptat
ion module” to “Adaptation Module” to avoid confusion with the
word “learning”, that could be referred to
Machine Learning algorithms

or
students learning
. In any case, it
should be clear that the “Adaptation module” will include
Machine Learning algorithm
s
.


Deliverable 4.2


Second System P
rototype

Page
5

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

Object Model:

It represents the common model that will be agreed by the different components in order to
allow the communications. It will provide the needed functionality to

access the data repositories allowing to
the rest of components to use it.

Common Repositories:

It represents the ALFANET data repository that comprises both the data used by
the new developed ALFANET components and the existing ones (IMS
-
LD Interpreter a
nd Interaction
Module); allowing to share data by all the components.

2.1.4

Authoring Tool

It will be an independent component that will interact with the courses repository through interfaces that
supports WebDAV protocol.


2.2

Communication protocols and architect
ure

The main target of the architecture design is to provide an effective way to integrate existing and new
components within the ALFANET project, providing an open and extensible framework and, at the time,
allowing focusing the development efforts in the

adaptation subjects.

The proposed architecture centralizes the integration and communication between the different modules in
the Dispatcher component. It will be in charge of the interpretation of communication protocols for each
existing component and o
f providing a standard way for the new and future services integration.

The characteristics of the project forces to take into account two types of common needs that all services
should cover:



User interfaces for each available operation (responses to the
user requests with a common interface,
which will be provided by the presentation layout)



Trace of the user interactions in order to provide inputs for the adaptation algorithms

On the other hand, the application should take into account other possible ser
vices needs, which are:



Configuration facilities (to be integrated within the administration module)



Communication with other modules (to provide and use functionality)

The following diagram illustrates the proposed communication architecture:


Figure
2.

Communications architecture diagram

Page
6

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288


The
Dispatcher

takes into account the communication needs and it is based on a set of configuration files
that will provide information about the
Protocol Interface

to be used in orde
r to call the corresponding service
with the appropriate protocol. Taking into account the initial application components, at first it will provide the
following protocol interfaces:

IMS
-
LD Interpreter Interface:

Which will call the IMS
-
LD Interpreter comp
onent and interpret its response in
order to communicate it with the rest of the modules.

OpenACS Interface:

Which will be in charge of the communications with the Interaction Module, and in the
same way that with the IMS
-
LD Interpreter module, it will int
erpret the responses in order to communicate it
with the rest of components if it is necessary via HTTP calls.

JAXM Interface:

It will be used for new developments and will be based on the JAXM standard (J2EE
Standard) in order to take advantage of the fun
ctionality that the J2EE Application Server provides. All the
studied application services, apart from OpenACS and IMS
-
LD Interpreter services, will be implemented
based on this interface.

On the other hand, it considers to include within the
Protocol Inte
rfaces

those functionality that extract
information from the request and the corresponding response in order to get information about the operation
and relate it with user interactions.

Finally, it has been included a mechanism that allows the services to
inform to the server (and to other
services) about data changes, operations or any other important issue that can be required by other services
in order to work or to synchorize data. This mechanism is based on an Event notifications. Each service is
able
to launch events to the system and to be subscribed to those ones that it needs.


Deliverable 4.2


Second System P
rototype

Page
7

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

3.

Second Prototype interface

In order to give an idea about the prototype, in this section we presents the appearance of the learning
system that is going to use both: the tutor

and the students.

The prototype is available at the SAGE web server, and it connects with the UNED server (where the
Interaction services and Adaptation Module is running).

http://rtd.softwareag.es/a
lfaneta/server


Next screen presents the main entrance to the prototype, that is the concrete workspace of the user that is
entering. Different areas are presented: general collaboration activities (fora, file storage, etc.), and the list of
courses that

are available to the user.



Figure
3.

Main entrance to Alfanet learning system




Page
8

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

When the user (learner or tutor) selects one course, then the course activities are presented to the user.
Besides, a special area for adaptation is presented. In

addition, the user can change its role (according to
what is previously defined in the course by the author).


Figure
4.

Example of one course in Alfanet learning system


The interface that has been presented in this chapter is one of the prese
ntation interfaces that the user can
select in the configuration of his/her LMS. Thus, the second prototype offers the user the possibility to there
to configure (from the UI Preferences administration) the User Interface presentation from among a set of
a
lternative interfaces. Nevertheles the functionality and the modules showed in different user interfaces is
basically the same. The differences between each user template is the structure of the screen, the way in
which the menus operate and are showed and

how the information of each service is presented at each
moment.

In the next screen we can see other user interface template, that summarize the contents of the current
connection in the left side, and allow to access to each content in the right side of

the screen by simple
clicking on the corresponding menu link.


Deliverable 4.2


Second System P
rototype

Page
9

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288


Figure
5.

Other user interface template


Page
10

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

4.

Second Prototype modules. Server

This section describes the modules included in the second prototype (we include 1P if they are already for t
he
first prototype or 2P when they are new).


Alfanet module for the 1
st

prototype

Developer

Security layer (1P, 2P)



Fl潷⁳煵敬整e渠⠱n)



S散畲楴y⁣桥cki湧㨠:灥r慴a潮s ⁁灰⸠副.敳
㉐)

SAGE

䑩s灡瑣桥r



A灰lic慴a潮⁦l潷⁡ 搠d敲eic敳⁣潮湥c瑩潮s
ㅐ)



乡瑩ve

X䵌 i湴牵n瑩潮 i湴nr灲整慴p潮 慮搠
潰敲慴e潮
㉐)

SAGE

Pr敳敮瑡ti潮慹敲



B慳ic⁐r敳敮瑡ti潮
ㅐ)



啉U Pr敦敲敮e敳 (A摭i湩s瑲慴a潮 慮搠 潰敲慴e潮)
(㉐)



Pr敳敮瑡ti潮⁡ 慰瑡ti潮
㉐)

SAGE

Tr慣k敲
㉐)

SAGE

4.1

Security layer

The security manager has two main fun
ctions: controlling the application access, and controlling access to
concrete operations.

According with this the application security for the is structured into two levels:



Application access control; i.e. the control of the user access to the public or

restricted domains of the
ALFANET project. This has been delegated to the corresponding service of the J2EE Application Server.
It has been developed the JAAS module which, using JCA, connects the Application Server security with
the application repositor
y providing the user identification, server role and authentication process.



This has been developed having into account that different operations belonging to a same service must
have access control for different types of users. Access control is implemen
ted upon a configuration file
(configuration.xml) that describes the different services available and their target users.

The
first prototype

integrated the application access control. The
second prototype

has incorporated the
Alfanet security control. Thi
s security control is implemented by checking the access permisions of a user
over an application operation. Access permisions are defined in the configuration files of Alfanet. In this files,
all the operations that has an specific security permissions (b
y default all operations are allowed for all users)
must specify the roles that have access permission . The Security Layer implementation chack the user and
the roles that he has assigned, the operation that he is requesting and compare this information w
ith the
defined in the configuration file. An example of the definition of the security is showed in the following lines of
the configuration file of Alfanet:






<service id="coursemanagerto
ol" name="Course Manager" type="coursemanagertool">

<description>Course publishing service</description>


<operation id="" name="Publish new courses" admin="true" allowed="admin"/>

</service>



Deliverable 4.2


Second System P
rototype

Page
11

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288


4.2

Dispatcher

The Dispatcher is in charge of the request interpretation and work distribution

between the application
services. It contains all the logic related with the communications with these services and it establishes what
are the interfaces that the services must provide in order to be integrated within the application.

It has been develop
ed a first version of the dispatcher and all the related infrastructure (application context,
error managing, application configuration, services connector interface, and specific connector
implementations for the services provided by the Interaction Modul
e, Content Server, QTI tool, IMS
-
LD
Interpreter and static contents). A generic connector has been implemented based on the JAXM API (Java
API for XML Messaging) which is used to interface different modules collaborating with the Dispatcher.
Currently, the

Adaptation module is connected using the standard interface defined with JAXM.

The implementation of the dispatcher in the
first prototype

covers the requests interpretation, management
of configured work spaces, calls to the corresponding services and fi
rst treatment of their responses), more
specifically:



The dispatcher interprets the request string by splitting it and identifying what are the called services and
what are the parameters for each one of them.



It implements the server flow, looking for th
e services configuration and identifying what are the
interfaces that should be instantiated in order to transfer the request to the service. (Interface caller)



Additionally it provides the Presentation layer with an unified XML structure, having into acco
unt both the
output from the services and the user “context”.

Second prototype

developments cover:

The operation of the previous version of the dispatcher divided the flow with each service into two main
operations: Context updating and response serving. S
econd prototype includes a third operation, between the
two existing ones: The opartion without response. In this way, the user or other service can request an action
that has no response, for instance, it can be performed some action and then control can
be delegated to
other service or service operation.

It has been implemented the interpretation and operation of the instructions (calls and events), error
messages and extra traces that can be returned by a service within a native XML response


4.3

Presentatio
n layer

The presentation layer

is in charge of the organised presentation of the different types of material; providing a
usable and integrated response to the user.

The functioning of the Presentation Layer and the corresponding transformations are based

on the definition
of a common intermediate interface language (DTD) that must be retrieved by the different modules. This
language has been defined upon xhtml.

The
First Prototype

included a first version of the presentation layer covering the management
of the
services responses in order to show their results and the management of the work spaces presentation. The
user interface generation engine is implemented.

Particularly, once the user is identified, the presentation layer gets the corresponding user
Presentation
Layout

(XSLT) and the common components templates and transforms the generated XMLs by using the
TrAX (Transformation API for XML) standard and generate the corresponding user interface.

The
Second Prototype

includes a more complete version of

the Presentation Layer, including the following
functionality:



Improvements to the Basic Presentation Layer: Development of
templates

(xsl) corresponding with a
new
User Interface

according with comments received from validation activities corresponding w
ith the
first prototype.



Personalised Presentation
, which allows a user to select from among exiting presentation layouts, and
applies these layous in the presentation of information coming from different modules.

Page
12

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288



Adaptive Presentation, in charge of presen
ting different course related items in the way that better suite
with the learners’ preferences and interests. Order, enphasise or remark different items. , which is
finished except for the final definition of rules structure that must be designed accordin
g with the
specifications coming from the Adaptive module.

Requirements:



Personalised presentaion only imposes the requirement of having an underlying datamodel, which is
supported in a XML DataBase. The DataModel is filled
-
in by the end
-
user through a pre
ferences setting
button.



Adaptive presentation of any service requires that the information retrieved from the service is provided in
an XML (xhtml
-
based) native language defined within ALFANET. For those services that do not adjust to
this situation, but
that retrieve another XML output or a well
-
defined xhtml from which underlying
concepts can be easily derived, ALFANET provides the means to associate a XSL to transform to the
ALFANET native language.



Additionally, either the adaptation module or a speci
fic domain
-
rules definition module will be required.
Both modules provide the Adaptive presentation module with baseline rules (dynamic or static) to apply in
presentation time.

Technical features:

The functionality of the Presentation components is suppor
ted through the following technical features:



The Presentation components work on LIP standard, which takes advantage of possible existing User
characterisation from target eLearning applications, with independence of the methods used to get user
attribute
s. Additionally, and through the Adaptation module, this LIP module can be enriched with new
features. To achieve with this last functionality it has been defined an extension of the LIP standard
(adapted to it in the extension nodes) that provides the inf
ormation needed to achieve the adaptation.
This new characterisation has also a generalization of user characteristics in order to allow the use of this
ones in new rules and new adaptation tasks and rules.



An XML schema supports the User Preferences defin
ition. The User interface templates are also defined
in XML schema.



Adaptation of presentation is achieved throght presentation rules. It is based on a root rule that can
contains another ones in order to structure its definition. All rules can be defined
as complete
mathematical functions in which it can be included logical structures with the result that will represent the
weight of the evaluated item in its environment. The relation between the user characteristics and the
final result can be performed b
y including in the rule expression the name of the user characteristic as a
simple variable. The system will give to this variables their corresponding contextual values. Finally a
XML shema supports rules structure.



Access to Data Structures is encapsulat
ed through a DataAccess layer which provides flexibility to
update the physical definition of the Data Structures, with the possibility to accomodate to other
DataBases.


4.4

Tracker

The tracker module has been developed for the
Second Prototype
. It is in char
ge of
tracking all the user’s
key interactions ans storing them in the Data
-
Base for further retrieval and usage by other modules. It also
manages the communication between modules through events and notifications

The tracker module includes:



The
tracker e
ngine



E
vents/Notifications

4.4.1

Tracker engine

The tracking of this interactions is performed by the same Tracker module, which is informed by the
dispatched with the user requests and interpret these ones in order to generate de corresponding trace.


Deliverable 4.2


Second System P
rototype

Page
13

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

Traces ca
n also be generated by any of the system services and server. It has been implemented a
mechanism within the dispatched in order to analize the service responses and extract from them those
traces that the services , or the corresponding connectors generat
es from their operation.

It is also provided an asynchronous method for traces generation. It consists in a servlet that can be called by
any service in order to notify about a issue (trace) that happens out of the Alfanet normal operation (this is,
when a

service perform an operation withot a previous system/user request and it must be traced). This
mechanism is in charge also of the generation of the trace context.

Traces include the following information

:



Trace Context data

: That describes the situatio
n in which is generated the trace (user request, user,
course, activity…) This information is generated in every user interaction by the Tracker.



Specific service trace

: It has been designed a data model that supports generalization in order to allow to
t
he services to give information that is not known in the system design time. This information is which the
services provides.

4.4.2

Events/Notifications

Within the tracker module it has been also included the Event Manager submodule. This module is in charge
of
capturing services generated events and of the communication of these events to those services that are
subscribed to its type or origin. The Event Manager has been included in order to allow an synchronous
communication between services, allowing the tran
sfering of information between them. For instance, when a
user fills a course test and it is evaluated by the QTI Tool module, it generates an event which can be listened

by any other service (LD Engine) in order to know the user test results.

Event Manag
er has the following structure

:



A System Event Listener that is in charge to capture the events generated by services and provided by
the dispatcher.



An Event Manager that is in charge of

:



The generation of the event standard data structure from the orig
inal event,



The trace of the event throught the Tracker



The identification of the subscribed services

: The events are described by its origin, identifier and
type. Any service can be subscribed to an event type, origin or identifier through the configurat
ion
defined in the Alfanet configuration file and the implementation of an specific Event Listener. The
following lines shows how it is configured.











Event Listener Interface

. Interface for services which will be called by the Event Manager.


<service id="impublication" name="OpenACS Publication" type="openacs">


<description>Course publishing se
rvice in OpenACS</description>


<event
-
subscription listener="com.softwareag.alfanet.services.openacs.OpenACSConnector">



<condition eventId="COURSE_PUBLISHED" serviceId="coursemanagertool"/>


</event
-
subscription>

</service>

Page
14

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

5.

Secon
d Prototype modules. Services

The services included in the second prototype are the following: (we include 1P if they are already for the first
prototype or 2P when they are new).


Alfanet module

Developer

Administration module



䍯湦i杵r慴a潮
ㅐ)



啳敲a
湡来r
㉐)



Pr敦敲敮e敳⁍ 湡来r
㉐)



T敭灬慴as慮慧敲
㉐)

SAGE ⁕久D

䍯畲C攠e慮慧敲



䱯杩c
ㅐ⼲/)



W敢⁵ 敲⁩湴nrf慣攠⠲e)

O啎䰠⼠UAGE

䥍I
-
䱄⁉L瑥牰t整er



䱥v敬⁁
ㅐ)



䱥v敬⁂
㉐)

O啎U

䥍I
-
QT䤠䥮瑥牰t整er



QT䤠Ii瑥t(ㅐ)



QT䤠⠲I)

SAGE

A摡灴p瑩潮⁍ 摵l攠
(A䴩
㉐)

啎䕄

A畤i琠t潤畬e



B慳ic⁳瑡t搠dl潮攠⠱e)



䍯C灬整e⁩湴n杲慴敤
㉐)

O啎U

䥮I敲慣瑩潮潤畬攠



䥮I敧r慴a潮
ㅐ)

乥N⁳敲eic敳⁡ 搠d䵌⁩湴n杲慴g潮
㉐)

啎䕄 ⁓AGE

䍯湴敮琠t敲e敲



S敲ei湧⁦il敳
ㅐ)



S敲ei湧⁦il敳⁡ 搠d潮瑥t瑳整e
-
摡瑡t(㉐)

SAGE

A䱆
A久T⁉ 瑥tr慴a潮
ㅐ⼲/)

SAGE


5.1

Administration module

The Administration Module serves as a common interface for system configuration and user management
hiding the corresponding functionality that it is provided by the other modules of the system, and to
configure
general application parameters. It is divided in two subsystems: the System Manager and the User Manager.
The first one is in charge of the application configuration and the centralization of the needed administration
functionality for applicatio
n services.

As stated in D21, the User Manager will be in charge of the management of users, groups and the security
permissions for both of them. The permissioning system used is the one provided by OpenACS, which is the

Deliverable 4.2


Second System P
rototype

Page
15

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

framework used to support the dif
ferent services that will be provided by the system as Alfanet Interaction
Module (see the corresponding section). It allows to set access control policies at the object level, being
possible to explicitly set control rights for every user and every object
, although it also allows to work with
large security domains by using object context groups and inheriting permissions to the children objects (an
object is any entity existing in the system, from a user to the answer to a message of a forum). As a result
,
two levels of permission are used in Alfanet:



Group profiles: the services provided by the Interaction Module may have different permissions
according to the course or the activity the user is taking part. Thus, the group profile allows to control
the re
sources to which each group can access.



User profiles: different types of users exist in Alfanet system. In the high level there are learners,
tutors, administrators, managers and authors, but inside each course and each specific activity, it is
possible t
o have particular users with very concrete permissions on some services (e.g. a learner that

has been selected as the moderator of a service to perform a collaborative activity specified in the
Instructional Design by the author of the course), as differen
t roles the users may take along the
course.

Other issue the User Manager should manage is the synchronization of users among the two existing
components that have been integrated in Alfanet, the IMS
-
LD Interpreter and the OpenACS framework. For
the first
prototype, the registration of users were not fully synchronized. The users only needed to register
once by filling in Alfanet registration form, but these data were sent both to the IMS
-
LD Interpreter and
OpenACS user managers, thus being replicated in bo
th modules.

The registration form built for the first prototype is made up of four different parts. The learners will have to fill
it in after registering in the system. The data gathered with this form will be used as the basis for user
modeling. It will

allow us to include the user in one of the user stereotypes we have defined, thus some initial
and rough recommendations based on these data can be provided from the very beginning. Later, after the
user interactions in the system, his/her user model will

be continuously refined, being as specific to the user
as possible. These parts are:



Personal data: basic initial data from the user, such as name, age, profession.



Preferences: it collects basic preferences and habits of the learner



General knowledge: it

collects the knowledge the user has from a very generic way, and
independently from any course of the system



Learning Style: we are using The
Index of Learning Styles

to assess learner’s preferences on four
dimensions (active/reflective, sensing/intuitive
, visual/verbal, and sequential/global)
2
.

This forms are not to be course related, but general to any learner of the system. When the user joins a
specific course, course specific forms can be provided, too. This will require that the author of the course
specifies the corresponding form at design time or the tutor creates a form for the course at run time.

Once the user is registered in the system, he/she can access his/her user model from the personal area, to
see what the system knows and modify some dat
a. In the next prototype, the user will also have access to
what the system has learnt about him/her and will have an option to disagree with what the system has learnt.

In the
second prototype
, it is implemented:



Complete user management



User preferences
data model and user interface



Templates manager (allow to register new presentation templates)



Extension of alfanet configuration files


5.2

Course manager

The
first prototype

of the course manager provides the administrative API for the IMS
-
LD Interpreter. It

provides the following functionalities:




2

Copyright © 1991 North Carolina State University (Authored by Richard M. Felder and Barbara A. Soloman). Reprinted by permiss
ion
of North Carolina State University

Page
16

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288



Interface for validating an IMS LD level A content package.



Interface for publishing a validated IMS LD level A compliant content package.



Interfaces providing user management functions for the IMS
-
LD Interpreter. U
ser management
includes user creation, deletion, assignment to roles and assignment to runs.



Interfaces for role instantiation.



Interfaces for property access.


Second Prototype
:

The second prototype enhances the CourseManager allowing the interpretation
of IMS LD level B. IMS LD
level B extends level A with the following additional constructs



properties
. The CourseManager deals with all types of properties defined in IMS LD: These are
integer, real, string, text, uri, file, date
-
time, duration and boolean
. Properties are checked regarding
defined constraints, datatype values during validation of the IMS manifest.



property
-
groups
: Properties can be grouped together using property groups. Groups may include
properties or property
-
groups. The CourseManager pr
epares the defined groups and converts them
in the appropriate property references in the global content.



expressions and conditions
: The CourseManager parses all expressions and conditions and checks
if they are syntactically correct. Conditions are conve
rted into an intermediate language that can be
interpreted during runtime delivery.



monitor
: provides a means for user to monitor other users progress by viewing the dossier (i.e.
collection of properties or property
-
groups).



global elements
: provides mean
s for a user to view or set properties and property groups while
viewing content. For this purpose IMS LD extends the XHTML specification with four additional
elements (view
-
property, set
-
property, view
-
property
-
group, set
-
property
-
group). The CourseManage
r
preparses these extensions during the publication stage.

The CourseManager component has been improved by providing additional checks in its internal processing
logic. This makes the CourseManager more robust against incorrect calls.

For the second proto
type the CourseManagerDelegate has been extended beyond a mere façade, to include
additional pre
-
processing which simplifies the use of the API interface. It is now expected that the
CourseManagerDelegate is used rather than making any EJB calls directly.
For example the process of
validating or publishing an IMS LD document has been simplified by the use of this delegate.

Exception handling has been improved by the introduction of a collection of newly defined exceptions. This
way a client calling the Cour
seManager can more easily track errors during validation/publication etc.

The CourseManager has been extended with its own logging facility. For this purpose log4j has been used
which is now in harmony with the rest of the system.

5.3

IMS
-
LD Interpreter

The IM
S
-
LD Interpreter delivered in the
first prototype

provided the business logic for the delivery stage of
IMS Learning Design level A. The IMS
-
LD Interpreter API is rather straightforward and simple. The calling
module is responsible for providing a mechanis
m for authenticating the user. Based on the user id and the
selected run a statefull LDEngine session bean needs to be
created
. Next the calling module can retrieve an
activity tree

for this particular user. An activity tree is expressed in XML and resembl
es the tree defined in
the method section of Learning Design with the difference that the activity tree is personalized for the user’s
active role and progress. The tree is made up out of branches and leaves. A branch is of the type play, act,
role
-
part an
d activity
-
structure. Leaves are of type learning
-
activity or support
-
activity. How each node should
be processed is described in the IMS LD specification. Now follows a short description about the specific
aspects of the tree that are different from the L
earning Design specification.

Each node has an
identifier
. This identifier is the same as the ones in Learning Design. The identifier is the
most essential key for the calling module to retrieve information and is used in all calls with the exception of
th
e activity tree itself, which doesn’t need a key for obvious bootstrapping reasons. Besides this identifier
attribute almost all nodes have a completed attribute indicating the completion state for the user with respect

Deliverable 4.2


Second System P
rototype

Page
17

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

to this node. Allowed values are:
no
t
-
completed
,
completed

and
unlimited
. The first two are obvious and the
third refers to a special state that indicates that this node can not be completed but should be treated as if
completed.

Some of the nodes have an additional
time
-
limit

attribute whic
h is set to
true
. This indicates that the
completion for this node is based on a timer. After a defined duration has elapsed the property will be set to
completed
. The calling module can use this attribute to inform users about this fact. When the user
-
cho
ice
attribute is set to
true

for a particular node, the client should render a possibility for a user to indicate if he or
she feels the node has been completed.

For some of the nodes an
environment

attribute may be defined. This attribute contains a toke
n list of all
environment ids that are associated to this node either directly or by inheritance of one of its parent nodes.
This attribute is essential when retrieving the environment tree for this node.

An environment tree describes which environments, s
ervices and learning objects are associated with a
particular node. Again the result is represented in an XML format resembling the original LD as closely as
possible. The major differences are described here. For a more general overview of the semantics o
f the
elements we refer to the IMS LD specification. Each environment node has an
identifier attribute

as was the
case in for the activity tree. This identifier is the key for retrieving any content associated with the node.

For both the nodes in the envir
onment tree and the activity tree,
content can be retrieved
. Content is
retrieved using the identifier of the node and the type of the node which corresponds to its XML tag name.
Content is returned as XML as also here it matches as much as possible with t
he original Learning Design
format. The content is personalized where appropriate, like for example is the case with the feedback tag,
which can be available or not all depending on the progress of the user. The content contains the items which
are also de
fined in Learning Design. However the identifier
-
ref attribute from the Learning Design
specification has been replaced with the
url attribute

referring directly to a resource representing the content
of this item. The client is responsible for retrieving
all the content referenced by an item.

Second Prototype
:

The second prototype of the IMS LD interpreter is capable of interpreting IMS LD level B. The impact on the
interface as described above is limited. One exception is the distinction between the loca
l content and the
global content. The local content was available in the previous version of the prototype. The global content is
new. It contains XHTML with four extensions from IMS LD (view
-
property, set
-
property, view
-
property
-
group,
set
-
property
-
group)
. These properties are either rendered into the content or are set by the user. This change
will result in the following actions by the IMS LD Interpreter:



Property value are checked for any restriction violations as defined by IMS LD. Restriction violatio
ns
can be violation against the datatype or against one of the explicitely defined restrictions. The
restrictions include for example minimum, maximum, patterns, enumeration restrictions. Invalid
values are never stored and an exception is thrown.



If the v
alue was valid, the IMS LD Interpreter persists the value and start determining the
consequence. Consequences are expressed using IMS LD expressions and conditions. Examples
are the completion of an activity when a property has been set to a specific value
. The change of one
property can lead to a chain of events(e.g. setting of properties) where each event can trigger a new
events. IMS LD distinguishes five types of events: property changes, role change, completion, timer
and first access events. For all t
hese events the IMS LD Interpreter computes the required actions.


Besides the global content, the IMS LD Intepreter has the following additional features compared to the
previous version:



The IMS LD Interpreter includes the monitor object which allows mon
itoring of other users
progress by inspecting their dossier of properties.



Exception handling has been improved by the introduction of a collection of newly defined
exceptions. This way a client calling the IMS LD Interpreter can more easily track errors.



The IMS LD Interpreter has been extended with its own logging facility. For this purpose log4j
has been used which is now in harmony with the rest of the system.



The IMS LD Interpreter has been improved by providing additional checks in its internal
proces
sing logic. This makes it more robust against incorrect calls.

Page
18

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288



A special TrackerModule has been included to notifiy the Alfanet tracker of events occurring in
the IMS LD Interpreter. These ‘tracks’ are taken up by the audit and adaptation module for furthe
r
evaluation.



Improved timer handling. The timer bean has been replaced by an EJB message bean. This new
approach has several advantages. First the performance will benefit as most of the processing
will be done in the background now, freeing up cycles for

the users that are on
-
line. Secondly it is
far easier to make a simple integration with the application server by having the application
server calling the message bean on a regular basis, instead of a separate client application.
Thirdly, message beans h
ave the advantage that there is a guaranteed delivery of the message
making the system more robust.

A cache has been implemented allowing faster processing of properties, expressions and conditions.

5.4

IMS
-
QTI Interpreter

The IMS
-
QTI Interpreter provides an i
ntegrated tool for the representation of question (item) and test
(assessment) data and their corresponding results reports. At the representation level, the QTI interpreter
delivers the HTML representation. At the assessment level, the QTI interpreter per
forms the actions defined
in the tests for test evaluation.

The
first prototype

of the IMS
-
QTI Interpreter supports the 'IMS Question & Test Interoperability QTILite
Specification'. This specification is based upon the 'IMS QTI: ASI Information Model' and
is the realization of
a subset of that model. QTILite is presented as the entry
-
level specification to the full QTI specification.
QTILite does not support all of the features of the full QTI specification however an instance that conforms to
QTILite will
also conform to the full QTI specification. The key differences between QTILite and the full
specification are:

The only question
-
types to be supported within QTILite are:



Yes/No;



True/false;



Likert scale examples could be: strongly agree, agree, neutral,
disagree, strongly disagree, strongly
agree, agree, disagree, strongly disagree, agree, neutral and disagree;



Other forms of multiple choice (i.e. one choice from many);



Simple response processing to provide for a single right answer and using the default
mechanisms.

No support for:



Hints and solutions;



Meta
-
data;



Comments;



Extensions;



Options that are "fuzzy";



Limited media types and limited text types;



All time
-
based mechanisms.


Second Prototype:

The Evaluation and Assessment package provides support for

the definition of questionnaires at design time
and the presentation of these questionnaires and their evaluation at run
-
time. For this prototype IMS
-
QTI
Interpreter supports the 'IMS Question & Test Interoperability Specification' v1.2 .

Description of
overal functionality



Definition of a set of items (questions) of different types. Current version supports following item types:

Standard True/False (Text), Standard Multiple Choice (Text, Images), Standard Multiple Response
(Text), Multiple Choice with I
mage Hot Spot Rendering, Multiple Response with Multiple Image Hot Spot
Rendering, Standard Single and Multiple Fill
-
in
-
Blank (Text), Standard Short Answer (Text), Standard Fill
-
in
-
Blank (Decimal, Integer), Standard Drag
-
and
-
drop (Images), Multiple Choice
with Fill
-
in
-
Blank, Matrix
-
based Multiple Response, Multiple Standard Fill in Blank (decimal & integer)


Deliverable 4.2


Second System P
rototype

Page
19

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288



Generation of dynamic questionnaires incorporating items from different object banks and attending to
different conditions (by means of metadatas defini
tion).



The above feature can be exploited for providing self
-
testing capabilities launched on user demand, or
promoted/suggested by the Adaptation module.



Presentation and evaluation (assessment) of questionnaires, presenting test results in a consistent
m
anner.



Possibility of specific integration with the e
-
Learning platform, i.e. it is possible to integrate the course
instructional design with the tests results, thus providing control on course evolution.

Components

The Evaluation and Assessment package i
s made by the following components:



QTI Items definition
. This component is in charge of defining basic items of very differnt types and
questionnaires integrating several items. Currently this component is supported by external QTI tools.

Canvas Learning
Author tool was proposed in order to design items according to IMS Question and Test
Interoperability (QTI) specification.



QTI tool Authoring dynamic adaptive tests
.
This component complements the previous one to add
adaptive capabilities as defined in I
MS
-
QTI standard, supporting the definition of questionnaires that may
combine items from different object banks having into account specific conditions. The development has
been performed because the QTI tools analysed did not support this part of the QTI
specification
(Selection and Ordering), and because this functionality has been determined a requirement for user
partners.

The dynamic adaptive tests are defined on the basis of metadata associated with different test items,
and additional information des
cribing which items (in terms of metadata as kind of learner they best suit
to, nature of item, etc) from which object
-
banks will be selected to form the final questionnaire.

A first version of this tool was presented to the consortium in the meeting held
in Stuttgart in May 24.
Additionally, Software AG delivered a release of the tool for usage and validation by users in June 17.
The release included a User manual. This tool is based on
IMS Question & Test Interoperability:ASI
Selection & Ordering, Version

1.2. This ‘Selection & Ordering’ specification contains the description of
how the sequence in which Sections and/or Items are presented can be controlled. The selection and
ordering process is a two
-
stage operation in which the child objects are selected

according to some
defined criteria e.g. meta
-
data content, etc. and the order of their presentation is then determined.



QTI Presentation and Evaluation
. This component is in charge of presenting the questionnaires to the
final user (learner) including the

dynamic generation of questionnaires based on defined attributes,
evaluate them, present feed
-
back to the user, and provide an effective integration of the overal test result
with the e
-
Learning application. This component is divided into the following on
es:



QTI Presentation
. This module interprets an XML structure (QTI) integrating the different tests
belonging to a questionnaire, and presents the different item tests to the user making them available
for fillin
-
in and further evaluation. This module has
been developed in Flash, thus allowing a more
powerfull presentation of item tests. The module, which includes presentation of different item types
(as multiple choice, multiple response
-
including image hot spot rendering, etc) has been presented
to the c
onsortium in the consortium meeting held in Stuttgart in May, 2004.



QTI Assessment
. This module manages responses generated by learner, evaluates them according to
items definition and generates scoring information using a scoring module that implements S
um
-
of
-
scores
algorithm
. In evaluation process QTI Assessment module decides
the feedback that is to be
presented as a result of the user’s responses if the conditions defined within the item occur. The
feedback can include hints and solutions and both of
these can be revealed in a variety of different
ways.

Requirements

This module do not impose any condition to the target eLearning platform. The QTI module is offered as an
independent service.

Current state of IMS
-
QTI module requires the usage of an exter
nal QTI tool to generate the basic items
following the QTI standard.

Page
20

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

Technical Features:



The IMS
-
QTI Interpreter supports the 'IMS Question & Test Interoperability Specification' v1.2 . A
summary of supported features are described as follows:

Object bank
level support

-

Meta
-
data

Assessment level support

-

Meta
-
data

-

Reference

-

Selection & ordering

Section level support

-

Meta
-
data

-

Reference

-

Selection & ordering

Items supported

-

Meta
-
data

-

Question types

-

Multiple choice

-

Drag and Drop

-

Fill in the Blank


-

Flow

-

Response processing

-

Feedback

-

Hints & Solutions

Material Content

-

Text

-

Image



It takes advantage of flexibility inherent to IMS
-
QTI standard and thus offer the capability of integration
with other standards as IMS
-
LD and IMS
-
LIP, through attribu
tes (meta
-
data). Integration with IMS
-
LD
provides Instructional Design based courses with the capbaility of acting upon results of questionnaires.
Integration with IMS
-
LIP makes that this integration is based on standardised user
-
defined features.


The QTI

components have been integrated into ALFANET Second Prototype. The delivery includes the user
manual corresponding with

QTI Author tool has been elaborated and delivered to the consortium.


5.5

Adaptation Module

As defined in the D21 General System Architect
ure and Design (section 4.2.11.2) the Adaptation Module is
made up of four different submodules:



Configuration Module, which involves the agents administration, the multi
-
agent system configuration
and the adaptation tasks configuration. The ALFANET admini
strator can configure some adaptation
parameters in order to control the adaptive behavior of the system.



Recommendations Subsystem, which receives the requests of adaptation tasks from the Dispatcher
and gives back a response.



Model Subsystem, which mana
ges the knowledge to solve the adaptation tasks.


Deliverable 4.2


Second System P
rototype

Page
21

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288



Modelling Subsystem, which updates the knowledge managed in the Model Subsystem by applying
machine learning techniques to the interaction data.

In the
first prototype
, the Adaptation Module was built as an
initial infrastructure to test the communications
with the different ALFANET modules, and two adaptation tasks were defined and used in the implementation.
These tasks were ‘Selecting a Moderator for a group of learners’, which is addressed to the tutor of

the
course, and ‘Recommending the Next Activity to a learner’.


For the
second prototype
, the initial skeleton for the Recommendations and Model subsystems
(implemented in first prototype) is reinforced and the communication with the Modelling subsystem i
s added.
The Configuration module will be implemented for the final system.

The adaptation tasks considered for this prototype are:



Learner Modeling. Learners are modelled using all the information available of the system: observed
data (i.e QTI results),
interaction data, infered data (inference rules) and learned data (machine
learning algorithms) from them.



Diagnosis of pedagogical situations. We have worked on two scenarios,
lack of knowledge

and
high
interest.



Recommendations: suggest the appropriate
LO according to the learner style and their currrent
pedagogical situation.



Support: provide motivational messages to the learner to increase the interest.


Next, we describe in more detail the functionality provided for the second prototype and the implem
ented
subsystems.

The
Adaptation
Module

is in charge of providing run
-
time adaptations to cope with the learning needs and
unpredictable situations that come across while interacting with the system. In other words, it identifies
relevant pedagogical situa
tions to enhance learning experience based on previous users’ interactions.

When detected one of these situations, the system will recommend to each individual learner in each relevant
pedagogical situation of the course the most appropriate material takin
g into account the interactions
performed by a group of similar learners, based on implicit collaboration interactions. As result a rich
interaction model about the implicit collaborations performed in our system is obtained, updating the learner
model.

In

our approach, inference and machine learning techniques are used in (1) modelling tasks to build and
update the models, (2) diagnosis tasks (computing the risk level of an educational problem for a learner) and
(3) identifying similar learners with collab
orative filtering techniques. All them are based on the analysis of the
interactions performed (individual and implicit collaborative interactions).

The recommendation process is supported by a multiagent architecture, where different types of agents
(coor
dinator, recommendatory, model and modelling) interact with each other to give the corresponding
recommendation to the learner.

The
Recommendations

subsystem launches a recommendation process consisting on the following three
steps:

(1)
Identify the curren
t pedagogical and contextual scenario for the learner considering the user individual
data, the existing experience with the course and the current context.

(2) Select the learning objects to recommend, focusing on the learning objective and considering t
he
sequence of interaction already performed.

(3) Analyze interactions of similar
-
learners
-
group about learning
-
objects
-
group to provide a list of learning
objects with their utility measure.

To make this possible a complex set of models has to be managed

by the
Model

subsystem within the
Adaptation Module. In particular, to perform the task of recommend learning objects, it works with the
Learner, Course, and the Interactions models (performed by the learner or the group within the services in
the course
context). Also Group and Services models are considered.



The
Learner Model

is an extension of the IMS LIP standard, including attributes grouped in personal
data, learning styles, background knowledge, habits, preferences and interests.

Page
22

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288



The
Course Model

pr
ovides four relevant elements: Course Objectives, Activities, Learning Objects and
Services. The Course is structured in different levels, each one defines its
objectives
: general course
objective, objectives of each module and objectives of each concept t
o learn. It is at the intermediate
level where the study is more interesting. The Adaptation Moduel can study each learner and what is
her/his situation respect to one specific objective: interest level, initial knowledge, progress, and
achievement level.



The
Service Model

describes the different educational services provided by aLFanet (forums, file storage,
comments, ratings, etc) and stores learned indicators as:

When it is most useful to be used, With which
configuration parameters, by what type of lear
ners, for what course objectives
.



The
Interaction Model

(commonly considered as a part of the User Model) describes the learner
experience and progress in a global context: Current Situation, Statistics and Historical interaction in
aLFanet.

At course leve
l the following interactions are stored:



Interaction items

(II) are generated by the learner during the course experience as result of the
interaction within the Services. The scope can be individual or shared with the rest of learners.
Examples of II are:

Messages in a Forum service, files or URL’s in the File Storage service.



Characterization Items

are interactions that characterizes, gives the opinion of the learner about
other LI (provided by the author or other learner). Examples are users’ comments an
d ratings
.



Learning Items

(LI) are both II and the Learning Objects provided by the author at design time.



Interaction Events
are passive accesses to a LI.




Evaluation Item

provides a result of the interaction with a Learning Object of type IMS QTI
3

(quest
ionnaire or evaluation of an activity
).



Organizational Item

is used to organize (grouping, classifying) the interaction items. Examples are
Threads in a Forum service, folders in the File Storage service
.



Categorization Event
: The learner can assign LI to
one or more categories, facilitating the
conceptual understanding.



Link Event
defines a relation between two LI
.

For each interaction we analyze the time spent, the size and the amount of interaction produced.

Other information stored is:



Recommendations

provided to users, including both the generation step and the serving step.



Session
s that usually reflect the concept of a running class.



Navigation path
: this is the most basic information that can be used to infer any other relation
between different ite
ms at run
-
time.



Finally, the Group Model characterizes a set of learners that are working in a course and has the
following attributes:



Composition (number of learners, diversity in type of learners, previous experience as group,
participation level, motiv
ation).



Temporal context (start
-
date, end
-
date).



Course_context (course_id, activity_id objective_id).



Interactions in the collaboration task associated (if any).



Statistics about the behaviour of the learners in the course (mean and total values of the us
e of
resources).

The set of models are stored on the knowledge base of THEO (a truth mainteinance system with inference
rules), in addition to the common repository. Models are also used as support for the adaptive functionality of
the Instructional Design

interpreter, the Interaction Services and the Presentation layer.




3

IMS Question & Test Interoperability


http://www.imsglobal.org/question/index.cfm



Deliverable 4.2


Second System P
rototype

Page
23

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288


The
Modelling

subsystem automatically computes the value of some attributes of the above models, when a
predefined rule cannot be applied to infer its value. The process takes the followin
g steps:

(1)
Identify the attribute to be learnt.

(2) Identify the set of predictive attributes, that is the set of attributes that are somehow responsible of
defining the value of the attribute. Usually a preprocesing (filtering) is needed in order to se
lect them.

(3) Obtain many instances of interaction data where the attribute to be learned and the predictive
attributes are involved.

(4) Try different machine learning algorithms and select in each situation the algoritm that gives the best
response, or

a combination of them.

The
Modelling

subsystem provides only the infrastructure and the communications with the rest of the
Adaptation module, but the information provided is not relevant, at the moment. The reason for this is that up
to now there are not

relevant data to test the machine learning algorithms. After the experiences with the 2
nd

prototype during the evaluation process in the different pilot sites, these data will be obtained an thus, the
modelling subsystem will be completed.


5.6

MultiAgent Pe
dagogical Model (MAPM)

The multiagent pedagogical model (MAPM) contributes to the
second prototype

of the ALFANET system
providing instructional design and learning design (LD) specification support to course development. It
presents a set of instructional

design (ID) guidelines for concept learning, which are transformed into a IMS
LD template. Concept learning is selected because of the following reasons: a) it is a representative example
of instructional design practice, being one the most used design le
ssons; b) it is based upon a considerable
amount of experience collected from ID research and practice; and c) it is the simplest but also the basic
component of each type of design, including forming of complex skills. Each of the courses in the ALFANET
s
ystem should deal at a certain point of the development process with an introduction of a particular concept
and its relationships to other concepts.

The concept learning template applies to two types of cases: concept definition and concept classification
.
The template further defines three properties of learner’s individual characteristics. They are: a) level of
knowledge, with two values: beginner and advanced; learning style being inductive and deductive; and c) two
types of perceptual modality


visual

and verbal. For each case three basic types of activities are organized.
They are presentation, practice and feedback. The concept learning template is a generic one as different
versions are possible on the basis of combinations of its components. Curr
ently two interpretations of the
concept learning template are applied to the courses ‘Introduction to communication technologies’ (Open
University, Netherlands) and ‘Spanish for beginners’ (Klett, Germany). In the course ‘Introduction to
communication te
chnologies’, Presentation is given in two ways


inductive and deductive, to matches the
learning style’s property values. Practice assumes QTI testing. Depending on results, two types of actions are
possible. If the test outcomes are favorable, learner ge
ts additional material. If a learner does not reach the
required level, then two remediation options are suggested. They reflect the perceptual modality values of
visual and verbal. In the ‘Spanish for beginners’ a pre
-
knowledge test score determines what
lesson a learner
should begin with. There are two types of presentations. They are inductive/visual and deductive/verbal,
reflecting two possible combinations of learning style and perceptual modality. Practice includes QTI testing
to check whether the le
arner achieved the required level. If not, remediation activities are planned. They are
followed by a QTI
-
re
-
testing.


5.7

Audit module

5.7.1

Situation

In the
first prototype
, the focus was on: 1) the investigation and development of the technology needed, 2)
the de
velopment of a general software architecture and 3) the development of a set of basic functionality's
from which we could test the technology and general architecture. To limit the complexity, the first prototype
Page
24

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

was build as a stand
-
alone application: all

input data was supplied as test files. The data for the request call
as well as the output data satisfied the DTD agreed by the Consortium.

This
second prototype

extends the first prototype. The focus in the second prototype is on: 1) the technical
integr
ation of the audit module in the audit system, and 2) the development of some more relevant reports
that support the auditing Alfanet of the learning environment.

5.7.2

Aim of this prototype



To develop a set of relevant analysis and corresponding reports which
can be used during the second
pilot.



To integrate the audit module in the audit system, so that the input and output data is carried out via the
dispatcher.

5.7.3

Description of functions of the second prototype

In this second prototype we have implemented som
e use cases with the tutor as main user. The
corresponding reports are showed in the next table.


Reportnr.

Parameters

Explanation

0

--

Dump internal database

1

Course ID

Lists the learners that have studied a specific course

2

Course ID, learner ID,
a
ctivity ID

Calculate the number of study hours for a combination of:
course, learner and activity

3

Activity ID

Calculate the mean study time of a certain activity

4

Activity ID

Calculate the mean value of the absolute value of the
difference between:

-

th
e planned study
-
time of the activity

-

the actual study time of the activity

for the activity (mean over all learners)

5

Course ID

A list of all activities used for the course over all learners and
the number of accesses over all learners.




Report zero

is
a report for the system developer and/or maintainer. The database content as part of the
audit module can be showed to be able to inspect the correctness and completeness. The function call
doesn't need any parameter.



Report one

delivers a list of all lear
ners that have studied and/or study a specific course. The function
parameter is the ID of the course.



Report two
delivers the number of study hours for a combination of a certain course, learner and activity.
The function parameters are the ID's of: the c
ourse, the learner and the activity of interest.



Report three
delivers the mean study time of an activity over all learners that have studied this activity.
The function parameter is the ID of the activity.



Report four
delivers the mean value of the (absol
ute) difference between 1) the planned study
-
time and
2) the actual study time of this activity over all learners who have studied this activity. In other words this
analysis compares the actual study
-
times of all learners to the planned (i.e. expected) ti
me. The function
parameter is the ID of the activity.



Report five

delivers a list of all activities used in the course together with the number of accesses over
all learners of each activity. The function parameter is the ID of the course.



Deliverable 4.2


Second System P
rototype

Page
25

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

Remark on repor
ts three and four
An activity could be used in more than one course. If we want to know
the mean study time of an activity in the context of a certain course, the course ID should be a function
parameter too. The code can easily be extended for this extra
choice
-
option.

5.7.4

The audit system architecture

In the following figure the architecture of the audit module is shown. On a conceptual level nothing has
changed in the audit module in architectural terms with respect to the first prototype. New with respect t
o the
first prototype is the interface between the dispatcher to: 1) receive the report number asked and the
corresponding data, and 2) give back the report data asked for.

reportRequest
JAXM-SOAP
auditService
dispatcher
user requests
a report
user views
the report
auditService
reportStructure
getData
API
reportResponse
JAXM-SOAP
apiData
reportDetails
internalDatabase
analysisBox
reportData
auditPlots


The process flow is as follows:

1.

Via the dispatch
er a XML
-
based request is send to auditService module. Based on this the caller is
asked about the data needed. At the same time the modules reportStructure and apiData are informed
about the report asked.

2.

The apiData module receives the data needed and p
ut it in the internal database. The database is a
collection of events (more on that later).

3.

The reportStructure module asks for report details which are produced by the analysisBox.

4.

After the report details are ready, the report is transmitted to the dis
patcher in XML format.


Page
26

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

Remark
As can be seen in the figure the interfaces are based on JAXM
-
Soap technology.

Remark

As in the first prototype no data are persistent between calls to the audit module. For every request a
standard set of data is fetched in
and stored temporarily in the internal database of the audit module


To be able to produce the reports, information is stored in the database in the form of events which are
derived form the traces in the tracker module. An event can carry data about: a co
urse, a learner, a learning
activity, an adaptive advise, a QTI, a learning object, an activity structure. An event can also present changes
in cognitive modality of a learner, the level of knowledge of a learner, the learning style of a learner, learner.

5.7.5

The course for the second pilot

For the second pilot a module with title 'Continues signals' is prepared. The module is a part of the existing
course Communication technology, Architecture and applications. The module is adapted according to the
didactic m
odel (inductive/deductive concept learning) as part of the Alfanet MAPM project track.

The module ‘Continues signals’ consists of:



An introduction and learning objectives



A set of learning objects with a recommended sequence.



Tw QTI’s (one after the induc
tive/deductie part and one after the remediation part)

There are two types of learning objects:

1.

In the first phase a learner gets (according to his/her learning style) an learning object of type inductive or
deductive. After this the students fills in a QT
I.

2.

In the second phase, the student follows a visual or a verbal learning object. The visual learning object is
chosen in the case of remedial teaching and consists of two animations. The verbal learning object
consists of extra subject material (the stude
nt doesn't need remedial teaching). This phase is closed with
a QTI.


The subject material is in part authored with the Alfa
-
authoring tool.

As part of the ultimate version, based on this course, a more complex audit analysis/report will be developed.


5.8

Int
eraction module

The Interaction Module
provides the different services that allows the learners to perform a course in the
system. It is based on an open source API called OpenACS
4

not to start from scratch, but new code is being
added to OpenACS to adapt
it to the specific requirements of Alfanet.

The Interaction Module provides services three different environments: the personal area (workspace), the
course area and the activities area. The personal area provides an integrated vision of the services and
c
ontents the user has access in the different courses s/he is enrolled, and the contributions performed in
them. The course area provides the services that have to be used each course, both if they were specified at
design time by the author or at run time
by the tutor. The activity area is similar to the course area, but under
the scope of an activity inside the course (some activities may require additional and specific services to be
performed, such as collaborative activities).

For the
first prototype
, i
t were implemented the functionality to manage several services. We have focused
on the forums and file
-
storage services, but calendar, notifications, comments, news and FAQ’s services are
also available for the first prototype. The communication with the
rest of the system is via the Dispatcher, as
defined in the D21. The Dispatcher sends http requests to the different services and the Interaction Module
sends html pages (without headers) back to Dispatcher, so the Presentation Layer can create the final p
age
that will be shown to the user.





4

http://openacs.org


Deliverable 4.2


Second System P
rototype

Page
27

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

For the
second prototype

two main functionalities have been implemented:



The service of Ratings, for allowing the valuation of the learning items.



The XML output of some pages in order to facilitate the adaptation of
presentation.

Moreover other additional functionality is:



The automatic publication of the course in the Interaction Service environment.



The generation of events in order to sincronize variables with the rest of the system.


5.9

Content Server

The content ser
ver delivers different resources (learning objects) from their respective identifier.

The
First Prototype

included a first version is in charge of serving contents stored in the application
repository identifying the content type and taking the correspond
ing action according to it.

Internally, the module performs a control of the user session, so that when a user asks for a resource that
has been previously served, the resource is provided from disk instead of generating a query to the Data
Base.

The
Secon
d Prototype

includes the serving of contents information. This information is extracted from the
course package manifest where the contents can be described. The Content Server is in charge of
indentifying the requested content and the search of the corres
ponding meta
-
data in the repository.

5.10

Common repositories

The Common Repositories refer to the development of the Object model for the ALFANET application, the
implementation of the data model on a physical level, and the development of the methods for upda
ting and
retrieving information from the common repositories.

The
first prototype

includes a first version of the Common repositories including:



Data Access layer

The data access layer has been developed by using the JCA (J2EE Connector Architecture) archi
tecture,
thus providing connectivity between ALFANET services and the data layer and providing independence
from the physical implementation of the DataBase. The Tamino Resource Adapter implementing the JCA
standard has been used. This layer includes the m
ethods to access the different items defined at the
Common Repositories.



DataModel Physical Definition

The Alfanet DataModel for the first prototype has been defined in the XML Database with the following
schemas:

-

CSO: Schema for Non XML Content

-

learnerinf
ormation: IMS
-
LIP (Learning Information Package)

-

learning
-
design: IMS
-
LD

-

lom: LOM (Learning Object Model)

-

manifest: IMS
-
CP (Content Package)



qtilite:
IMS
-
QTI (Question and Test Interoperability) lite specifiaction

The original schemas of the IMS standard
have been accomodated for Tamino XML Server (it doesn’t
support group references and documents with namespaces prefix)

The
second prototype
, includes the following add
-
ons:



Data Access layer

WebDav access

to store the data generated by the Authoring tool
into the ALFANET Data Server, and
maintaining security issues that relate the ALFANET server (which is available to users for testing
Page
28

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

purposes). A new version of Tamino WebDav Security 4.1.5. was installed in ALFANET servers.
Additionally an upgrade of Tam
ino XML server was done. Current version is Tamino XML Server 4.1.4.
After configuring the system, the different tests performed assured the secure access to a external user.

LOM Retrieval
. The Content Server incorporates a new API that retrieves the LOM d
escription
coorresponding with an object. This API will be used by the Adaptation module to retrieve metadata
information relevant to the different objects conforming the course.



DataModel Physical Definition

Related with the physical definition of the Dat
aBase, the following schemas have been defined:



category
, will provide support to taxonomies that will be used by adaptation tasks.



trace
, will support the traces generated by the tracker, and later used by adaptation modules.



ui_preferences
, will support
preferences of users regarding the presentation layer.



templates
, will support different alternative presentation templates.



questestinterop:
IMS
-
QTI (Question and Test Interoperability)



An

extended LIP
shema has been defined to take advantage of attribute
s already defined in LIP
standard, and in turn use the flexibility provided by LIP to incorporate new attributes. These new
attributes are being used by the adaptation module that determines the User Model.


Deliverable 4.2


Second System P
rototype

Page
29

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

6.

Authoring tool

The Authoring Tool is an independe
nt application of the
Alfanet

LMS prototype and its objectives are to
provide an easy and user friendly interface to create and edit courses for the Alfanet System.


Alfanet module for the 2
nd

prototype

Developer

Authoring tool

ACE
-
CASE


The Authoring To
ol has four feature modules:



Manage Global Resources


This module allows the user to have a centralized way to edit
resources that he wants to use and reuse several times in several courses.

This is implemented in a folder oriented philosophy that means
that the user may organize the
resources in different folders for different kinds of resources;



Manage Global Metadata


This module allows the user to have and edit metadata templates that
can be used and reused in several courses.

This is implemented in

a file oriented philosophy that means that the user may organize the
different templates in different files;



Learning Editor


This is the core module of the Authoring Tool. This module allows the user to
create and edit course that will be published in t
he Alfanet LMS.

This module is organized in a similar way to the Learning Design specification with some
adaptations to be more friendly and understandable to the user.

This organization wraps the different concepts of the Learning Design that have somet
hing in
common in sub
-
modules to be more intuitive and conceptually organized to the user.

This module also allows creating interchange files that follow the IMS CP standard, which intend to
create a standard way to transfer course files;



Repository Inter
face


This module is the module that allows the integration with the Alfanet
Repository and communicates with it via WebDav protocol.

This integration is intended to facilitate the transfer and publishing of the courses edited in the
Authoring Tool.

This

is an applet that runs an WebDav communication application that supports almost every
features allowed by the WebDav protocol;

The Authoring Tool for the
first prototype

supported only the edition of Level A of the Learning Design. For
the
second prototy
pe
, the Authoring Tool supports the edition of Levels A, B and C of the Learning Design.

The support of IMS LearningDesign Conditions (Level B) will not include the complexity of expressions as
operands, considering its complexity and considering that it
would be very difficult for course designers to use
it.



Page
30

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

7.

System requirements

This chapter identifies the main system requirements that are identified at the moment of delivery the first
system prototype. This requirements could be updated in the next prot
otypes.

7.1

Server requirements

The application have been developed using JBoss as application server. This is not a restriction, since in
principle, it could be migrated to a different one. But development and tests have been done with JBoss
version 3.2.1.

Be
sides, the application modules are using Tamino XML Database v.4.1.1.1, for storing the ALFANET data.

7.1.1

Course Manager and IMS
-
LD Interpreter

Specific requirement for these modules in the first prototype is the Microsoft SQL Server 2000, that is used
for sto
ring the courses information once these courses have been published. For the second prototype this
requirement not applies. The database used now is Postgress.

7.1.2

Learning tool

On the server side the OpenACS suite is needed because the Interaction Module is b
uilt upon it. The
requirements for OpenACS (we are using OpenACS 4.6.2) are the following:

Hardware requirements:



256 MB RAM



4 GB hard drive


Software requirements:

Operating System:



OpenACS is designed for a Unix
-
like system. It is developed primarily in
Linux, although it can be
run on Mac OS X, and in Windows within VMWare. For the prototype, we are running it on Linux
(Linux kernel of 2.4.14 or newer).


Web Server.



OpenACS uses AOLserver as web server to handles incoming HTTP requests, provide a runtime

environment for OpenACS's tcl code, connect to the database, send out HTTP responses, and
log requests and errors. Currently we are using AOLserver 3.3.


Database.



OpenACS separates the database with an abstraction layer, which means that several differen
t
databases function identically. Currently OpenACS fully supports PostgreSQL 7.2 and Oracle
8.1.7. While you can run the core OpenACS on any supported database, not all contributed
packages support all databases. Currently we are using PostgreSQL 7.2.3. P
ostgreSQL is
written for Unix
-
like operating systems, and a modern Unix
-
compatible platform should be able to
run PostgreSQL.


More information can be obtained here:
http://alfanet.ia.u
ned.es/doc/individual
-
programs.html


7.1.3

Agents requirements

The system requirements of Adaptation Module related to the Agents part are the common requirements to
its components: Theo and Jade.



Jade requirements:

The only software requirement to execute the
system is the Java Run Time Environment version 1.2


Deliverable 4.2


Second System P
rototype

Page
31

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288



Theo:

They are basically Lisp libraries of classes that provides the framework to the inference mechanism used
in the Adaptation Module. Thus, a lisp environment is needed.



DataBase:

The Adaptation module

uses PostgreSQL to store the agents internal data. PostgreSQL is written for
Unix
-
like operating systems, and a modern Unix
-
compatible platform should be able to run PostgreSQL.
So far it has been tested with the following
5
: AIX, BSD/OS, FreeBSD, HP
-
UX, I
RIX, several
configurations of Linux, MacOS X, NetBSD, OpenBSD, Solaris, Tru64 UNIX, UnixWare.

Nevertheless, the C client library (libpq) and the interactive terminal (psql) can be compiled natively under
Windows. If you are using Windows 98 or newer you
can build and use all of PostgreSQL "the Unix way"
if you install the Cygwin toolkit first. But we haven't tested it in Windows.

For this prototype, we are running it on a Linux machine with RedHat distribution. Besides, the Adaptation
Module is running i
n a UNED server.

7.1.4

JAXM Services

Regarding the JAXM Interface implementation for the Adaptation Module, the JAXM library and the web
services associate (e.g. SAAJ) are needed. It is running in JBoss.


7.2

Client requirements

There are different main interfaces f
rom the end
-
user point of view. Depending on the user profile, we can
distinguish: editor tool, administration tool, and learning tool (for tutor and learners).

7.2.1

Editor tool (ACE
-
CASE will identify the application requirements)

The tool was developed based
on a peer
-
to
-
peer application called Groove Workspace. For more information
please visit the following page:
http://www.groove.net
;

The tool has the following installation requirements:

Operating System:



Microsoft® W
indows® 98



Microsoft Windows ME



Microsoft Windows NT® 4.0 (with Service Pack 5 or later)



Microsoft Windows 2000



Microsoft Windows XP (Designed For)

Note:

With the release of Groove Workspace 2.0, Groove no longer supports Microsoft
Windows 95.

Hardware R
equirements:



Intel® Pentium® processor, 400 MHz or higher



128 MB RAM for Groove Workspace, 2
56 MB RAM for synchronizing a Groove® Mobile
Workspace with a Microsoft® SharePoint™ site.



100 MB free disk space, with additional space required for your data.



Display resolution 800 x 600, 15
-
bit (32,768) colour minimum

Software Requirements:



Microsoft
Internet Explorer version 4.0 or later required, version 5.5 or later recommended.



Internet Explorer 6.0 or later required to use the Groove Forms Tool, Groove Mobile
Workspace for Microsoft® SharePoint™ or Groove Web Services.




5

http://www.postgresql.org/docs/current/interactive/supported
-
platforms.html

Page
32

Deliverable 4.2


Second System Prototype


ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

Internet Connection:



56 kbp
s modem minimum
-

LAN (local area network), DSL, or cable modem preferred.


7.2.2

Questionnaires tool

The first prototype analyses the QTILite standard for the questionnaires and tests interpretation.

Second prototype supports Question and Test Interoperabilit
y Specification v1.2. Since the current
application does not provide any tool for facilitating to the author the questionnaires creation, it is
recommended that the author uses any existing tool in the market (some of them are available in the web).
Canvas

Learning Author tool was proposed in order to design items according to IMS Question and Test
Interoperability (QTI) specification.

7.2.3

Administration tool

This tool will be launched from a browser. In principle, this tool won’t have any special requirement
.

7.2.4

Learning tool

This tool will be launched from a browser. In principle, this tool won’t have any special requirement.




Deliverable 4.2


Second System P
rototype

Page
33

ALFANET

Active Learning for Adaptive Internet

IST
-
2001
-
33288

Appendix 1

Bibliography


D21 General System Architecture and Design. (January, 2004). European Communities, Fifth Framework
Information Society T
echnology program. ALFANET project (IST
-
2001
-

33288)

D41. First System Prototype (February, 2004). European Communities, Fifth Framework Information Society
Technology program. ALFANET project (IST
-
2001
-

33288)