Development of intelligent reusable learning

objects for web-based education systems

Ruben Peredo Valderrama, Leandro Balladares Ocana*, Leonid B. Sheremetov

Centro de Investigacion en Computacion—IPN, Unidad Profesional ‘Adolfo Lopez Mateos’, Del. Gustavo A. Madero,

Col. Nueva Industrial Vallejo, C.P. 07738 Mexico City, Mexico

Abstract

The research in WBE (Web-based Education) systems is centered in reusability, accessibility, durability and interoperability of didactic

materials and environments of virtual education. A special type of labeled materials called Intelligent Reusable Learning Components Object

Oriented (IRLCOO), producing learning materials with interface and functionality standardized, rich in multimedia, interactivity and

feedback is described in this paper. The structuring model for dynamic composition of these components is based on the concept graph

knowledge representation model. The multi-agent architecture as a middleware for open WBE systems is developed for sequencing and

delivery of learning materials composed of IRLCOOs.

q 2004 Published by Elsevier Ltd.

Keywords: WBE; Intelligent reusable learning components object oriented; Intelligent components; Agents

1. Introduction

A basic problem faced by the learning community is

how to produce and deliver quality content for online

learning experiences, being able to compose, revise and

update this content in an efficient way. This arise the

issues of interoperability (content from multiple sources

working equally well with different learning systems) and

reusability (content developed in one context being

transferable to another context), which are imperative

to the sustainability of the work on WBE (Steed, 1999;

Veen, Collis, Santema, & Genang, 2001). Without them,

(a) anyone with a significant investment in either content

or a learning system is locked into that particular content

or system; (b) every time a course, or an interactive

electronic training manual needs to be updated, the

material must be rewritten; (c) the process of developing

high-quality content is prone to unnecessary duplication

of effort, driving up the cost, possibly past what

0957-4174/$ - see front matter q 2004 Published by Elsevier Ltd.

doi:10.1016/j.eswa.2004.09.003

* Corresponding author. Tel.: C52 55 57296000x56611; fax: C52 55 24

0140.

E-mail addresses: peredo@cic.ipn.mx (R.P. Valderrama), ballad@

cic.ipn.mx (L.B. Ocana), shere@cic.ipn.mx (L.B. Sheremetov).

the market will bear (Reusable Learning Object Strategy

Definition).

That is why research in the field of WBE is centered

on reusability, accessibility, durability and interoperabil-

ity of didactic materials and learning environments. To

this end, there are also several organizations working

toward standards to get content labeled in a consistent

way (using XML language and metadata which is like a

bar-coding system) and to make sure learning content is

‘interoperable’ with various learning management tech-

nologies. The main initiatives are the following: the

Open Knowledge Initiative (OKI) of the MIT, the

Advanced Distributed Learning (ADL) initiative and

the Global IMS Learning Consortium (Advanced Dis-

tributed Learning Initiative; Global IMS learning con-

sortium; Open Knowledge Initiative). The IMS develops

open technical specifications to support distributed

learning. These specifications form part of standards

and tools that are developing in the framework of the

ADL’s Sharable Content Object Reference Model

(SCORM) (Advanced Distributed Learning Initiative).

Nevertheless, a number of open questions still exist, most

of them in the implementation of interactive learning

resources with flexible schemes of sequencing, tailored to

individual learner needs and available whenever and

Expert Systems with Applications 28 (2005) 273–283

www.elsevier.com/locate/eswa

R.P. Valderrama et al. / Expert Systems with Applications 28 (2005) 273–283274

wherever. For instance, the delivery order in the SCORM is

not yet based on learner information; it is fixed for each item

at the design stage. Another difficulty at the moment is that

there is still no consistent way for learning materials to be

labeled or tagged effectively (making them difficult to

search). The efficient middleware schemes for content

search, aggregation, and delivery are under investigation

and development.

In Sheremetov and Peredo Valderrama (2002), we

discussed a special type of labeled materials called

Intelligent Components of Programmable Reusable Soft-

ware extending the capacity of Learning Interactions (LI) of

Flash of Macromedia. In Sheremetov and Uskov (2002), we

have defined the generic layered agent architecture for

Learning Management System (LMS). In this article, we

show how these approaches can be integrated. On the one

hand, Intelligent Reusable Learning Components Object

Oriented (IRLCOO) are described, a special type of

Reusable Learning Objects (RLO) producing learning

content rich in multimedia, interactivity and feedback. On

the other, a multi-agent architecture for IRLCOO sequen-

cing, retrieval and delivery using the generic architecture

