A MODELING LANGUAGE FOR COLLABORATIVE LEARNING

EDUCATIONAL UNITS

Supporting the Coordination of Collaborative Activities

Manuel Caeiro-Rodr

ıguez

Departamento de Enxe

ner

ıa Telem

atica, University of Vigo, C/ Maxwell S/N, Vigo, Spain

Keywords:

Modeling, Collaboration Support, Computer-supported Collaborative Learning, Educational Modeling Lan-

guage.

Abstract:

This paper introduces a modeling language to support the computational modeling of collaborative learning

educational units. The languages supporting the computational modeling educational units are named as Ed-

ucational Modeling Languages (EMLs). EMLs have been proposed to facilitate the development of complex

and large e-learning applications. The introduced language is proposed as an EML specially oriented to-

wards collaborative learning. A main goal is to enable the modeling of the variety of ways in which human

interaction can be supported (e.g. well-structured and ill-structured, synchronous and asynchronous, strict-

coordination and free-collaboration). To do it, a separation of concerns approach is followed. The proposal,

named as Perspective-oriented EML (PoEML), involves several parts (named as perspectives) where all the

modeling issues are arranged and separated. The paper introduces the ideas and constructs of the main PoEML

perspectives towards the modeling of the variety of forms for collaboration support.

1 INTRODUCTION

This paper introduces an Educational Modeling Lan-

guage (EML). EMLs (Rawlings et al., 2002) (Koper,

2001) have been proposed to facilitate the develop-

ment of e-learning solutions. The EML introduced in

this paper is specially focused on supporting the mod-

eling of collaborative learning educational units. Col-

laborative learning comprises a broad range of edu-

cational practices that take advantage of human inter-

action in order to achieve more effective and efﬁcient

learning (Dillenbourg, 1999). In practice, collabora-

tive learning educational units may be arranged in ac-

cordance with different structures (e.g. a discussion-

based lecture, a group-based workshop, a brainstorm,

a cooperative project) and using different collabo-

ration schemes (e.g. synchronous or asynchronous,

strict-coordination or free-collaboration, face-to-face

or distance). The goal is to support the computa-

tional modeling of collaborative learning educational

units taken into account this variety of structures and

schemes. To do it, the proposal follows a separa-

tion of concerns approach. The key idea is to de-

compose the modeling of educational units in several

concerns. For example, participants awareness and

authorizations can be modeled as different concerns.

The modeling of awareness is concerned with the way

in which events produced during education have to

be processed and notiﬁed to appropriate participants

(e.g. learners’ actions have to be notiﬁed to a teacher).

The modeling of authorization is concerned with the

assignment of permissions to participants (e.g. learn-

ers and teachers have different permissions to use the

functionalities of a simulator). The concerns identi-

ﬁed in this proposal are named as perspectives and the

proposed language is named as Perspective-oriented

EML (PoEML).

Next section introduces the PoEML separation of

concerns proposal . Then, section II describes the

PoEML constructs of the main perspectives devoted

to support the collaboration requirements. The paper

ends with some conclusions.

334

Caeiro-Rodríguez M. (2007).

A MODELING LANGUAGE FOR COLLABORATIVE LEARNING EDUCATIONAL UNITS - Supporting the Coordination of Collaborative Activities.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 334-339

DOI: 10.5220/0002373503340339

 SciTePress

2 A SEPARATION OF CONCERNS

EML PROPOSAL

This section introduces a separation of concerns pro-

posal to support the modeling of collaborative learn-

ing educational units. This modeling involves many

different requirements that need to be satisﬁed, spe-

cially the several collaboration modes. To do it, the

whole modeling problem is decomposed into several

parts (named as perspectives) grouping and separat-

ing the various modeling concerns. Then, each per-

spective may be modeled separately while abstracting

from the concerns considered in other perspectives.

The idea of this approach was taken from the

workﬂow patterns project (van der Aalst et al., 2003)

(Russell et al., 2004). This separation of concerns

approach has already been applied to the evaluation

of EMLs expressiveness and suitability(Caeiro et al.,

2005). As a result 12 perspectives have been identi-

