A review of schemes for modelling scripts

ugliestharrasΛογισμικό & κατασκευή λογ/κού

4 Νοε 2013 (πριν από 3 χρόνια και 10 μήνες)

97 εμφανίσεις

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


1






WP23
-

Mobile Support for Integrated Learning


Deliverable 23.
2
.
1

A review of schemes for modelling scripts




Authors: Baggetun, R., Barros, B., Fesakis, G., Girardin, F.,
Hoeksema, K., Hämäläinen, R., Miao, Y. & Vantroys, T. and the
members of the M
OSIL project



Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


2


1.
Introduction

................................
................................
................................
...................

3

2. Different approaches

................................
................................
................................
.......

4

2.1
Investigati
ng the capacity of IMS LD for formalizing collaborative Learning Scripts

............

4

2.2 Pedagogically annotated activity diagrams

................................
................................
....

7

2.2.1 The

maze script using the “Pedagogical Annotated Activity Diagrams”.

.......................

8

2.2.2 Concluding remarks

................................
................................
...........................

12

2.3
An approach to a learning proces
s modelling language covering CSCL needs

...................

12

2.3.1 Conceptual model of a collaborative learning script modelling language

....................

12

2.3.2 Co
nceptual vocabulary

................................
................................
.......................

14

2.3.3

Script modelling tools based on the presented modelling language

..........................

18

2.4

Scripted
Activities

Sketchpad

................................
................................
...................

20

2.
4
.
1

Model Description

................................
................................
..............................

21

2.
4
.
2

The maze script using the
Scripted Activities Sketchpad

................................
.........

22

2.
4
.
3

Concluding remarks

................................
................................
...........................

25

2.5
Active Document approach

................................
................................
.......................

26

2.5.1
Example with maze script

................................
................................
...................

27

2.5.4
Concluding remarks

................................
................................
...........................

28

2.6 Workflow approach of learning scenarios

................................
................................
....

29

2.
6
.1 Ex
ample with maze script

................................
................................
...................

30

2.
6
.
2

Comparison with other approaches and standards

................................
.................

31

2.
6
.
3

Concluding remarks

................................
................................
...........................

32

2.
6
.
4

The COW Platform

................................
................................
.............................

32

3. Conclusions

................................
................................
................................
..................

34

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


3



1.
Introduction

This deliverable (D23.3.3 “A review of schemes for modelling
scripts

”) is a result of MOSIL, a
one
-
year research collaboration among a group of European researchers within the Kaleidoscope
Network of Excellence on technology
-
enhanced learning. MOSIL is a jointly executed research
program to study learning approac
hes that rely on mobile support to integrate learning not only in
classrooms, but also workplaces, public spaces, outdoor spaces
-

the world in general.

The conceptual components and their relations of collaborative learning scripts have been
discussed in
literature (Dillenbourg
1
, Kollar et al
2
). However, a general modelling language for
formalizing CSCL scripts is still missing. Furthermore, there is no corresponding authoring tool for
CSCL practitioners to create, reuse, integrate, and customize CSCL scri
pts without a high
overhead of technical knowledge. As a first step in the direction of a CSCL scripting language we
investigate existing process modelling languages. So during MOSIL work several attempts have
been made to use existing standards (UML (stat
e charts, activity charts), IMS
-
LD and workflow
models (xpdl)) to express collaboration scripts.
Some are produced for the pedagogical domain,
while others are for software engineering. machine readable).

The most important attempt in the current discussi
on in this direction is IMS Learning Design (IMS
LD), a standard published by the IMS consortium based on the Educational Modelling language
(EML) developed by the Dutch Open University OUNL
3
. Although, during

the MOSIL work we found
out, that IMS
-
LD does
not cover enough (e.g complex groups). A second attempt is to use UML to
support scripting. Coming from the software engineering domain UML can be used to describe
learning activity models in order to use a common representation language. UML could offer w
ell
known representations like activity diagrams in order to express data and control flow during
collaborative learning activities. Furthermore activity diagrams could be probably modified in order
to give the correct abstraction level for the expression
of key pedagogical concepts that rise from
relevant research. Another approach to CSCL scripts is to enhance state charts to be able to
model e.g. collaboration between learners within different states of a learning process.

To contribute to the learning

needs and promote practical competence in designing we need more
powerful tools for collaboration, more expressive in order to describe collaboration scripts. To
meet those needs we created own approaches or extension to the LD. The approaches may also
be

used in different kind of purposes. For example for psychological purposes, pedagogical
purposes (such as; for teachers communicaton, sharing scenarios, activities, etc.) technological
purposes (machine interpretable in order to be able to generate comput
er supported tools to
mediate collaborative learning activies). In the second chapter we describe these approaches
modelling several variations of the maze script (see D.3: script collection).

In our approaches the mobility is part of the language.
The mob
ility is an aspect that is not
explicitly considered in the language, because the actual technology allows interaction with the
user in different devices.
Within our approaches we tried to consider different dimensions,
formality levels, perspectives, ro
les and groups, specification levels, resources and conceptual



1


Dillenbourg, P. (2002). Over
-
scripting CSCL: The risks of blending collaborative learning wi
th instructional design.
In P. A. Kirschner (Ed). Three worlds of CSCL. Can we support CSCL (p. 61
-
91).
Heerlen, Open Universiteit
Nederland.

2


Kollar, I., Fischer, F., & Hesse, F. W. (2003).
Cooperation Scripts for Computer
-
Supported Collaborative Learni
ng.
In B. Wasson, R. Baggetun, U.Hoppe, & S. Ludvigsen (Eds.), Proceedings of the International Conference on
Computer Support for Collaborative Learning
-

CSCL 2003, COMMUNITY EVENTS
-

Communication and Interaction
(pp. 59
-
61). Bergen, NO: InterMedia.

3


Koper, E.J.R. (2001). Modeling Units of Study from a Padagogical Perspective: the Pedagogical Meta
-
model behind
EML. Educational Technology Expertise Centre Open University of the Netherlands.

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


4


models. At their best, these approaches may
help educational
,
technical people and actual users
to understand each other

better. But many limits were also found, because l
earning processes are
so complex

and there are critical issues such as h
ow to visualise collaboration
.



2. Different approaches

While working with our approaches we found out that it is difficult to cover all the needs from
pedagogical perspective to technical implementation,
because in those cases the size of templates
will grow unusable. So we tried several different approaches (for different purposes). When
different attempts of visualisations are used “missing items” may be added to those. In this
document five different ap
proaches are introduced, examples of different approaches are shown
through the Escape the Maze
-
script (see figure 2) and possibilities and limitations are discussed.
In this chapter
first we will
discuss limits of IMS LD
. Second
p
edagogically annotated
a
ctivity diagrams

will be introduced. Third,

conceptual model, vocabulary and modelling
tools

of the collaborative learning scripts will also be introduced. Fourth we will describe the

Scripted
Activities
Sketchpad approach
. And
after that the
Active Docume
nt approach

will
be presented in terms of its components, detailing the model it uses to describe collaborative
learning activities. Finally we will introduce
a runtime engine (COW) to process XPDL files

(used for business process modelling)

with a pedagog
ical extension.



2.1
Investigating the capacity of IMS LD for formalizing collaborative
Learning Scripts

It is claimed that IMS LD can formally describe any design of teaching
-
learning processes for a
wide range of pedagogical approaches
4
. This modelling
language has strengths in specifying
personalised learning and asynchronous cooperative learning. However, IMS LD provides
insufficient support to model group
-
based, synchronous collaborative learning activities. Caeiro et
al. (2003) criticised IMS LD rega
rding CSCL purposes and suggested a modification and extension
of the specification
5
. This modification and extension is just restricted in role
-
part and method
part. Hernandez et al. (2004) suggested adding a special type of service, called “groupservice”

to
extend the capacity of IMS LD
6
. Such an extension at service level, rather than at activity level,
cannot appropriately capture the characteristics of collaborative learning activities.

In the following we are using a slight variation of the
maze
scrip
t (see D.1) as a reference
example:

First the teacher gives a short introduction about the structure of the learning task and then
divides the class (24 students) into 6 groups of four (activity 1). Toni and Darina form group 1
together with two other stud
ents. They can use a little LEGO robot in a physical maze and a



4


Koper, E.J.R. & Olivier.
B. (2004). Representing the Learnin
g Design of Units of Learning. Educational Technology &
Society. 7(3), p.97
-
111.