and the Component Agent Platform (CAP) is described.

The rest of the article is organized as follows. In Section 2,

the concept of RLO is introduced. In Section 3, the model of

IRLCOO and its communication with the LMS are

described. Section 4 describes (i) the model based on

concept graph formalism and developed for structuring

of IRLCOO along with (ii) the authoring tool, called

IRLCOO Factory, for the composition of learning materials.

In Section 5, an extension of these ideas towards the

agent architecture is presented, with the emphasis on the

communication and sequencing management. Finally,

conclusions are discussed.

2. Reusable learning objects

While speaking about learning recourses, learning

contents and activities also can be exposed as components

permitting this way to generate compound learning

experiences. Online learning content typically contains:

materials explaining the concepts, a navigation scheme,

assessments and collaboration tools as well as other

interactive and graphical elements. To be learning content,

the content should also be aware of learners. At a minimum,

learning content should recognize who the learner is and

record information about the learner’s experience. To make

this possible, learning content has generally been developed

in conjunction with some sort of LMS that keeps track of

learners. As the learners interact with the content, results are

passed back to the system. The content can also change its

behavior based on learner information stored in the system:

learners might be sent to different places in the content

based on test scores, language preferences, learning style

inventories, competencies, certifications, organizational

roles, and other data.

RLO or Shared Content Objects (SCO) according to the

SCORM terminology represents an alternative approach to

content development (Reusable Learning Object Strategy

Definition). Learning objects are self-contained learning

components that are stored and accessed independently.

RLO is any digital resource that can be reused to support

Web-based learning. Examples of RLOs may include live or

streaming or prerecorded video or audio, a course module,

animations, graphics, Web-based applications, Web pages,

PDFs; documents Office; and other pieces that are aimed to

deliver complete experiences, such as a lesson. From a

pedagogical perspective, each RLO might play a specific

role within an instructional design methodology. Learning

objects can be re-assembled to create new courses or

sequenced to form individual learning paths. The key issues

are: (i) each RLO must be able to communicate with

learning systems using a standardized method that does not

depend on the system, (ii) a sequencing system (usually

forming a part of the LMS) defines the navigation rules for a

learner to move between RLOs, (iii) each RLO has a

description that enables designers to search for and find the

right RLO for the right job. This has clear benefits. It

enables mass-customization of learning with more person-

alized and ‘just for me’ content. And for authors, there is the

opportunity to search for existing learning objects from

within the organization or from external providers and reuse

them, saving time and money.

There have been some examples of learning environ-

ments, such as for example, LiveBOOKs developed by the

Computer Systems Group of the University of Waterloo that

include ideas of reusable objects in their development to

facilitating the creation and maintenance of electronic

courses (Cowan, 1998). Within the EVA project we have

also explored a number of working models and tools for

development of structured learning materials and their

delivery (Sheremetov & Guzman Arenas, 2002; Sheremetov

& Quintero, 2001). In EVA, these materials are located in the

knowledge space, which is composed of knowledge domains

represented as a set of ‘Multi-books’ (or POLIlibro, in

Spanish), personalized electronic books generated by

concatenating selected items (RLOs) along the learning

trajectory for each knowledge domain. While developing

learning materials, one of the issues we have addressed is the

development of interactive learning resources providing

learner’s feedback. We call these units RLCOO and will

describe them in more detail in the following section.

3. From RLO to intelligent components

In software engineering, a component is a reusable

programmed building block that can be combined with other

components in the same or other computers in a distributed

network to form an application. More specifically,

R.P. Valderrama et al. / Expert Systems with Applications 28 (2005) 273–283 275

a component is a piece of software reusable in binary form

you can connect to other components with relatively little

effort (Eddon & Eddon, 1998). Examples of a component

include: a single button in a graphical user interface, a small

interest calculator, an interface to a database manager. A

component operates within a context called a container and

can be deployed different servers in a network and

communicate with other for needed services.

3.1. RLCOO

Applying these ideas to the development of RLO,

Macromedia’s Flash components have been used as the

basis of content elements in the format of the Reusable

Learning Components (RLC) (Macromedia). Flash already

has Smart Clips for the learning elements denominated LI,

so, the original idea was to generate a library of RLC for

WBE. Different templates for RLC as well as for the

programmable buttons with Smart Clips and Clip Par-

ameters interface were generated, for example, generic

buttons for audio, video, exams, charts, etc. The interfaces

were stored as swf files in a static way. New learning

templates also were created to add the functionality or to

improve the existent one. To load components, a new

mechanism was generated based on the integration of