ﬁed.

2.1 Perspectives

This section introduces the perspectives by situating

them in the Activity Theory mediation model (c.f. ﬁg-

ure 1. The Activity Theory is a meta-theory about ac-

tivities and their constituent components (Engestrom,

1987). Considering that any educational unit can be

conceived as a set of activities, the Expanded Media-

tional Model provided by this theory is an interesting

framework. The core of this model is that any activ-

ity involves a subject (e.g. a person), represented by

a role, that acts in an object to achieve a certain goal.

This connection is mediated by the environment and

the community where the activity is performed. In

other words, the activity depends on the environment

and on the community. The environment contains the

tools and resources that can be used by the subject to

act on the object. The community puts the empha-

sis in the social context where the subject operates.

The rules component highlights the fact that within

a community, subjects are bound to rules and regula-

tions that affect the way they interact in the activity

(including also the interaction with the environment

and its elements). The division of labor refers to the

decomposition of the goal into sub-goals and the dis-

tribution of responsibilities among the available sub-

jects, producing as consequence new activities.

The Expanded Mediational Model has guided the

identiﬁcation of 12 perspectives:

1. Structural. It is concerned with the arrangement

of the rest of the elements into well-structured and

self-contained components. The structure consid-

ered is based on the activity concept. Educational

Environment

Role

Object

ACTIVITY

Rules

Authorization

Awareness

Interaction

Community

Division of Labour

Subject

Goal

Environments

Tools

Organizational

Order

Temporal

Participants

Goals

Structural

Causal

Figure 1: Proposed perspectives in accordance with the Ac-

tivity Theory Expanded Mediation Model.

units are conceived as a set of activities that pro-

vide the basic structure to group all the other ele-

ments (goals, actors, environments, etc.).

2. Goals. It is concerned with the goals that have to

be satisﬁed in educational units. These goals indi-

cate the work that has to be performed by partic-

ipants (e.g. learners and teachers). For example,

a goal can be ”to perform the basic transistor cir-

cuit” or ”to comment a newspaper article”. These

goals are different from learning goals that refer

to a desired knowledge, skill or capability. This

perspective involves the featuring of goals con-

sidering goal aggregations and specializations, the

mandatory or optional character of a goal, etc.

3. Participants. It is concerned with the participants

involved in the educational unit. Participants are

not ﬁxed in the models indicating speciﬁc per-

sons. Instead, roles that represent the desired par-

ticipants are indicated. This perspective consid-

ers the speciﬁcation of roles (e.g. learners, teach-

ers), groups (e.g. a discussion group made up by

a ”moderator” and several ”learners”); the assign-

ment of participants to roles and groups; etc.

4. Environments. It is concerned with the environ-

ments where the educational unit has to be per-

formed. An environment is made up by artifacts

(data elements) and tools that can be used by par-

ticipants. For example, a lab environment is made

up by several simulators, documentation about the

simulators operation, etc.

5. Tools. It is concerned with the applications and

services(e.g. simulators, editors, communication

and collaboration services). These applications

and services are situated in the environments. To

facilitate the reuse of the educational unit mod-

els, tools are not ﬁxed during the design, but they

are described in an abstract way. During run-time

tools provided by different vendors that satisfy

such description can be used. It is similar to the

A MODELING LANGUAGE FOR COLLABORATIVE LEARNING EDUCATIONAL UNITS - Supporting the

Coordination of Collaborative Activities

335

distinction between roles and participants.

6. Organizational. It is concerned with the organi-

zational structure required to carry out an edu-

cational unit. This information may be used to

constrain the behavior of other perspectives. For

example, the assignment of a teacher to an eval-

uation activity may depend on his/her position in

the organizational structure.

7. Order. It is about the order in which activities are

intended to be performed. It indicates if activities

have to be performed in sequence or parallel, to

set synchronization points, etc.

8. Temporal. It is concerned with time speciﬁcations

(e.g. temporal indications and constraints). It can

be used to decide when an activity must be initi-

ated or ﬁnished. For example, to indicate that a

lab practice has to be initiated at 14:00 and that it

has to be ﬁnished in 2 hours. Separating tempo-

ral and order issues in different perspectives it is

possible to consider order without temporal spec-

iﬁcations, and vice versa.

9. Authorization. It is concerned with the access

rights of participants to environments’ elements,

mainly to the tools’ functionalities. For exam-

ple, a simulator may provide two different permis-

sions: ”Expert” and ”Novice”. Teachers may be

assigned the ”Expert” permission while learners

are assigned the ”Novice” one. In collaborative

scenarios it is usual that different participants have

different authorizations.

10. Awareness. It is concerned with the processing

of runtime information (events) and the notiﬁca-

tion of relevant situations. For example, in many

educational units it is very important that teach-

ers be aware of learners’ actions. Nevertheless,

as important as providing awareness it is not to

overload the recipient (e.g. the teacher) with too

much information. Therefore, in order to give

to the right participant the appropriate informa-

tion and to avoid information overload, awareness

should be focused, customized, and temporally

constrained (Baker et al., 2002).

11. Interaction. It is concerned with the invocation

of operations in tools. Many of the controls re-

quired to support collaboration among a group of

participants involve the invocation of operations

in collaborative tools at certain time points (from

the Temporal perspective) or as result of events’

occurrences (from the Awareness perspective).

12. Causal. It informs participants about why they

should perform an educational unit.

3 POEML META-MODEL

PoEML (Perspective-oriented EML) is an EML ar-

ranged in several packages reﬂecting the separation

of concerns introduced in the previous section. This

section describes some of the main packages of the

PoEML meta-model centering on those more relevant

for the modeling of collaboration. For each package

an UML diagram showing the elements involved and

the relationships among them is included.

3.1 The Structural Package

The structural package enables to represent the

”skeleton” of educational unit models. This ”skele-

ton” is made up by the core concept underlying this

proposal: the ”activity”. Nevertheless, this concept

has not been named as ”activity”, because it is an

overused term and it can produce confusion. Instead

”activity” the term Educational Scenario (ES) is pre-

ferred. There are several reasons: (i) in the common

”activity” conception the goal is the more important

component and the participants and the environment

play secondary roles, but in PoEML these three com-

ponents have the same relevance; (ii) the term ”activ-

ity” is usually related with closed speciﬁcations con-

straining the actions of participants, but many times

educational activities are established in open ways

(e.g. to do an inquiry about the consequences of the

second world war); and (iii) the ”activity” concept

seems not appropriate to reﬂect the hierarchical orga-

nization of educational units (e.g. a course composed

by modules and modules by lessons, a lab practice or-

ganized in several phases).

Therefore, the ES is the core element to com-

pose the structural skeleton of educational unit mod-

els. From a conceptual point of view, an ES represents

a complete piece of education with a speciﬁc learn-

ing goal. It can be used to represent educational unit

models at different levels of abstraction, from sim-

ple lessons to complete curriculums. From a practical

point of view, any educational unit model involves ex-

actly one ES where a hierarchical structure of aggre-

gated ESs is situated. In other words, an ES (named

as Root ES) is composed by other ESs (named as Sub-

ESs or Children ESs). In addition, these Sub-ESs can

be composed by other ESs. The rest of PoEML ele-

ments are connected at the ESs directly.

Figure 2 illustrates the ES and its main constituent

elements. As it is represented an ES element in-

volves an aggregated structure relating: (i) its own

decomposition into Sub-ESs; (ii) a Goal (or set of

Goals) that need to be satisﬁed; (iii) a participant

or set of participants (speciﬁed as Roles) that have

ICEIS 2007 - International Conference on Enterprise Information Systems

336

to work towards the Goals achievement; (iv) one

or several Environments where participants have to

work, composed by Artifacts (from the Data pack-

age) and (v) Tools that represent applications and

services; and optionally (vi) a certain Organization-

alStructure that situates participants in an organiza-

tion scheme; (vii) OrderSpeciﬁcations to indicate the

order in which the Sub-ESs are intended to be at-

tempted; (viii) TemporalSpeciﬁcations to indicate or

constraint the moment at which each Sub-ES has to

be initiated and ﬁnished; (ix) AuthorizationSpeciﬁca-

tions assigning permissions to participants for the use

of resources; (x) AwarenessSpeciﬁcations indicating

how events should be processed and notiﬁed to partic-

ipants; (xi) InteractionSpeciﬁcations with constructs

that enable the performance of automatic operations;

and (xii) Records containing descriptions of compe-

tencies, learning objectives, pre-requisites, etc.

Tools

Participants

Goals

Organizational

Order

Temporal

Authorization

Awareness

Structural

Tool

Interaction

Environment

0..*0..*

AwarenessSpecification

Goal

AuthorizationSpecification

Organization

InteractionSpecification

TemporalSpecification

OrderSpecification

Role

EducationalScenario

1..*

0..*

1..*

0..*

1..*1..*

0..*

Environments

0..*

Causal

Record

0..*

Figure 2: The EducationalScenario. element and its main

components.

3.2 The Authorization Package

The Authorization package includes elements to

model speciﬁcations for the management of permis-

sions and their assignment to participants. This is

supported by the modeling of Authorization Speciﬁ-

cations (AuSs) in accordance with the elements de-

picted in ﬁgure 3. An ES can involve zero, one or

several AuSs. An AuS relates one or several Roles

(indicated with the Role element of the Participants

package) with one or several CompositePermissions.

In addition, AuSs can be associated with a Choice-

Point to determine the application of the AuS in a de-

ferred way (e.g. if a condition is satisﬁed).

Structural

EducationalScenario

0..*

Authorization

Spectification

0..*

PermissionOperator

0..*

Participants

Role

0..*

0..1

Aspect

ChoicePoint

0..*

deferred

Negation Aggregation

Environments

SourceSelection

0..*

Composite

Permission

0..*

Tools

Permission

0..*

roleRef

Figure 3: Main elements of the Authorization. package.

The CompositePermission element enables to

specify the permissions of interest to be included in an

AuS. Many times permissions are not managed indi-

vidually, but they are aggregated into logical compo-

sitions (e.g. a ”moderator permission” with the ”mod-

erator permissions” of all the communication ser-

vices). The CompositePermission element enables to

indicate a single permission or a combination of sev-

eral permissions. PoEML adopts a Directed Acyclic

Graph (DAG) approach to support this speciﬁcation.

A CompositePermission is a rooted DAG where the

leaves of the DAG are basic permissions, the non-

leaves are permission operators, and the edges are

connections, i.e., permission streams. A Composite-

Permission speciﬁcation includes the following ele-

ments:

• The SourceSelection element from the Environ-

ments package enables to specify the particular el-

ement(s) on which the permissions will be granted

(e.g. a chat).

• Permissions. They are the PrimitivePermissions

speciﬁed in the Tools perspective. In addition to

the permissions offered by tools PoEML recog-

nizes permissions provided by DataElements and

Environments (view, read, write).

• PermissionOperators. PrimitivePermissions and

CompositePermissions can be combined to spec-

ify new CompositePermissions using these opera-

tors. PoEML provides two operators:

1. Aggregation. It allows to combine several per-

missions on several elements. For example: a

”moderator” permission on a conference tool

and a ”write” permission on DataElements.

2. Negation. It allows to withdraw a permission

(or set of permissions) on a certain element (or

A MODELING LANGUAGE FOR COLLABORATIVE LEARNING EDUCATIONAL UNITS - Supporting the

Coordination of Collaborative Activities

337

set of elements) from a CompositePermission

speciﬁcation.

3.3 The Awareness Package

The Awareness package is intended to capture timely

and relevant information about what happens during

education. Eventually, this information will be used

to notify participants (e.g. a teacher), to feed appro-

priate tools or to decide the performance of opera-

tions. To do it, PoEML enables to specify the way

in which events produced during the execution of an

educational unit should be processed and managed.

This is achieved by the modeling of AwarenessSpec-

iﬁcations (AwSs) (cf. ﬁgure 4). An ES can involve

zero, one or several AwSs. An AwS relates a Com-

positeEvent, with a Role (from the Participants pack-

age), with a Tool (from the Tools package) or with

a InS (from the Interaction package). In addition, an

AwSs can also be associated with a ChoicePoint to de-

termine the application of the AwS in a deferred way

(e.g. if a condition is satisﬁed).

Awareness

Specification

0..*

CompositeEvent

0..*

EventOperator

Filter Aggregation Correlation

0..*

0..1

Aspect

ChoicePoint

0..*

deferred

roleRef

toolRef

Environments

SourceSelection

0..*

Structural

EducationalScenario

0..*

Participants

Role

0..*

Interaction

InteractionSpecification

Tools

Tool

0..*

Tools

Event

0..*

Figure 4: Main elements of the Awareness. package.

The CompositeEvent element enables to specify

the events of interest to include in an AwS. Many times

participants in an educational unit are not interested

on a single event but on a combination of multiple

events. CompositeEvents enable to specify a single

event or a combination of a set of events. A tech-

nique is needed to detect occurrences of combinations

of multiple events. This has long been studied in the

active database ﬁeld where event algebras have been

proposed (Zimmer and Unland, 1997). More recently,

XML-based approaches used in distributed Web sys-

tems have also considered this problem (Bernauer

et al., 2004). PoEML adopts a DAG approach. A

CompositeEvent is a rooted DAG where the leaves of

the DAG are event producers, the non-leaves are event

operators, and the edges are connections, i.e., event

streams. A CompositeEvent speciﬁcation includes the

following elements:

• The SourceSelection element from the Environ-

ments package enables to specify the particular el-

ement(s) on which the events will be captured.

• Events. They are the PrimitiveEvents speci-

ﬁed in the Tools perspective. In addition to the

events produced by tools PoEML recognizes other

events: execution state of an ES, participants’

presence events, etc.

• EventOperators. PrimitiveEvents and Composi-

teEvents can be combined to specify new Com-

positeEvents using these operators. During execu-

tion, PrimitiveEvents will enter the DAG at their

associated leaves and ﬂow to the input slots of op-

erators connected to these leaves. PoEML pro-

vides three basic categories of EventOperators:

1. Filter. It allows selecting events of interest

based on the values of their parameters. In this

way, it is possible to select events related to: a

certain time interval; a certain participant; etc.

2. Aggregation. It is for summarizing events of

the same type. It allows to count the events pro-

duced.

3. Correlation. Event correlation addresses rela-

tionships among instances of different events.

The operators included are: conjunction, dis-

junction, concatenation, sequence, concurrency

and negation.

3.4 The Interaction Package

The Tools package enables to model the Tools that

should be included in Environments. The Interaction

package is concerned with the invocation of opera-

tions in such Tools. In this way, it is possible to spec-

ify control models: conference control, conversation

control, ﬂoor control, etc. This is supported by the

speciﬁcation of InteractionSpeciﬁcations (InSs) in ac-

cordance with the elements depicted in ﬁgure 5. An

ES can contain zero, one or several InSs. An InS in-

volve a structure similar to ECA (Event-Condition-

Action) rules.

• It includes an AwarenessSpeciﬁcation or a Tempo-

ralSpeciﬁcation to determine when to invoke the

operation.

• It can include a ChoicePoint to constraint the per-

formance of the operation.

• It includes an CompositeOperation that indicates

the operation(s) to perform.

The CompositeOperation element enables to

specify the operations that have to be invoked in an

ICEIS 2007 - International Conference on Enterprise Information Systems

338

Structural

EducationalScenario

0..*

Interaction

InteractionSpectification

0..*

CompositeOperation

0..*

InteractionOperator

Sequence

Parallel if-construct while

Awareness

AwarenessSpecification

0..1

0..*

0..1

Temporal

0..1

TemporalSpecification

deferred

Aspect

ChoicePoint

0..*0..*

0..*

Environments

Tools

SourceSelection

0..*

Operation

0..*

Tools

Figure 5: Main elements of the Interaction. package.

InS. Many times several operations have to be in-

voked in conjunction. The CompositeOperation el-

ement enables to indicate a single operation or a com-

bination of several operations. PoEML adopts a DAG

approach to support this speciﬁcation. A Compos-

iteOperation is a rooted DAG where the leaves of

the DAG are operations, the non-leaves are operators,

and the edges are connections, i.e., operation streams.

A CompositeOperation speciﬁcation includes the fol-

lowing elements:

• The SourceSelection element from the Environ-

ments package enables to specify the particular el-

ement(s) on which the operations will be invoked.

• Operations. They are the PrimitiveOperations

speciﬁed in the Tools perspective.

• OperationOperators. PrimitiveOperations and

CompositeOperations can be combined to specify

new CompositeOperations using these operators.

PoEML provides four operators:

1. Sequence. The included Operations have to be

performed in sequence.

2. Parallel. The included Operations have to be

performed in parallel.

3. If-construct. The included Operation have to be

performed if a certain ChoicePoint is satisﬁed.

4. While. The included Operation have to be per-

formed repeatedly while a certain ChoicePoint

is satisﬁed.

4 CONCLUSION

The work introduced in this paper has a twofold inter-

est. In the one hand, the application of the separation

of concerns design principle to the structuring of a

modeling language. In the other hand, the proposal

of a computational solution to support the modeling

of educational units. In conjunction, the paper intro-

duces an EML based on the separation of concerns

approach: PoEML. The proposal devotes a special at-

tention to the support of the variety of collaboration

modes that may be involved in collaborative learning.

ACKNOWLEDGEMENTS

We want to thank Spanish Ministerio de Educaci

on y

Ciencia for its partial support to this work under grant

MetaLearn: methodologies, architectures and lan-

guages for E-learning adaptive services (TIN2004-

08367-C02-01).

REFERENCES

Baker, D., Georgakopoulos, D., Schuster, H., and Cichoki,

A. (2002). Awareness provisioning in collaboration

management. International Journal of Cooperative

Information Systems, 11(1&2):145–173.

Bernauer, M., Kappel, G., and Kramler, G. (2004). Com-

posite events for XML. In Proceedings of WWW2004.

Caeiro, M., Anido, L., and Llamas, M. (2005). Towards

a benchmark for the evaluation of LD expressiveness

and suitability. Journal of Interactive Media Educa-

tion, (4).

Dillenbourg, P. (1999). What do you mean by collaborative

learning? In Dillenbourg, P., editor, Collaborative-

learning: Cognitive and Computational Approaches,

chapter 1, pages 1–19. Elsevier, Oxford.

Engestrom, Y. (1987). Learning by Expanding: an

Activity-theoretical Approach to Developmental Re-

search. Orienta-Kosultit, Helsinki, Finland.

Koper, R. (2001). Modeling units of study from a pedagog-

ical perspective The pedagogical metamodel behind

EML. Technical report, OUNL.

Rawlings, A., van Rosmalen, P., Rodr

ıguez-Artacho, M.,

and Lefrere, P. (2002). Survery of Educational

Modelling Languages (EMLs). Technical report,

CEN/ISSS Workshop on Learning Technologies.

Russell, N., ter Hofstede, A. H. M., Edmond, D., and

van der Aalst, W. M. P. (2004). Workﬂow data pat-

terns. Technical Report FIT-TR-2004-01, Queensland

University of Technology, Brisbane, Australia.

van der Aalst, W. M. P., ter Hofstede B. Kiepuszewski, A.

H. M., and Barros, P. (2003). Workﬂow patterns. Dis-

tributed and Parallel Databases, 14(1):5–51.

Zimmer, D. and Unland, R. (1997). The formal foundation

of the semantics of complex events in active database

management systems. Technical Report Tecnical Re-

port 22/1977, C-LAB, Paberborn Germany.

A MODELING LANGUAGE FOR COLLABORATIVE LEARNING EDUCATIONAL UNITS - Supporting the

Coordination of Collaborative Activities

339