5


Caeiro, M., Anido, L. & Llamas, M. (2003). A Critical Analysis of IMS Learning Design. In Proceedings of CSCL 2003,
p.363
-
367.

6


Hernandez, D., Asensio, J.I., Dimitriadis,

Y. (2004). IMS Learning Design Support for the Formalization of Collaborative
Learning Flow Patterns. Proceedings of the 4th International Conference on Advanced Learning Technologies (Aug.30
-

Sep. 1, 2004, Joensuu, Finland), IEEE Press, pp.350
-
354.


Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


5


computer simulation with a robot in a maze. Toni and Darina are the “strategy developers” and
the other two students are the “maze builders” to test the strategies (so called rule sets).
Strat
egies and mazes can be stored on a central server (activity 2). Then each group in turn
presents their developed group results. As a group speaker Toni presents their first results
(activity 3). Now all groups are allowed to access the other groups work re
sults. The roles within
the group have switched, so Toni and Darina now are the “maze builders” trying to improve the
groups’ mazes so the other groups’ strategies will not help to escape out of them. Meanwhile the
other two students are working as the “st
rategy developers”. A competition has started to find out
which group develops the best strategies and mazes (activity 4). Finally the groups show their
achieved results (activity 5).

When using IMS LD to formalize collaborative learning scripts, we see s
everal major difficulties
and challenges:

Modelling groups

Modelling artefacts

Modelling dynamic features

Modelling complicated control flow

Modelling varied forms of social interaction

This will be discussed in more detail below by referring to the maze
script explained above.

1)

Modelling group work with IMS LD confronts with the problem how to model multiple
groups with the same role and the dynamic changes of groups. IMS LD enables to define multiple
roles, each of which can be played by multiple perso
ns. When investigating, we found that in
many cases the notation of “role” can be used to model groups for CSCL scripting. However, by
using IMS LD it is very difficult to specify how a group work pattern is assigned to several groups
working in parallel a
nd how sub groups can be defined within these groups (like needed in activity
2 and 4). If each group/subgroup is defined as a role, the designer has to define a list of roles
representing multiple groups (e.g., maze builder 1, …maze builder 6). The proble
m of this solution
is that the numbers of groups cannot be predicted at modelling phase. If only one role (e.g., maze
builder) is defined for all subgroups building mazes, then all persons who build mazes will be
members of the same role. The problem of th
is solution is the information about
groups/subgroups will miss and the run
-
time system cannot support inter
-
/intra
-
group
collaboration appropriately. In addition, in IMS LD the role members are assigned before running
a unit of learning and these assignme
nts keep unchanged within the life cycle of the run.
However, in some situations (e.g., in activity 1) groups are formed and group members are
assigned after the start of the process execution.
The difficulty of how to model groups is
(amongst two others)
also targeted in the section about the UNED scripting approach in this
report (see section 2.4.2)
.

2)

A second major difficulty while modelling CSCL scripts with IMS LD we see in modelling
artefacts. In learning processes, actors usually generate artefacts

such as a vote, an answer, or
an argument. In IMS LD, an artefact can be modelled as a property of a person or a role, which
creates the artefact. This property is used to record the outcome of the person and to support
personalised learning. In collabora
tive learning processes, an artefact is usually created and
shared by a group of people. It is normally used as a mediation to facilitate indirect interaction
among group members. It may be created in an activity and used in other activities like an
inform
ation
-
flow. For example, in the maze script the different sub groups produce, re
-
use and
improve rule sets and maze definitions. In order to support group interaction, an artefact should
have attributes such as type, status, created_by, creation_activities
, contributors,
consume_activities, current_users, and so on. By using IMS LD to model an artefact as a
property, one has to model all attributes of the artefact as properties as well. These properties
should be defined as a property
-
group with many restri
ctions. Such a complex definition cannot
be intuitively understood, it will be very difficult to model dynamic features even for technical
experienced designers, because the limited data
-
types of properties and many references make it
Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


6


very complicated
to h
andle artefacts. In addition, it is difficult to model a collective artefact,
because IMS LD does not support array
-
like data
-
types for a property. For example, it is
unpredictable how many rule sets are developed by a group in activity 2. Furthermore, an
artefact
as a maze definition may have a complex data structure and has to be handled by using specific
application tools. Since there is no explicit relation between artefacts and tools, IMS LD cannot
specify the relation between them.

3)

A third major di
fficulty while modelling CSCL scripts with IMS LD occurs when
modelling dynamic process aspects. IMS LD provides several elementary expressions (e.g., users
-
in
-
role and datetime
-
activity
-
started) and built
-
in actions (e.g., property operations,
hiding/show
ing entities, and notification) to model dynamic features of collaborative learning
processes. For modelling collaborative learning processes, more elementary expressions and built
-
in actions are needed. For example, during the first activity, the teacher
creates groups/subgroups
and assigns group members. Another example is that before the start of activity 4, the role
assignments to “rule set developer” and “maze builder” have to be exchanged. An example of
needed elementary expression can be found in act
ivity 3 “number
-
of
-
role
-
members” which can be
used as the up
-
limit of a loop control variable to model unpredictable times of presentation
performed by each working group in turn. At least, elementary expressions and built
-
in actions
concerning about newly

introduced notations like group and artefact should be extended.

4)

A fourth major problem is how to model complex process structures. IMS LD provides
play, act, role
-
part, and activity
-
structure to model structural relations at different levels.
Primaril
y linear structured learning/teaching processes with concurrently executable activities can
be modelled. However, as Caeiro et. al. (2003) pointed, the linear structure of a play with a series
of acts introduced a great rigidity while modelling network str
uctures. It is possible to model non
-
linear structural relations among activities by using conditions and notifications. The specification
of a collaborative learning process will become very complicated and confusing. In addition, it is
very difficult to
model a control flow associated with a complicated combination of process
instance thread splitting and synchronization. Such structures are inevitable in collaborative
learning activities.

5)

The last difficulty we want to stress in this paper occurs when

modelling varied forms
of social interaction. IMS LD uses a metaphor of a theatrical play to model learning/teaching
processes. A play consists of a sequence of acts and within an act there is a set of role
-
parts.
These role
-
parts are run together in para
llel. Role
-
parts enable multiple users, playing the same
or different roles, to do the same thing or different things concurrently on the same act. For
example, while each student reads the same article, the teacher prepares presentation slides. If a
group

of people performs a synchronous activity, IMS LS enables them to use a conference
service and provides no means at activity level to support collaboration. In collaborative learning
processes, it is quite usual that people with the same or/and different
roles perform a shared
activity through direct or indirect interaction. While making the joint effort, people with different
roles may have different rights to interact with other roles and the environment. In particular, it
can not be clearly modelled by
using IMS LD whether and how people collaborate, because people
may work in a variety of social forms: Individually, in an informal group, in sub
-
groups (e.g., in
activity 2), in a group as a whole (e.g., in activity 1), or in a community.

The criticisms
presented above can be consolidated by including the following:

IMS
-
LD is intentionally generic, not adhering to any underlying pedagogical theory, which, despite
it flexibility, lacks the tools for being tailored to such an specific theory

IMS
-
LD also lac
ks social structure, as it does not take into account the possibility of organising
users into groups and groups into societies, which is an essential feature for collaborative
learning. Thus, this proposal is unable to specity a collaborative and cooperat
ive division of labour
as carried out by a group

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


7


IMS
-
LD constitutes a reference model, which allows creating more specific instructional designs
complying with underlying pedagogical theories, though it’s too ambiguous as an instructional
modelling langua
ge

2.2 Pedagogically annotated activity diagrams

Activity diagrams are well known notation from the software engineering discipline. Activity
diagrams can describe data and control flow for software systems. The data flow is based on the
classes’ hierarchy

(UML static structure of the system). Arrows in the diagrams show objects flow
between the activities. Control flow can describe except of selection and/or repetition even
concurrent or parallel activities and their coordination. Activities can document t
he flow of
operations of a specific method of a class or the sequence of several classes methods call for the
implementation of a specific function that requires class collabo
ration.

Figure 1.
.

Activity diagrams are facing several problems for CSCL scrip
ting.


It is obvious that activity diagrams could be used as a basis for the development of a notation
system to describe pedagogical scripts. After some tests at least the following limitations and/or
inadequacies can be described (See
Figure 1.
):