loadVars, loadMovie and loadMovieNum. The liberation of

ActionScript version 2.0 inside Flash MX 2004 allowed

redefining the RLC to Reusable Learning Components

Object Oriented (RLCOO), allowing implementing the

paradigm object oriented, besides allowing containing

Fig. 1. Basic classes’ diagram of RLC

certain common functionalities inside of the Application

Programming Interface (API) like: communication with the

LMS, communication with the Agents and dynamic load of

Assets in Run-Time.

As we see later, this mechanism is also used to provide

communication of the RLCOO with the LMS. A general

scheme of the RLCOO with their classes and load dynamic

de Asset is show en Figs. 1 and 2, respectively.

3.2. Intelligent RLCOO

A new type of components, called IRLCOO, was

developed for the advanced templates, adding nonlinear

feedback from the users and the functionality of dynamic

component generation for the auto-configurable labeled

materials. A general scheme of the IRLCOO with nonlinear

feedback is shown in Fig. 3.

For the nonlinear feedback, a small Neural Network

(NN) of the Bidirectional Associative Memory (BAM) type

was used. The NN is composed of two layers, identified by

two groups of neurons {a1,a2,.,an} and {b1,b2,.,bn}. The

n!p generated connections, conform a correlation matrix,

represented by W (Partida, Peredo, & Cordova, 1995):

W ZXm

k

ATk Bk

This matrix is generated by means of the vectors AZ{a1,a2,.,an} and BZ{b1,b2,.,bn}, being A the input

vector that can be composed of different factors that a

teacher wants to measure, as for example: time, score

OO written in ActionScript 2.0.

Fig. 2. RLCOO general schema with dynamic load of asset.

R.P. Valderrama et al. / Expert Systems with Applications 28 (2005) 273–283276

and number of intents; while the vector B represents the

output or feedback that the student will receive in function

of the input vector A (Fig. 4).

This NN was programmed as a part of IRLCOO. Since

in Flash, two-dimensional matrices do not exist, one

dimensional matrix was used adding some logic to work

appropriately. For the IRLCOOs used as assessment items

Fig. 3. The general schema of IRLC

(as shown in Fig. 4), the evaluations can be carried out in two

different ways:

1.

OO

By means of IRLCOO generated with fixed parameters,

setting the first component in a Web page, loading the other

ones by means of loadMovie or loadMovieNum and after the

last question is answered calling the evaluation Servlet JSP.

with dynamic feedback.

Fig. 4. An assessment IRLCOO of the drag and drop type (before and after evaluation).

R.P. Valderrama et al. / Expert Systems with Applications 28 (2005) 273–283 277

2.

By means of generating of IRLCOO with dynamic

parameters obtained from the LMS database. The weight

matrix is built at the moment the IRLCOO is loaded in the

browser, recovering the input and output vectors obtained at

the training phase and stored in the LMS. The values to be

measured are also returned with different feedback IRL-

COOs associated with them by means of an engine of

dynamic sequencing.

The second mode requires communication between the

IRLCOO and LMS using the API with the Run-Time

Environment (RTE). In this manner, a dynamic sequencing

is generated in function of the student’s interaction with the

materials and his/her evaluations.

3.3. Communication between (I)RLCOO and LMS

The common implementation of this model is in

an asynchronous RTE (browser-based delivery) and one

where a content object initiates all communication. As

depicted in Fig. 5, a content object and the LMS implement

communication adapters in the content object’s RTE.

In the case of the Flash (I) RLCOOs, this adapter is

based on the use of loadVars function code to commu-

nicate Flash objects with the LMS. This way, the

component incorporates the capability to discover and

communicate with a communication adapter. Through the

communication adapter, the LMS returns the requested data

or a message identifying an error condition or that the

request cannot be honored. While running, content also

sends state information for storage across sessions (IEEE;

Sheremetov & Uskov, 2002).

As an example, a code fragment written in ActionScript

version 2.0 from the (I) RLCOO shown in Fig. 4 to get the

student’s name and to store the student’s score as follows:

var studentName Z “!”;

Fig. 5. Learning content ECMAScript API model (adopted from (IEEE)).

var lmsStudentNameZLMSGetValue(“cmi.core.

student_name”);

if (lmsStudentName !Z“ “)

{

studentNameZ“ “ClmsStudentNameC“!”;

}

doContinue(“completed”);.

.

scoreCC;

if (lmsInitializedZZtrue)

{

LMSSetValue(“cmi.core.score.raw,”Cscore);

}

If a static sequencing is used, the standard sequence engine

called sequencingEngineDynamic.jsp, obtains the ID of the

last used (I) RLCOO, and searches for the following (I)

RLCOO to be retrieved from the RecordSet of the sequence by

means of the following SQL query:

String sqlSelectUserSCOZ“SELECT* FROM UserS-

COInfo WHERE UserIDZ? AND CourseIDZ? ORDER

BY Sequence”;

For a dynamic sequencing, a new engine called

sequencingEngineDynamic.jsp was developed generating

R.P. Valderrama et al. / Expert Systems with Applications 28 (2005) 273–283278

an SQL query in a dynamic fashion and modifying the

student’s trajectory in function of the variables included in the

output vector of the NN.

4. Content aggregation

To create a collection of learning resources, according to

a logical structure, involves, among other things, to

organize the learning resources into a hierarchy. Our

conceptual model assumes that all learning experiences

(learning content and content resources) can be represented

as a concept graph (Sheremetov & Guzman Arenas, 2002).

The concept graph encodes the definition model that

defines the expected behavior and that is used to identify

the next activity.

4.1. Structuring of RLCOO

The concepts at any level of abstraction (courses, chapters

or topics) and relations between them (uni- and bi-directional,

in general) correspond to the nodes and arcs of the graph,

respectively. Each node i has a number of attributes, including

its weight (node ratio) that means the importance to achieve a

final goal of learning, knowledge constraints (prerequisites)

and estimated time to learn the concept. The definition model

specifies rules and conditions that control sequencing and are

associated with each node. A precedence relation i/j is used

to relate concepts, which mean that concept ‘i’ has to be

learned directly before the concept ‘j’. Knowledge constraint

attribute captures a prerequisite relation k/j that means that

concept ‘k’ is needed to learn the concept ‘j’, but not

necessarily precedes it. Each arc (i, j) also has its weight

(relation ratio) that means the strength of relationship or the

necessity of the previous concept for the next one. All the

ratios are estimated from ‘not necessary’ to ‘obligatory’ and

are represented using a five-valued numeric ranking scale from

0.2 to 1. To capture the fact that it can be necessary to learn

two or more concepts to proceed with the next one, AND arcs

are used.

The concept graph has the following two layers associated

with it.

Fig. 6. A structure of a compound

†

lear

Content graph. Content resources to learn concepts may

include simple static Web pages, MIME resources of any

type (e.g. DOC, PDF files), services and proxies for

services, and dynamically created objects. For example, in

the context of this article we emphasize the use of RLCOOs

as content objects.

†

Activity graph. The activities and sub-activities are

represented by activity nodes. Activity is a procedure

intended to elicit learning through the use of a learning

resource. The rules and conditions are applied to the

activity graph to create learning experiences. The model

assumes that different activities are related to the same

skill, competency, or proficiency. For example, one

activity may teach a skill, and another may test whether

the skill has been acquired. Yet another activity may

provide an alternative instructional approach for the skill

to be used as remediation, if the normal approach fails.

Conceptually, a set of state-data items is associated with

each node in the activity tree for each learner. An LMS

uses the state model to record the learner’s experience

with the activity, which in turn is used in identifying the

next activity and its content resource to be delivered, as

shown in the previous section.

In the first versions of EVA, the RLOs were organized by

means of a specific structure with the chapter representing the

lowest level of content granularity tackled by EVA. The

composition of the RLO of different multimedia objects was

static. The proposed structure is based on the idea of a

compound learning item as a collection of Reusable Learning

and Information Atoms (RLA and RIA, respectively)that are

grouped together to teach a common task based on a single

learning objective (Vladimir & Maria, 2003) (Fig. 6). An RLA

is an elementary non-dividable piece of learning that is built

upon a single learning objective. Each RLA can be classified

as either being a concept, fact, process, or procedure. Each

RLA combines three types of content objects, specifically: (1)

content component (pieces of learning), (2) practice com-

ponent (learning activities), and (3) assessment component

(tests, quizzes, and exams).

On the other hand, an RIA is an elementary no divisible

piece of information that is built upon single information

objective. It may contain up to seven different content items,

ning item with RLCOOs.

R.P. Valderrama et al. / Expert Systems with Applications 28 (2005) 273–283 279

such as: (1) overview, (2) introduction, (3) importance,

(4) objectives, (5) prerequisites, (6) scenario, and (7) outline.

The Summary RIA may contain several content items such as

(1) review, (2) next steps, and (3) references/links/ additional

knowledge resources. Using these components in order to

convert the collection of components into a complete ‘learning