For an
activity diagram to be specified a known number of classes (actors) is required. In other
words the number of swim lanes should be known. This is not possible or even necessary in the
PAIR2
Student2
Student1
teacher
Demostration of model RS transformation.
model development
Models : ModelsColection
model development
Models : ModelsColection
PHASE1: Teacher presents transformation
examples to the whole class[in case
that students have not recently worked
on this kind of transitions
among representation formalisms].
For example teacher can give (or mention) a
semi-quantitative model for a phenomenon and
then produce an equivalent quantitative one.
PHASE2: Each student tries alone to produce a
model in representation system R1 or R2
in order to give it to someone else for
transformation.
Individual work.
PROBLEM PLACE
M1R1 : model
MODEL TRANSFORMATION
M1R2 : model
PROBLEM PLACE
MODELS PAIR SUBMITION
[M1R1 IS EQUIVALENT TO M1R2]
M1R1 EQUIVALENCE M1R2 CHECK
[M1R1 IS NOT EQUIVALENT TO M1R2]
MODEL PAIRS : ModelsColection
EXAMPLES DISCUSSION
Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


8


case of pedagogical scripts where group size varies during the script. F
urthermore the social level
may change (individual
-

pair
-

group
-

whole class) during a script implementation.

The detailed pre
-
description of a human interaction during collaboration is rather very complex if
possible and may be unwanted if the purpose of
the script is to describe the formulation a learning
facilitating environment of collaboration.

For the facing of the above limitation it is possible to adjust the description in an abstraction level
where intensive human interaction is described as an at
omic activity that is assigned to (require)
many actors simultaneously. This means for example that a social negotiation activity should be
placed on a swim lane that is normally a syntax error in UML activity diagrams.

In activity diagrams a swim lane cor
responds to a class but for learning scripts a swim lane
corresponds to a role and a social level of organization.

Having in mind the above limitations it is possible to exploit basic ideas from activity diagrams in
order to describe learning scripts to te
achers and/or researchers in an informal way. More
specifically it is proposed to use activity diagrams with the following conventions:

The swim lanes will correspond to roles and/or social level.

The abstraction level of concentrated human interaction sho
uld be adjusted by well known
structured situations of collaborative learning (e.g. peer teaching, synthesis, negotiation,
apprenticeship etc).

The activity symbols should be annotated in order to code pedagogical rational information and
implementation h
ints.

The above convention aims to help the designer to document why she/he believes that the script
enhances learning except of simply use (mobile) technologies. The proposed approach is called
“pedagogical annotated activity diagrams”
. In the followings

the approach is applied to the maze
script.


2.2.1 The maze script using the “Pedagogical Annotated Activity Diagrams”.

As a first step for the description of maze script a pedagogical review of the script has been taken
place. In this review several poss
ible pedagogical questions has been produced for each phase of
the script using a brainstorming process. These questions indicate pedagogical information that
could be coded as annotation on the diagrams. The initial description of the script with the
ques
tions produced by brainstorming is in the following table.


Features

Script Name

Escape the Maze

Authors

M. Jansen, M. Oelinger, K. Hoeksema, U. Hoppe (University of Duisburg
-
Essen)

Reference

http://www.collide.info/modules.php?op=modload&name=publications&file=inde
x&req=getit&lid=61

Objectives

Algorithms to escape out of an arbitrary maze

“Reactive Programming by Example”

Algorithmic thinking

Target Audience

~K8

Context

Computer science

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


9


Locus of
representation

Mainly internal scripts necessary. Cooperation mode can be chosen by students,
method of work and how to distribute and work in virtual and physical
environment can be decided by studen
ts.

Granularity

Low. Most activities will happen in phases 1 and 3 and are only quite general
defined

Coercion
Degree

Low. Many decisions about how to work and cooperate can be made by the
students

Way of data exchange between groups is predefined by sys
tem (rule server)

Duration

4 hours

Environments

Physical maze / Lego Robot / control by PDA or Notebook / Virtual environment
with mazes and programmable robot / rule sets transferable

Design Principle

Competitive or collaborative Cooperation between De
veloper Groups

Experimental
Results

High motivation

StoryBoard

Phase 1

Groups building rule sets and mazes in physical and virtual environment

Phase 2

Presentation of results

Phase 3

Competitive or cooperative collaboration by following the tasks:

Tr
y to find a ruleset which enables a robot to escape out of the maze of another
group.

Try to find a maze which is to hard to escape for the robot acting according to a
rule set of another group.

Try to improve your/ another groups rule sets / mazes or merg
e old rule sets to
get a better one.

Phase 4

Presentation of improved systems

Figure
2
. Escape the Maze

Script


In the figure 3 there is a high level description of the above script (figure 2). It is possible to see
the four phases and the two swim lanes
for the social levels used in the script.


Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


10



Legend:
ACTIVITY THAT IS GOING TO BE FURTHER ANALYSED

Figure 3:
First (abstraction) level representation of the maze script.


Using a hierarchical decomposition notation two processes are described further in corresponding
schemata. In figure 4 the descr
iption of P1 Phase is analyzed. It is possible to see the Cool Modes
use and the collaborative learning expectations of the activities in P1. It is obvious that any of the
leaf activities could be further described by any text based notation.


STUDENTS GROUP
COOL MODES
maze_ws : WorkSheet
P1.1. CONSTRUCTION OF A MASE
P1.2. DEVELOPMENT OF A RULE SET
mazes : Maze and Rules Set Collection
P1. MAZE AND CORRESPONDING RULE SETS DEVELOPMENT

Legend:

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


11


SOCIAL NEGOTIATION - LEARNING FAVOR STATE
,
USE OF TOOL FOR SELF REGULATION,
SCAFFOLDING, NEGOTIATION DIALOGUE
FACILITATION ETC

Figure 4:
P1. Maze and corresponding rule set development.


In a similar way in figure 5 there is the description of phase P3. It makes sense to say that using
activity diagrams the readability of the script has been significantly enhanced. Furthermore

the
pedagogical annotation requirement uncovers script improvement possibilities. For example there
is no reach annotation in the diagrams that is a good indicator of improvement requirement. In
other words the script could be modified in order to answer
to the questions: Q1. “Why it is
expected that students will collaborate during the script implementation?”. The pedagogical and
learning design rational behind this script should be made clearer on the graphical representation
in order to facilitate teach
ers in better implementation. For example a hint could be provided to
the teacher to search for different solutions for the same maze during phase P4 in order to trigger
engagement in the presentation watching.


STUDENTS GROUP
COOL MODES
P3.1. SELECT A MAZE-RULE SET PAIR
P3.2. FIND A NEW RULE SET FOR THE MAZE
mazes : Maze and Rules Set Collection
P3.2. FIND A BUG FOR THE RULE SET
P3.3. ENHANCE RULE SET
COOL MODES
COOL MODES
mazes : Maze and Rules Set Collection
P3.4.STORE NEW MAZE
P3. DEBUG (FIND AND/OR CORRECT ERRORS)

Figure 5:
P3. Maze and corresponding rule
set development.



Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


12


2.2.2 Concluding remarks


UML activity diagrams can not be efficiently applyied for CSCL scripting as they are. The main
limitation is the requirement for detailed description of interaction between the different
collaborators that is no
t easy and often even desirable in CSCL scripting. In the above approach a
more informal flavor of activity diagrams have been proposed in order to describe CSCL scripts in
an appropriate abstraction level for quick and efficient human communication. The a
pproach
named “pedagogicaly annotated activity diagrams” permits the visual description of CSCL with
additional information about pedagogical aspects like: the reason that a specific situation is
expected to be interesting for students to engage to, what
is the basic collaborative learning
mode that is expected to happen (e.g. apprentienship, jig saw etc) etc. The proposed notation is
not machine oriented and is not expected to be implementable in a delivery system but it could
be used in teachers trainin
g for example. The use of UML notation permits the exploitation of
existing activity diagrams graphical editors for the production of specific schemata.


2.3
An approach to a learning process modelling language covering
CSCL needs

In order to enhance effe
ctive collaborative learning designs, we identify important conceptual
elements of collaborative learning scripts and propose a script modelling language for formalizing
collaborative learning scripts. In this chapter we present the conceptual model of the

script
modelling language and discuss some important elements in detail. At the end we give a short
overview of tools using different representations when modelling CSLC scripts according to the
described modelling language.