experience’—a compound learning item, four other types of

RIA specifically, Welcome RIA, Overview or Introduction

RIA, and Summary RIA, are developed using RLCOOs and

added to a set of RLAs.

Though the LIs originally are focused exclusively on the

evaluations, completely new RLCs have been developed to

generate interactivity for the didactic multimedia as well.

4.2. Authoring (I) RLCOO

Once we have components and models for their structuring,

development of easy-to-use authoring tools put in the hands of

subject matter experts, is imperative to the success of the

WBE. In this way, knowledge can be packaged and distributed

very quickly. During the development of the didactic materials

for EVA, it was decided to develop templates of the

components and an authoring tool, called (I) RLCOO Factory,

to facilitate their deployment, since many teachers are not

experts in handling of multimedia tools. We have developed

the Structurer and Packer of content multimedia using the (I)

RLCOO as the lowest level of content granularity. The

integration of the (I) RLCOO and content aggregation is

carried out on the base of the concept graph model that allows

generating materials at different granularity levels. It is

Fig. 7. RLC factory

important to mention that the RLCOO and IRLCOO are

basically Active X components.

The (I) RLCOO Factory is used to construct Web-based

courseware from the stored (I) RLCOO and also to enhance

the courseware with various authoring tools. Developers can

select one of the Factory Web-enabled lesson templates and

specify the desired components to be used in each item.

The (I) RLCOO Factory will automatically populate each

item page with the RIA and RLA, and automatically adds

Table of Contents and navigation links. Commercial

authoring tools, such as Macromedia DreamWeaver can

be used to create new interactive activities to further

enhance the courseware and even for content delivery in

the case of a desktop multimedia application. The visual

interface of the authoring tool contains different ‘views’,

each one in its own window. As it can be seen in the

Fig. 7, these views contain the hierarchic logical structure

of the content package, the content graph view of the

package, RLA and items (called grouping) among others.

A metadata tool allows to generate RLCOO and

IRLCOO to generate on-line courses allowing to measure

metric of the students, to be able to personalize its learning

experience, besides offering an interface and functionality

consistent, besides is used to generate specifications of the

RLC and learning items compatible with the SCORM 1.2.

Metadata are the specific descriptions of the component and

its contents, such as title, description, key words, learning

objectives, item type, and use rights. The metadata tool

provides templates for entering metadata and to store each

component in the Factory or other IMS/IEEE compliant

repositories. XML specifications are generated while

screenshot.

R.P. Valderrama et al. / Expert Systems with Applications 28 (2005) 273–283280

labeling and structuring didactic materials as the output of

the tool. XML is considered as a language of specification

of components and of graph coding that allows the

generated components to be compatible with the EDUCO-

M/IMS compliant RTE.

Fig. 8. Agent-based architecture of the WBE system.

5. From (I) RLCOO to agents

New generation WBE systems should be based on

standard, completely open middleware (the software that

users do not see, but that is the key to openness and

continued innovation through competition). Its role is to

broker the communication between system entities enabling

clients to request a service without knowing where or how

that service is implemented. This flexibility will become

even more important because the WBE architecture will be

a heterogeneous mix of cooperative, intelligent devices

located in the home, at the factory, in public places, and at

the office. Distributed computing middleware must do most

of the ‘thinking’ for the users. Thus, clients will become

very thin, the intelligence will reside in the network, and

most applications will be network centric.

Being a step forward from traditional two-tier client-server

architecture, the communication scheme between the

(I) RLCOO and LMS presents many difficulties. First, the

front end of the communication, API is embedded in

the (I) RLCOO as a Jscript code. It reduces the flexibility of

the component. Also, to work correctly, communication

adapter must always be present and initiated. Another

drawback of this scheme is the difficulty to implement

interactions between distributed components, though inter-

application communication is the key issue of the distributed

object and component paradigms. Sure, loose-coupled fixed

interactions occur when, for instance navigation buttons are

embedded into the component’s body. Usually, the semantics

of these interactions is to switch the control loci between

components within the content aggregation. The fscommand

used initially was changed for loadVars for not having to use

javascript for flexibility the communication of the components

with the LMS.

To make the communication scheme more flexible, open

WBE systems must be developed over an open middleware.

This middleware can be implemented based on the distributed

object or agent paradigms. In this section we illustrate the later

approach because agents can be considered as one of the most

promising technologies to implement the intelligent middle-

ware (Sheremetov & Uskov, 2002). At present, there is still

much debate (Franklin & Graesser, 1997), and little consensus,