2.3.1 Conceptual model of a
collaborative learning script modelling language

In this section, we briefly present the conceptual model of the script modelling language by
presenting the conceptual structure of the collaborative learning script. It conceptually represents
the grammar o
f the script modelling language. Figure 6 illustrates the core concepts (elements) of
the modelling language and emphasizes the functional relationships between elements. A
CSCL
script

is defined as a computational representation of a collaborative learnin
g process. Each CSCL
script has its
learning objectives

and
design rationale
. It consists of a set of
roles
,
activities
,
transitions
,
artefacts
, and

environments
. Both
persons

and
groups

can become the members of
roles. A group can have subgroups and perso
n members. An activity may be atomic or may be
decomposable consisting of a set of networked activities and even other scripts. A transition
specifies a temporal preceding relation between two activities. An artefact may be created and
shared in and/or acr
oss activities as an intermediate product and/or a final outcome. An
environment can contain sub
-
environments and may contain
tools

and
contents
. A tool may use
artefacts as input parameters and/or output parameters.
Actions

may be performed by users
durin
g an activity or by the system before/after an activity or accompanying a transition. A
property

may be atomic or may have internal structure. An
expression

may use properties and
other expressions. A
condition

consists of a logical expression and actions,

transitions and/or
other conditions. Actions, properties, expressions, and conditions are useful elements for modeling
the dynamic features of collaborative learning processes and have very complicated relations with
other elements (e.g., CSCL scripts, ro
les, activities, artefacts, persons, groups, environments, and
so on). For example, an action may use attributes of entities as parameters and change the
values of attributes of certain entities. Such relations are not drawn in this diagram in order to
kee
p the diagram simple and readable.

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


13



Figure 6: Conceptual Model of Collaborative Learning Script
Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


14


2.3.2 Conceptual vocabulary

The relations between the core elements have been depicted above and we have an overview
about the script modelling language. In t
his section, we focus on presenting the semantics of each
element and some attributes of them.

CSCL Script

A CSCL script is a computational description of a collaborative learning process in which learners
with the help of other roles work collaboratively
toward certain outcomes (partially as artefacts)
by performing temporally structured activities within environments. A CSCL script has attributes
such as learning objectives, design rationale, prerequisites, coercion degree, granularity, duration,
target a
udience, learning context, script
-
specific properties, generic information (e.g., id, name,
description, and status), administration information (e.g., author and version), and run
-
time
information (e.g., creation
-
time, last
-
modification
-
time). The design
retionale and learning
objectives are the start point and the end point of the scripting and will be discribed
in detail
below
. It is allowed to specify a CSCL script with different degrees of “informedness”. CSCL scripts
with different coercion degrees ha
ve different usages. If a lower
-
grained CSCL script is embedded
in a higher
-
grained CSCL script, the mappings between the roles, properties, and artefacts of two
CSCL scripts should be specified. The designers of a CSCL script can estimate a period of time

to
complete the collaborative learning process. The target audience indicates for what kind of
students the script is suitable. The attribute “learning context”
enables

an informal description of
the general learning environment in which the defined CSCL
script is carried out. A script
-
specific
property is defined to capture a special feature of this CSCL script.

Learning Objectives

Learning objectives are the learning objectives to be attained by learners who execute the
scripted collaborative learning p
rocess
. The designers can specify the learning objectives at two
levels. The first level is the script level where overall learning objectives can be described. The
second level is the activity level in which the concrete learning objectives of each activi
ty can be
specified.

Design Rationale

The designers can specify the design rationale at two levels. The first level is the script level
where overall design rationale can be described as an attribute value. The second level is the
activity level in which t
he concrete design rationale of each activity can be specified as a part of
the description.

Activity

An activity is a definition about a logical unit of task performed individually or collaboratively.
There are three types of activities: atomic activity,
compound activity, and route activity.

An atomic activity is an elementary activity that makes up a CSCL script. Its attributes are defined
to specify learning objectives, engaged roles, used environments, created
-
/used
-
artefacts,
transitions and restrict
ions, pre
-
/post
-
/during activity actions, user
-
defined activity
-
specific
properties, completion
-
mode, execution
-
time, completion
-
condition, mode of interaction, social
plane, interaction rules, generic information, and simulation information. Some attribut
es are
important for designers to model collaborative processes and some for the run
-
time system to
render a collaborative learning environment appropriately for each user.
For example, the possible
values of social plane are: separately with a certain rol
e, individually with a certain role,
collaboratively with one and/or multiple roles, collaboratively in subgroups with a certain role, and
Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


15


so on. If the choice is “separately”, the run
-
time system will create an activity instance for each
user who reaches
the activity. If anyone completes his activity (e.g., find a given paper), all
activity instances will terminate. The “individually” means that the run
-
time system will create an
activity instance for each user. The run
-
time system synchronizes access to t
he following activity
by continuously checking whether all users have already completed the current activity. In
comparison the run
-
time system based on IMS LD typically handles this situation defined by using
role
-
part method.
The choice of “collaborative
ly with one and/or multiple roles” makes the run
-
time system to create only one activity instance and a session facilitating collaboration. Such an
activity will terminate according to the definition. For example, the value of the “completion
-
mode” is “con
ditional” and the “completion
-
condition” is that “if artefact_is_delivered or
time_is_over then complete_activity”.

The semantics of the value “collaboratively in subgroups
with a certain role” is that the run
-
time system creates an activity instance and a

session for each
sub
-
group and the members of each sub
-
group can have a shared activity workspace. The run
-
time system synchronizes access to the next activity when all subgroups finish their work. Another
example is the attribute “interaction rules”. It
contains a list of definition about under which
condition which role can (not) do what with whom by using which tool in which environment. For
example, in activity 1, the tutor can perform the actions to create groups/subgroups and assign
group members. In

activity 4, students can access strategies and mazes created by other groups.
Such information can be used by the run
-
time system to automatically provide corresponding
awareness information and to avoid work overload. It is so called that providing enoug
h and
necessary information to the right people at right time. In short, interaction rules explicitly specify
different responsibilities of different roles in a collaborative learning activity. Comparison with the
role
-
part method used in IMS LD, such an a
ctivitiy
-
centered definition method enables to model
varied forms of social interaction.

A compound activity is decomposable and contains a set of structured subactivities. There are four
kinds of compound activities: sequence, selection, concurrency, and
network. The meanings of the
first two types are as same as those in IMS
-
LD specification. A concurrency activity contains a set
of concurrently executable subactivities which will start together. The concurrency activity
terminates when all of its subacti
vities complete. The network activity is defined to represent
arbitrary complicated structure of a sub
-
process. The first three types of compound activities can
be represented by the corresponding network activities, but these types provide a simpler way t
o
specify specific control flows because the transitions among the subactivities need not to be
explicitly represented. Using compound activities enables to model hierarchical structured
processes.

A route activity is a “dummy” activity that just specifies

a variety of transition combination with
transition restrictions (split/join) and types (and/xor).

Transition

A transition is used to explicitly specify a temporal preceding relation between two activities.
Attributes are source
-
activity, destination
-
act
ivity, and actions. The first two attributes indicate
the source and the destination of the transition. Actions defined here refer to actions bound with
the transition and will be performed by the run
-
time system while triggering the transition. An
example

of an action bound with a transition is that when the transition between the third
activity

and the fourth activity of the maze script be triggered the action to exchange roles will
performed. Transitions can be combined with transition restrictions and
different types in
activities. Especially,
the concept of transitions and
route
activities enables to model
arbitrary
complex control flow.

Person and Group

The notation of “person” is defined similar to that in IMS
-
LD. However, we explicitly introduce th
e
notation “group” for modelling a variety of collaborative learning activities. A group has attributes
Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


16


such as name, max
-
size, min
-
size, person members, subgroups, purpose, form
-
policy, disband
-
policy, dynamic/static, group
-
specific properties, and run
-
ti
me information. The size of a group
can be restricted by its max
-
size and min
-
size. A group can have person members and subgroups
and form a hierarchically structured organization (as a directed
-
acycle
-
graph). Each group is
created for a certain purpose. I
t may be formed by using a certain policy such as open, assign,
apply
-
approve, invite
-
accept, and so on. It may disband by using a certain policy as well. Persons
normally have longer life cycle than the life cycle of a given CSCL script in the system and
can be
assigned as role members of multiple runs of the scripts executed at the same time or/and
different time. Unlike IMS LD, a group as a whole can become a member of a role. The members
of a group may
be
allowed or may be not allowed to change after th
e start of a run. The use of
group
-
specific properties enables to support “groupalized” learning.