about exactly what constitutes agent hood. However, an

increasing number of researchers find the following

characterization useful (Wooldridge, 1997; Jennings, 2000):

An agent is an encapsulated computer system that is

situated in some environment and that is capable of flexible,

autonomous action in that environment in order to meet its

design objectives. There are a number of points about this

definition that require further explanation. Agents are:

†

clearly identifiable problem-solving entities with well

defined boundaries and interfaces;

†

situated (embedded)in a particular environment-they

receive inputs related to the state of their environment

and they act on the environment;

†

designed to fulfill a specific purpose-they have particular

objectives (goals) to achieve;

†

autonomous-they have control both over their internal state,

over their own behavior and over the decision on the

selection of the particular behavior; this is probably the key

point differentiating agents from objects and components;

†

capable of exhibiting flexible problem-solving behavior in

pursuit of their design objectives-they need to be both

reactive (able to respond in a timely fashion to changes that

occur in their environment)and reactive (able to act in

anticipation of future goals).

Agents physically reside in the environment called Agent

Platform (AP). AP is responsible via its components (manage-

ment system, directory facilitator, and communication chan-

nel) for providing management functions (registering,

deregistering agents, searching for the services exposed by

agents, etc.) and communications between agents residing

within the same or different platforms. All the communication

is realized at the knowledge level (communicating agent’s

intentions and goals) using Agent Communication Language

(ACL) (FIPA, 2001).

In the Section 5.1, we describe how sequencing and

(I) RLCOO delivery can be implemented in a multi-agent

environment running over the FIPA compliant CAP (Sher-

emetov & Contreras, 2001).

5.1. Communication between agents

In this architecture, agents are embedded in the applications

running both at the client and server (modeling the

functionality of the LMS) sides and implemented as programs

in Visual Basic.NET (Fig. 8). Each one of these applications

R.P. Valderrama et al. / Expert Systems with Applications 28 (2005) 273–283 281

contains an agent based on an ActiveX control, by means of

which communication among the applications is supported. In

the case of a client, this agent is called Personal Assistant (PA)

and in the case of a server, Sequencing Agent (SA). These

agents inherit the functionality of the BasicAgent of the CAP.

The SA agent has an API to manage the RLOs repository

(DB), implementing ‘sequence’, ‘retrieve’ and ‘delivery”

services.

Hosting embedded ActiveX agent, client’s application has

the following additional components. Its essential part is a

browser invoked as a COM server that is used to visualize the

RLCOOs. Another component of the client application is an

XMLDOM object to manipulate the (I) RLCOOs required by

the user. The interaction between the user and the RLC is

provided by the client’s GUI.

When the user requests an (I) RLCOO, through some

event or control of the user’s interface, the client’s agent is

activated and it generates a FIPA-ACL message (generally

using the ‘request’ performative) which is sent to the

corresponding LMS’s agent. LMS is composed of a set of

(distributed) SAs, each of them controlling a particular

domain of the knowledge space defined by the concept

graph. Directory Facilitator agent of the CAP is used to

locate the corresponding SA according to the request. An

SA opens a thread for each conversation. When the

requested (I) RLCOO is found, this agent returns the object

to the client’s agent (using FIPA-ACL ‘inform’ performa-

tive with the XML file in the ‘content’ parameter). Once

the client agent has received this message, it processes the

‘content’ parameter with XMLDOM and shows the RLO in

the embedded browser.

The methods to manipulate the content of the RLO need to

access the fields of the agent’s XMLDOM object to extract

parameters from the DB or to store the information. The same

functions of the communication API are used (as shown in

Section 3) as follows:

public function doLMSGetValue(field as String)

set nodoModoZxml_root.selectSingleNode(field) doLMS-

GetValueZnodoModo.text

end function

public sub doLMSSetValue(field as String, value as String)

set nodoCampoZxml_root.selectSingleNode(field)

nodoCampo.textZvalue

end function

The fields that are used in the program and that are part of

the (I) RLCOO such as ‘cmi.core.lesson_mode’, ‘cmi.core.

lesson_status’, ‘cmi.core.exit’, etc. are transmitted as a part of

actions requested by client’s PA. RDF representation scheme

is used.

5.2. Agent management of sequence processing

SA implements the sequencing scheme similar to that of

IMS Simple Sequencing (IMS, 2002), which will also be

included in the future release of the SCORM (v1.3).

Conceptually, sequencing is defined in terms of four indepen-

dent but related SA’s services that operate under a control

scheme: Navigation Interpreter, Sequencing Process, Delivery

Process, and Rollup Process. The main advantage of the use of

these processes as services is that, actually they can be called

independently by the client agent (using ACL’s request

message). It is up to the agent’s decision to check all the

service conditions and to deliver it to the client or not.

In its simplest form, SA has to map navigation events to

learning activities and their associated content resources for

delivery to a learner. It accepts navigation events as inputs. As

output, it identifies the next activity and its content resource to

be delivered. The source of the navigation event is the

navigation interface which is separated from the content

resource and is loaded within the client’s application. The

navigation interface captures event from the user interface,

determines if the event trigger is valid in the current context,

translates the navigation event into a sequencing request and

transmits it to the server’s agent in the content field of the ACL

message.

The main behavior of the SA is sequencing process.

According to the scheme described in Section 4, it resolves

a sequencing request into the identity of a particular node

of the activity graph. The content resource associated with

the node is delivered to the learner as the next content

object in the sequence. Sequencing requests include

those that specify movement through the content in the

activity graph (e.g. next or previous item in sequence),

branching to a particular node, and global requests (e.g.

start, exit).

The starting node is either the root node, the last node

delivered, or any enabled node. The process evaluates the

definition-model sequencing rules associated with the node

and uses values from the state model to identify the activity

and its content resource to deliver. The process may

traverse one or more nodes and paths in the activity tree to

determine the appropriate activity based on the sequencing

request, the definition model, and the state model.

It also validates that the identified activity and its content

resource can and should be delivered. For example, the process

evaluates limit conditions from the definition model to assure

that the activity is available. The resulting identification of the

activity is passed to the delivery service. This service is given

the identification of a node to deliver to the learner. The

identified activity’s content resource is delivered to the learner

specified within the XMLDOM object.

When delivery is completed, inform (Done) message is

received by the SA, which results in switching of its state to

idle waiting for events and requests while the learner interacts

with the RLCOO.

SA relies on tracking status information to enable dynamic,

conditional, sequencing behaviors. Activity graph can contain

an arbitrary number of aggregations of sub activities. The

process of determining the tracking status of a parent activity

based on the tracking status of the child is called rollup.

R.P. Valderrama et al. / Expert Systems with Applications 28 (2005) 273–283282

The rollup process takes place after a change in the tracking

status for any child of a node. Once the rollup process is

complete for a node, rollup continues for the node’s parent and

propagates toward the root activity. For example, the ‘score’ of

a sub activity (implemented as an (I) RLCOO) may contribute

to the total score of the parent activity (assessment). SA

performs rollups when the delivery of a content resource

terminates, if any tracking status information changed as a

result of this delivery and if the scope of navigation goes

beyond the immediate neighbors of the current node.

6. Discussion and conclusion

The RLCOO and IRLCOO allow an interface and

functionality common, programmable materials to be able to

carry out the dynamic sequence. IRLCOOs with a feedback

implemented by means of the BAM module allow to generate

components with the possibility of modification of its content

(static feedback), as well as of modification of the same

ActionScripts (dynamic feedback). This allows to specify and to

generate interactive, standardized, visually attractive learning

materials. The IRLC has the following advantages over the LI:

(i) an additional module of a BAM-type NN for nonlinear

feedback, and (ii) a possibility to work with the desktop

multimedia applications, as well as with the applications for the

Internet both with fixed parameters and those settled by the

middleware or read from the database.

A distributed model of the knowledge space composed

of RLCOOs integrates different topics into the common

framework. The development of this model is facilitated by

the authoring tool for specification and packaging of

learning materials and activities specified according to the

SCORM 1.2 standard. The use of the (I) RLCOO Factory

allows reducing in a significant way the time of

development of learning materials. For example, the

development of a Flash component takes approximately 2

weeks, while with the IRLCOO and the authoring tool; it

takes approximately 15 min to develop, to label and to

structure this component.

Agents are proposed to be used for the open middleware

implementation. Several technical advantages result from the

use of the AP: (1) agents of an application can be distributed

over the network; (2) a client does not know what machine, or

even what kind of machine, an agent (and content object as

well)resides on; (3) systems integration can be performed to a

higher degree; (4) the functionality of the learning components

can increase substantially (implementing different techniques

adopted to learning styles, different models of knowledge

representation, different interaction techniques) (Gordon &

Hall, 1998; Pe~na de Carrillo, Fabregat, & Marzo Lazaro,

2000; Sheremetov & Guzman Arenas, 2002). Agent archi-

tecture also has advantages enabling rich communication

schemes in different learning scenarios. The overall technical

goal of agent computing is clear: to advance distributed