Role

A role is a kind of participants who have common responsibilities during the collaborative learning
process.
A
role
is defined mainly by two parts
. One
part is its responsibilities and privilege within
the scope of the scripted collaborative learning process. Concretely speaking, the responsibilities
and privilege of a role is specified by assigning activities to do and by defining access rights to the
en
vironment elements and the actions performable within an activity. When a role is assigned to a
certain activity, all members of the role can participate in the activity and will have rights to view
and do something specified. The second part of the defini
tion is its membership. A role can have
person members or group members. A role can be further decomposed into sub
-
roles, which can
inherit the responsibilities and privilege of the role. The subroles of a role may be allowed to
assign to persons exclusive
ly or shareable. The restrictions can be set on the maximum and
minimum number for each role as well. That is, roles ca
n

be used for grouping purpose. A
question raises that when to model as a group and when to use the notation of the role while
grouping.
In fact, some roles are organization
-
oriented definitions like students and staffs. The
definition of organizational roles can be shared by multiple CSCL scripts. Others are behaviour
-
oriented role such as meeting chairman and tutor. It would better to mod
el an organization
-
oriented role as a group and to model a behaviour
-
oriented role as a script role. There are, at
minimum, two advantages to distinguish these two notations and establish the relations of
assignment between them. First, any change in the o
rganization of persons and groups has no
affect on the definition of the role in scripts and re
-
definition of roles in scripts does not effect on
organization. Second, because groups can become members of a role, it is easy to specify that a
group work pat
tern is assigned to several groups working in parallel.

Artefact

The
artefact
element does not exist in the IMS LD specification. An artefact is designed here as an
intermediate product and/or a final outcome created and shared in and/or across activities.

The
usage of artefact elements enables to model within CSCL contexts much more intuitive and easier
than to model the same process within IMS LD, because some burden for designers to handle
technical tasks are released by providing built
-
in mechanisms to
handle artefacts. In our
language, an artefact is treated as a file which can be a MIME
-
type or user
-
defined type. The
attributes of an artefact contain generic information (e.g., title, description, type, status, URL,
sharable, and aggregated), associatio
n information (e.g., creation_activities, consume_activities,
and default_tool), and run
-
time information (e.g., created_by, creation_time, contributors,
last_modification_time, current_users, locked_status, and so on). An artefact and its status will be
v
isible in the environment of the creation
-
/consume
-

activities at run
-
time. The specification about
the relations between artefacts and tools will help the run
-
time system to pass to/from artefacts
as input/output parameters to tools automatically at run t
ime. Some expressions and actions
related to artefacts should be added for mediating group work such as get
-
current
-
users
-
of
-
artefact and change
-
artefact
-
status. The artefact
-
specific properties may useful to model a
Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


17


specific feature of an artefact. As an
aggregated artefact, it is possible to append collective
information to the same file.

Environment

An environment specifies a set of contextual elements such as contents and tools. It may be a
real
-
world environment or a virtual environment. It is as same

as the definition in IMS
-
LD.
However, the run
-
time system may render a shared environment for a group of users according to
the definition of the activity in which the environment is used. For example, awareness
information about partners and artefacts is

provided in the rendered environment to foster
effective collaboration.

Content and Tool

A content is available information entity (e.g., a web page, an article, a book, and so on) needed
to carry out activities. A tool is a physic tool or an IT applicat
ion or an interface which can be used
to perform activities. A tool may be a single
-
user application, a shared application, or a service. A
tool may be an integrated tool or can be a referable/declared tool, which can be defined in CSCL
scripts. In IMS LD,

the concept of the learning object includes knowledge objects and tool objects.
These are similar to the definition of content and tools here. However, a tool is defined in IMS LD
mainly by its URL, which can be used to invoke the corresponding applicatio
n. Because we
introduce the concept of artefacts, when we model the information flow, sometimes it is necessary
to specify explicitly which artefacts will be used as parameters of an application and which
artefacts are output of a certain application. With
out such an explicit definition, the users will have
trouble to find appropriate tools to handle artefacts.

Action

An action is a generic and powerful mechanism to represent dynamic features of a collaborative
learning process. It is implemented as a proce
dure within the framework of the collaborative
learning script. An action can be declared as an action name and parameters to be passed. An
action is defined by referring the action declaration and assigning the parameters needed. The
action mechanism prov
ides a unified form of operations including not only property operations,
showing/hiding entity, and notification defined in IMS
-
LD, but also commonly used operations on
script, activity, artefact, role, group, person, transition, environment, and their re
lations. The
action notation is introduced for hiding the designers without a high overhead of technical
knowledge from complexities of modelling dynamic features of collaborative learning processes,
e.g., assigning all contributors of a given artefact as
the members of a certain role. The script
modelling language provides frequently used operations on elements as built
-
in actions. Each
implementation of modelling language can provide extended actions. The script modelling
language provides flexible mechan
isms for users to declare user
-
defined actions.

Property, Expression, and Condition

A property is used to capture a feature of an entity such as a script, a role, an activity, an
artefact, a person, a group, and an environment. The data type and data struc
ture of a property
can be declared as a property declaration, which can be reused in the definition of a script.

An expression is defined as same as that in IMS
-
LD. In IMS
-
LD, some elementary expressions are
provided like <is
-
member
-
of
-
role> and <complete
>. However, it is necessary to extend
elementary expressions to support collaboration such as <is
-
all
-
role
-
members
-
online> and
<artefact
-
contributors>. Furthermore, like an action, an expression schema can be declared in a
unified form (an expression name
and parameters to be passed), which can be reused while
defining a CSCL script.

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


18


Like IMS LD, the term of condition refers to a condition clause that is defined as a if
-
then
-
else rule
by using a logical expression and actions/transitions/conditions. The pat
tern of a condition can be
declared and reused while defining a condition clause in CSCL scripts as well.

2.3.3

Script modelling tools based on the presented modelling language

In order to support effective collaborative learning script design, we are work
ing on tools using
two different representation perspectives /views to CSCL scripts: A tree based and a diagram
based perspective. The tree
-
based view provides convenience to have both an overview of a
hierarchical structure and a view of semantic details.

The diagram
-
based view is suitable for
specifying processes with layered, more complicated control flow structure intuitively. Both tools
are based on the script modelling language described in the last section. A change of
representation is easily possib
le. Both tools enable non
-
technician designers to understand and
design collaborative learning scripts, which are translated from/into XML
-
formatted CSCL scripts
automatically by the tools. A CSCL script can be created, saved, deleted, validated, and deliv
ered.
For supporting different usage purposes, the tools can adapt the user interface to enable
modelling at different coercion degrees.

2.3.3.1 Tree
-
based Modelling Tool

The user interface of the tree
-
based authoring tool is shown in Figure 7. The window

of the tool
consists of two panels. The left panel is used to define CSCL script structure and the right panel is
used to create detailed designs. In the script structure panel, each CSCL script is shown as a tree
in which compound activities are represen
ted as intermediate nodes and atomic/routing activities
are represented as leaves. Like IMS
-
LD, there is no transition between sub activities of a selection
activity. However, all transitions between sub activities nested in a networked activity have to be

explicitly represented. The sub
-
flow of a sequence activity can be represented as a sequence of
activities and the order implies the transitions. Such a design is based on a fact that the main
structural relations of collaborative learning scripts are seq
uential.

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


19



Figure 7: The user interface of the tree
-
based authoring tool


Figure 7 shows an example definition of the maze script. Five activities are defined in a sequence
in which they are carried out. The sub
-
flow (with two concurrently executed activi
ties, two routing
activities, and transitions) of the second activity of the
maze

script (see D1) is described on the
lower level. Other trees below are reusable components such as persons, groups, contents, tools,
actions, expressions, and so on. A user c
an create or load a CSCL script and then create elements
such as activities, transitions, roles, environments, artefacts, and so on that make up a script. If
selecting an element, the user can see and edit the detailed specification of the element (e.g., t
he
definition of the
coopetion

activity in the Figure 7). The tool enables to define the relations
between elements by using drag & drop operations. For example, if assigning a role named
“working group” to the activity named “activity 4”, the user can dr
ag the tree
-
node representing
the role in the script tree and drop it in the list of “Engaged Roles”.

2.3.3.2 Diagram
-
based Modelling Tool

The diagram
-
based tool is based on state chart diagrams. It enables to define complex control
flow on arbitrary level
s. Each state node corresponds to an activity and each arrow represents a
transition. The nested sub
-
flow of an activity can be specified by drawing a new state chart in a
new workspace that pops up when double clicking the activity node. The designer can
decide
whether to show a sketch of the sub
-
flow of the activity node or to show the pedagogical
comment about the activity represented by the node. The designer can create and remove
elements (like a role, a tool or an artefact) by using drag & drop operat
ions. Detailed specification
of each element can be defined within a popped
-
up dialog window for each kind of elements.

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


20



upper level view fragment

Detailed view on subactivity flow of an upper level
activity


Figure 8: The user interface of the diagram
-
based authoring tool


Figure 8 is showing to screenshots of the maze script representation (control flow) in the diagram
based modelling tool. On the left you can see a fragment of the upper level control flow of
activities. Here it is a simple sequence.
The designer can decide for each activity node to show
either a pedagogical comment (like e.g. the upper activity) or a sketch of its sub activities (like
the activity node in the middle). He can also assign and denominate roles, tools, etc. to an activity

which can be used when defining sub activity flow. This can be done by double clicking on an
activity and can be repeated to any level. A new workspace is opened like it is shown on the right
part of Figure 8 which is a screenshot of the whole tool. On th
e right border you can see the tool
drag and drop area of the tool. This tool is realised as a plugin for the Cool Modes framework
7

developed by University of Duisburg Essen.


2.4

Scripted
Activities

Sketchpad


The Scripted Activities Sketchpad attempts
to bridge the gap between textual description of a
pedagogical script and low level machine
-
readable data
-
flow models. We have a traditional view of
scripts as a simple sequence of phases. In our approach, scripts are layered into two levels we call
“persp
ectives”: the phase perspective and the activity perspective.

Our aim is to visualize the elements of the different pedagogical scripts. Our graphical
representations (see
Figure
9 and
Figure
10) can be used for informal sharing of learning scripts
among teachers and researchers as well as to produce a computational equivalent. The Scripted
Actitvities Sketchpad tries to fulfill the need of both a simple and a rich conceptual

model. It



7

P
inkwart, N. (2003). A plug
-
in architecture for graph based collaborative modeling systems.
Proceedings of the 11th Conference on Artificial Intelligence in Education, Sydney, Australia

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


21


emphasizes on resource production, reuse and transformation as well as on the learners
interactions.

This approach was mainly developped during the Mosil mini
-
camps. It tries to find the largest
common denominator between all the participants.
When we presented our graphical
representations, they fostered discussions and feedback on issues that are still open. We should
keep in mind that from a pure workflow engine perspective, the Scripted Actitvities Sketchpad
does not give a sense of timing,
does not have well defined constraints and is context
-
free.
Moreover, teachers could argue that it does not underline the design rational of the script, the key
moments when learning happens and the purpose of the presence of some tools.


Figure 9: Layers

the Scripted Activities Sketchpad tries to cover. The
Scripted Activities Sketchpad

focuses on the middle
layer

2.
4
.
1

Model Description

The Scripted Activities Sketchpad is organized into two diagrams (see
Figure
1
0) ; a phase
perspective and an activity perspective. The purpose of the phase perspective is to to give an
overview of the several phases of the script with a summarized dataflow. A phase is “fed” by data
from other phases (inputs) and produces outputs.

T
he activity perspective describes a specific phase from the pedagogical script. A phase consist in
a set of activities performed by participants. Roles personify the participants. A roles is itself
specified by a set of activities. Activites can be recursi
vily definied within activites. We found
crucial to be able to specify the interaction and the role change within an activity. An environment
is assigned to each activity. Physical or virtual learning objects can be part of the environment. A
flow between
activity and interaction components can be described the same way as a finate state
diagram would.

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


22



Figure
10: Object diagrams of the
Scripted Activities Sketchpad

2.
4
.
2

The maze script using the
Scripted Activities Sketchpad

In this section, the maze scr
ipt is represented using the Scripted Activities Sketchpad.


2.4.2.1 Phase Perspective

The phases of the maze script are described by the light blue squares. They are connected
between each other to represent the data flow. At the beginning an instruction

worksheet (a
resource in light blue rounded square) is read (“R” in the flow line) during phase 1 “Setting rule
sets and mazes”. The output produced (“W” in the flow line) which are the collection of rule sets
and mazes are pictured by dark
-
blue rounded s
quares. The results are used (“R” in the flow line)
by the next activity: the “Presentation” activity. To go from one activity to another, a set of
constraints (red round between activities) must be fullfiled. In our case, it would be a time
constraint. Af
ter the presentation phase, the constraint would be that every presented their
results in order to move to the “Coopetition” (competion and collaboration) phase. Outputs of
phase 1 are also used to play and compare the proposals to produce advances rule se
ts and
mazes to become the outputs of phase 3. The outputs produced during the whole script are used
in phase 4 which is the final presentation of the results, the advanced rule sets and mazes.

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


23



Figure 11: Phase perspective on the Maze Script

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


24


2.4.2.2 Acti
vity Perspective

We will focus on Phase 1 which is rich enough to depict what the Activity Perspective is. Before
the phase takes place, a first input constraint, pictured by an incoming line, must be fullfiled. At
that stage, the scenario involves groups
of 4 participants. Light
-
blue octogones represent the
activities within the phase and the activities withing roles. Activities are therefor recursive (i.e. an
activity can include an activity). We will concentrate on the “Create different mazes” activity.
The
environment defined consists in a table, a physical maze, a simulation maze and a rule set upload
mechanism. We picture it in a three dimensional box. The activity is performed by participants to
whom roles have been assigned. In our case, we have an i
ndefined number (specified with a “*”)
of student testers and a student supposers. Each role is defined by the activities to carry out.
Moments of interaction, in red squares group role activities between which interaction should
occur. The student testers

argument (“Propose and Argument activity) over the quality of their
maze. Supposers explain (“Agreement” and “Classify”) their solution to the testers. An activity
undertaken can produce an output as the “rethink” activity producing the maze collection in

the
supposer role. We picture participants changing roles during an activity by a bi
-
directional stripped
arrow. This role rotation can be triggered by an event which labels the bi
-
directional arrow.

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


25



Figure 12: Activity perspective of the Maze Script's
first activity


2.
4
.
3

Concluding remarks

The Scripted Activities Sketchpad is an attempt to model learning mechanisms (e.g. explanation,
argumentation) not only sequences of high
-
level activities. It is flexible, neutral and technology
free. It can serve
as base for a tool to think, design and model educational scripts rather than
describing technical settings. However, it is just a graphical grammar, but not a formal language.
We intend to produce a useful conceptual framework that can be used in counsell
ing and
evaluation related to online learning projects. A long term objective, that our approach starts to
address, consists of automatically generating CSCL environments based on the definition of
integrated scripts.

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


26


2.5
Active Document approach

The Activ
e Document (AD) System provides a computational model and an underlying
technological infrastructure that permits the design and development of collaborative learning
activities that involve a variety of resources and devices. Emphasis is placed on learnin
g
experimental sciences where there is a pressing need for students to improve their learning
processes with a better understanding of theory and practice throughout the academic year,
especially in the context of distance learning. A way forward is to eng
age the students in a variety
of activities, including the performance of experiments either in real or virtual settings, supported
by a distributed collaborative computer environment. The premise here is to offer a persistent,
structured, dynamic, active
and personal work space to sustain their constructs in a long term
learning process.

The concept of an Active Document includes three aspects of the learning process: a description of
the activities, a description of the learning communities and the outco
me of the work undertaken
within the environment. They are specified in XML and are defined by four pairs of document type
definitions (or DTDs) and their corresponding XML document.

The
AD model

specifies a collection of activities, each of which reflect

the components of an
activity, modelling the division of labour and the mediating tools associated with each task.
Activities can be grouped within this AD, to provide (optional) sequencing and prerequisite
dependences between
groups

of activities. The de
finition of an activity includes the following: (a)
The description of the object of the activity. (b)The specification of the tasks and subtasks, and for
each one (if applicable) the different roles that the participants involved in the task can play. (c)