information technologies so that they may be more efficient

and flexible.

At the moment, we are also working on how personal

technology assistants or smart agents (using metadata and

XML) can constantly search within the Web for new learning

objects that match exact interests and role requirements of the

user (learner or teacher). Coherent and compatible metadata

schemas for search and retrieval of learning objects including

retrieval by software agents are under development.

Acknowledgements

The authors of this article would like to thank the IPN and

CIC for partial support for this work within the projects:

20040858 and 20031441. The authors would like to acknowl-

edge all their colleagues and students participating in the

design and development of the software and learning materials

described in this article.

References

Advanced Distributed Learning Initiative, URL: http://www.adlnet.org.

Cowan, D. (1998). An object-oriented framework for liveBOOKs. Technical

Report, CS-98, University of Waterloo, Ont., Canada.

Eddon, G., & Eddon, H. (1998). Inside distributed COM. Microsoft Press.

FIPA XC00061. (2001). FIPA ACL message structure specification.

Franklin, S., & Graesser, A. (1997). Is it an agent, or just a program? In J. P.

Mueller, M. J. Wooldridge, & N. R. Jennings (Eds.), Intelligent agents III

(pp. 21–36). Berlin: Springer, 21–36.

Global IMS learning consortium, URL: http://www.imsproject.org/.

Gordon, A., & Hall, L. (1998). Collaboration with agents in a virtual world.

Proceedings of the workshop on current trends and artificial intelligence in

education. 4 world congress on expert systems, Mexico City, Mexico .

IEEE 1484.11.1, Working Draft 14, Draft standard for data model for content

object communication.

IEEE 1484.2, Draft standard for ECMAScript API for content to runtime

services communication.

IMS Simple sequencing specification (2002). Version 0.7.5 public draft

specification, IMS Global Learning Consortium, Inc.

Jennings, N. R. (2000). On agent-based software engineering. Artificial

Intelligence, 117, 277–296.

Macromedia, Inc., URL: http://www.macromedia.com/.

Open Knowledge Initiative, MIT, URL: http://web.mit.edu/oki/.

Partida, M., Peredo, R., & C’ordova, F. (1995). Simulacion de redes

neuronales, Memoria bidireccional bivalente adaptativa: BAM. Polibits,

1 (14), Ano VII (in Spanish).

Pena de Carrillo, C. I., Fabregat Gesa, R., & Marzo Lazaro, J. L. (2000).

WWW-based tools to manage teaching units in the PLAN-G distance

learning platform. Proceedings of the EDMEDIA 2000, world conference

on educational multimedia, hypermedia and telecommunications, AACE,

Montreal, 2000, Montreal.

Reusable learning object strategy definition, creation process and guidelines for

building, v3.1 Cisco Systems, Inc., URL: http://www.cisco.com/warp/

public/10/wwtraining/elearning/implement/rlo_strategy_v3-1.pdf.

Sheremetov, L., & Contreras, M. (2001). Component agent platform.

Proceedings of the Second International Workshop of Central and Eastern

Europe on multi-agent systems, CEEMAS ’01 , 395–402.

Sheremetov, L., & Guzman Arenas, A. (2002). EVA: An interactive web-

based collaborative learning environment. Computers and Education,

39(2), 161–182.

R.P. Valderrama et al. / Expert Systems with Applications 28 (2005) 273–283 283

Sheremetov, L., & Peredo Valderrama, R. (2002). Development of labeled

multimedia for WBT using SCORM. Proceedings of the IASTED

international conference CATE ’02, Cancun, Mexico .

Sheremetov, L., & Quintero, R. (2001). EVA: Collaborative distributed

learning environment based in agents. Proceedings of the world conference

ED-MEDIA 2001, Tampere, Finland, 2001.

Sheremetov, L., & Uskov, V. (2002). Hacia la nueva generacion de sistemas de

aprendizaje basado en la Web (towards the new generation of web-based

learning environments). Computacion y Sistemas, 5(4), 356–367 (in Spanish).

Steed, C. (1999). Colin steed web-based training. Gower Publishing Limited.

Veen, W., Collis, B., Santema, S., & Genang, R. (2001). Learner led learning

in an online community. Proceedings of the World Conference on ED-

MEDIA 2001, Tampere, Finland .

Vladimir, U., & Maria, U. (2003). Reusable learning objects approach to Web-

based education. International Journal of Computer and Applications,

25(3).

Wooldridge, M. (1997). Agent-based software engineering. IEE Proceedings

of the Software Engineering, 144(1), 26–37.