The tools and resources available for each role related to a task. This model is partially
represented in the figure 1
3
.


Community
User
Role
plays
*
*
*
Activity
Task
*
*
*
LabDoc
*
collaborates in
develops
Aim
Goal
Experiment
fulfills
Resource
input
input
*
*
outcome
General input
Teacher
Student
Monitor
Guest
...

Figure

13
. Main elements of the AD model


The AD model requires another data that is described in

the following complementary models:



Community AD
. It

represents the activity organization in order to describe the
assignment of roles for a specific task to the members of a given community. For each
activity, a description of the community involved is p
rovided. As it has been previously
stated, this description is processed by the AD architecture in combination with the
Description AD in order to relate the appropriate tasks and tools to the corresponding
members of the community.

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


27




Resources

definition.
It represents
the support for a specific task available to students
when they undertake an experiment. For each task, a description of the available resources
is given. This description is processed by the AD architecture in combination with the
Descriptio
n AD in order to relate the appropriate tasks and tools. Performing the activities
specified in an Active Document may either require or benefit the use of a number of
resources, such as external document repositories or different types of modelling tools.



Outcome

De
finition. It
specifies the way in which the results of the tasks performed in the
environment are in
-
progress. Thus, the Outcome AD is in fact the real
active

component of
the AD organization, i.e., it is the result of the work generated by a sp
ecific actor involved
in the activity described by the Description AD.


2.5.1
Example with maze script

In this section the maze script is represented using the AD model and compiled in order to create
a collaborative enviroment to carry it out with groups
of students.

The different phases of the Storyboard are considered “experiments” in the Active Document and
for each phase one or more activities have been defined, with some resources to carry them out.

In the figure 14, the maze scenario is shown in t
he AD environment, and in figure 15, part of the
XML code with the definition of the Phase 2 of this script following the AD model. In this example,
two tasks have been defined (without constraints between them) and two tools are available to
carry them o
ut: one is a software tool (Coolmodes) and the other is a physical tool (Toolkit to
create the maze and the robot). The first creates an outcome that could be stored by the AD
system and and the latter only should present a list of instructions. These tool
s should have been
previously declared as resources in the resources.xml file, so that the active document compiler
could use them for creating the enviroment.



Figure 14. Main window for the maze scenario in the AD

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


28




Figur
e

15
. XML definition for Phase 1 for the Maze script


2.5.4
Concluding remarks

First of all, the Active Document model is implemented in the Active Document system that is fully
operative, available software product and has been tested with actual users (
see evaluation
subsection for details). The following subsections deal with its architecture, the evaluation and the
available resources for the AD system.

The Active Document computational architecture is composed of three parts: a metadata editor,
which
allows creating and configuring the ADs for the specification of learning activities, a
distributed set of tools, which are available to be used in such activities and a set of software
components, which work together for generating the user environment th
at will permit to carry
out the defined activities and will manage the interaction between users and the system.


Resource AD

Community AD

Description AD

CONFIGURATION LEVEL

XML Data
Source



D
ATABASE



Configuration
Data

PRESENTATION LEVEL

APPLICATION LEVEL


C

O

N

T

R

O

L


L

E

V

E

L

login

request

response






AD System

Metadata
editor



Figure

16
. The Architecture of the Active Document (AD) System


The general architecture underlying the Active

Document (AD) System and its management is
shown in Figure 16. The system has four functional levels. The four XML data structures that
Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


29


define a particular AD scenario together with the results produced by students are labelled as


in
each part, and the
generated user interface as

.

This Active Document System (and its underlying model) has been evaluated with students during
four years in a variety of subjects such as Chemistry for undergraduates or a PhD course on
Natural Language Processing Applicatio
ns. The Chemistry students were divided into a number of
small groups and given activities aimed to teach them Lab procedures. They had three phases,
ranging from the previous training to the real Lab practise and the post
-
lab report elaboration.
The activ
ities used a number of devices (such as PDAs) and established a virtual environment
tailored for giving the students the possibility to gather some experience before the Lab and for
reflecting on the theoretical background of the Lab procedures.

There are
a use manual and an installation manual available, as this is a working software ready
to be used. These manuals, along with data, detailed explanations and related publications can be
found on the web at the URL http://sensei.lsi.uned.es/ActiveDocument/Ev
aluation.html


2.6 Workflow approach of learning scenarios

Pedagogical scripts describe the structure and the coordination of learning activities in somehow a
process
-
oriented view. Some authors speak about this kind of process as a learning process. In
ot
her domain fields, the description and enactment of coordinated activities is realised by
workflows system. The generally accepted definition for this kind of system comes from [1]

”Workflow is concerned with the automation of procedures where documents, i
nformation or
tasks are passed between participants according to a defined set of rules to achieve, or
contribute to, an overall business goal.”

Some links can be drawn between workflow process and pedagogical scripts. In both cases, the
participant aims t
o achieve a common goal (learning some things). The workflow approach
presented here is based on the standards of the Workflow Management Coalition (WfMC). As
represented in figure

17
, workflow model consists of five main entities (Process, Activity,
Trans
ition, Relevant Data and Participant).



Figure 17: XPDL Meta Model from [3]


Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


30





Process

defines the way to achieve a common goal, i.e., mainly the path between the
different activities. It determines the execution context (overall description, input values
,
...). This element is the container of all the other entities of the metamodel.



Activity

defines the work to realize; there are three types of activities. Sub
-
flow activity
allows to execute another sub
-
process, block activity consist of an activity set
which is an
aggregation of activities and transitions and atomic activity is the real work to do. At the
execution time, these atomic activities are transformed into work items which are executed
by participants and/or applications.



Transitions

are the lin
ks between different activities. They define the control flow inside
the process;



Relevant Data

are the data used and produced by the process and the activities. This
data can be linked with the data of the enterprise, as for example a LMS system. It’s
pos
sible to define the data flow, i.e., how the information will circulate between the
different activities;



Participant

represents a human, role or group to whom work items are assigned.
Participant can be linked with the organizational model of the enterpri
se or of the learning
platform.

As we can see, there are some similarity between workflow model and script model. A CSCL script
is a sequence of phase, so we can see it as a workflow process. Each phase represents an activity.
With the transitions, we can
model the control flow and the data flow between the phases.

This approach of learning scenario with a workflow engine is the basis of the development of the
COW [2] (Cooperative Open Workflow) system which aims at supporting different learning styles
and
offering flexibility mechanism to redefine dynamically the learning process (e.g.,
add/remove/modify activity/transition, …).


2.
6
.1
Example with maze script

The maze script can be described using a workflow approach. As in using annotated activity
diagram
s, it is possible to describe the learning process at different levels. The first level will
describe the overall process which is the sequence of the four main phases. Each phase
represents a subflow activity, i.e., an activity which will call another pro
cess (figure

18
). By this
way, we can obtain a more precise decomposition of the learning process.

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


31



Figure 18 First level representation of the maze script


The second level will refine each phase into a process of atomic activities. Nevertheless, it’s
po
ssible to add any sublevel of definition. For example, figure
19

represents a possible redefinition
of the phase 1 of the maze script where two groups of students are building in parallel a maze and
setting rules for the robot.



Figure 19 Description of
the

first phase


2.
6
.
2

Comparison with other approaches and standards

This workflow view of learning processes is relatively close to the IMS
-
LD point of view which is
also process
-
oriented, considering only the scheduling part of the specification. In fac
t, the
“pedagogical aspect” of IMS
-
LD, like “objectives” is useless for workflow enactment which mainly
focuses on activities structuring.

The model of IMS
-
LD and the model of workflow are relatively
close together. They focus on activity and on their coor
dination

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


32


Some fundamental elements of workflows systems like time management (deadline for activities,
minimal and maximal duration) and data flow are not fully expressed in IMS
-
LD. In the same way,
the pedagogical elements of IMS
-
LD have no equivalence in

workflow model, e.g., the objectives
of an activity. From a technical point of view, it’s not really a problem because these elements are
not fundamental for the enactment. They have to be presented to the students and teacher, but
they are useless for ac
tivity coordination.


2.
6
.
3

Concluding remarks

The use of workflows systems offers a technical response for the enactment of learning scenario.
Actually managing the schedule of the activities performed by students can be a daunting task for
tutors and tea
cher especially if there are a large number of students. They have to keep track of
each student’s progress to provide them with new activities. Workflows systems can easily
manage the time constraints, the data flow between activities and in some case the

set of roles of
the participants.

However, this kind of system mainly focuses on coarse grain coordination. If we want to express a
more precise collaboration or coordination model, we have to use other tools for that purpose. In
this case, the workflow s
ystem only sets the environment for the activity.

There are only few workflow systems dedicated to support learning scenario. We will present more
in detail the COW platform developed in the University of Lille.


2.
6
.
4

The COW Platform

This work has been d
riven by the following requirements:



Support different learning styles. The workflow must be able to handle both individual and
group work even within the scope of a single process;



Support collaborative activities. We believe that collaborative learning c
an be a way to
enhance the learning experience and strengthen learners’ motivation;



Support dynamic redefinition of the learning path. A tutor should be able to add activities
for example if he detects a weakness in the learner knowledge. There are even so
me times
when one does not even know beforehand the activities that will be needed;



Support for reuse of existing course and activities models. It will be easier for pedagogical
engineers to build course modules from existing parts. So we would like to pro
vide
predefined models (or skeletons) and also keep track of the models that have been
modified during a course.

From a technical point of view, we would conceive a ”learning scenario enacting component”
which can be included within existing LMS. And for m
ore interoperability, we would also follow the
existing standards for the implementation of the workflow engine.

For the development of the COW platform, we have defined a micro
-
kernel architecture. We can
realize two types of modification in COW at run
-
ti
me, the process model and the engine
behaviour. Process modification consists in adding/deleting/changing activities and transitions.
These changes can be realized for one person or for a group of learner.

This architecture allows us to easily add level de
sign for specific purpose. For example, we can
add a level to manage IMS
-
LD specification. This level translates IMS
-
LD in XPDL in order to enact
the learning process by the workflow engine. When a user connects to the system, the IMS
-
LD
level can show the

pedagogical aspect (e.g., learning objective of the activities or of the module).

Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


33




.





















8

Workflow Management Coalition. ”The Workflow Reference Model”, WfMC
-
TC
-
1003, Version 1.1, 19 January 1995.
http://www.wfmc.org/
Dillenbourg, P. (20
02). Over
-
scripting CSCL: The risks of blending collaborative learning with
instructional design. In P. A. Kirschner (Ed). Three worlds of CSCL. Can we support CSCL (p. 61
-
91). Heerlen, Open
Universiteit Nederland.

9

Thomas Vantroys and Yvan Peter, COW, a
Flexible Platform for the Enactment of Learning Scenarios, Springer Verlag,
LNCS 2806.
Kollar, I., Fischer, F., & Hesse, F. W. (2003). Cooperation Scripts for Computer
-
Supported Collaborative
Learning. In B. Wasson, R. Baggetun, U.Hoppe, & S. Ludvigsen (Eds
.), Proceedings of the International Conference on
Computer Support for Collaborative Learning
-

CSCL 2003, COMMUNITY EVENTS
-

Communication and Interaction (pp.
59
-
61). Bergen, NO: InterMedia.

10

Workflow Management Coalition. ”Workflow Process Definition

Interface


XML Process Definition Language”, WfMC
-
TC
-
1025, version 1.0, 25 october 2002. http://www.wfmc.org/standards/docs/TC
-
1025_10_xpdl_102502.pd



Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


34


3. Conclusions

In this
chapter we have seen examples of existing approaches utilised in structuring
and
facilitating collaborate learning (Active Documents and COW). We have also seen development
efforts of computational workable representations (section 3). Further, we have seen the
exploration and adaptation of one of the UML models for expressing in a

more formal way a
collaboration script including how to put in the designers rationale into the model. We have also
tried to use the existing IMS
-
LD specification to express our scripts (the rationale behind them,
their critical ingredients etc.). Last, w
e have developed our own modelling technique from
scratch

without what we feel are restrictions and limitations found in current models.

Our investigations into IMS
-
LD showed that we need a more dynamic runtime engine that could
facilitate amongst other t
he problem of changing roles. Further, that the artefacts being produced
in collaboration scenarios (e.g. collaborative artefacts) are not represented good enough in the
current specification (only as generic properties). Last, our investigations showed th
at it is difficult
to model different social planes of CSCL (e.g. individual, versus, informal groups, sub
-
groups,
class etc.).

The pedagogical annotated activity diagrams are adapted UML (Unified Modelling Language)
Activity Diagrams modified to shows soc
ial planes/level in the different swim lanes, and where the
model (activity symbols) is annotated in order to show the pedagogical design rationale. PAAD
tries to emphasize that the pedagogical design and rationale should be more explicit represented
in th
e visual model

Further, a first version of a 'conceptual model, vocabulary, and modelling tools' has been
developed. In this approach a CSCL script "is defined as a computational representation". A
conceptual model modelled using a class diagram is present
ed, and the elements explained. In
this approach the need for awareness information is also emphasized as an important ingredient
in CSCL. Also, the important distinction between organisational roles (staff and student) and roles
that are played in the le
arning design is made (a distinction not made properly in IMS
-
LD). A
toolbox consisting of two ways of representing collaboration scripts is being developed. One
showing a tree based representation, another showing the scripts as diagrams (which is based o
n
state charts). These tools generate validated XML descriptions that are ready for a computational
environment.

The Scripted Activities Sketchpad is an attempt to bridge the gap between pure textual
descriptions of scripts and computational machine readab
le representations. Two different
abstractions levels are modelled in this approach. One showing a high level view (phase
perspective, and one an activity perspective where the details are visualised. This modelling
technique is meant to facilitate communi
cation about the scripts especially in design teams
consisting of actors with different expertise.

The Active Documents approached is based on the activity theory framework where special
concern has been made in relation to model the social organisation, a
ctivities and
resources/services available for the learners. This model based on xml technology is fully
operational and have been tested in different scenarios. The next section explained how the
workflow approach (specified by WfMC) has been adapted to c
ollaborative learning. The adapted
platform, COW, focuses on activities, data flows and transitions. This approach demonstrates that
many of the concerns collaboration scripts have can be taken care of in such a model (e.g time
constraints, data flow, role
s of participants), but that this approach handles more coarse graines
coordination rather than details that at times are necessary in collaboration scripts.

All the sections

in this chapter concerns the issue of representations. Both how to use
represent
ations to fully model what we want to express in CSCL, but also how representations are
transferable into computational artefacts in an educational context.
In traditional I
nformation
Systems Design (ISD) you can see several competing methods and models fo
r both the process
Kaleidoscope


JEIRP MOSIL
-
Deliverable 23.2.1


31.
12.2004


35


(e.g data centred and task centred models) and products (e.g object oriented or xml based
architectures) of information system development. The representations are developed based on
both theory and practice, but no unifying models exis
t even though UML family of models are
currently the dominating one.

Looking at

the literature in CSCL we could not find that any real (unified) methods have emerged
from the field. Benyon (2002) reports the same from the field of CSCW. One possible reaso
n for
this is that there exist different models/perspectives on learning (there will always be a debate
about what the nature of cognition and learning is). A representational model that fits all the
perspectives might be impossible, or at least difficult,

since a model should just focus on the
important aspects while hiding
unnecessary

detail. Thus, what is
unnecessary

detail from one
perspective are the
important

and essential
aspects

of another
perspective.

W
e envisage that representations are needed to
both mediate the understanding of collaboration
scripts, in additions to models and representations that ease the process from model to
computational artefact. We believe this is an issue that will grow in importance due to current
trends of making standar
ds for learning units, and the need for better understanding,
communicating and building of CSCL. In short for a better discourse around collaboration scripts,
from how to model and visualise them to how to realise them in an CSCL setting.


We also see th
at in fostering such an understanding we need different representation models at
different stages due to different purpose of the representations and different actors involved in
communicating about and designing for CSCL. By showing current available appr
oaches together
with investigations into existing standards such as UML and IMS
-
LD we have come to the
conclusion that a representation model (or models)that deals with the intricacies of CSCL are
needed. Especially a model that can express social planes,
shifting roles and different pedagogical
rationales in a more sensible way. A first step in that direction has been taken in this part of
MOSIL.







Acknowledgements



The work has been conducted as a part of MOSIL
-
work with equal parts of each author.






11

Benyon, D (2002). Representations in Human
-
Computer Systems Development. In Cognitive, Technology & Work
4:180
-
196. Spreinger
-
Verlag. London Limited.