approaches require a 'domain language' or
Educational Modeling Language (EML), allowing
modeling the learning activities, as well as a
'binding' technique to be machine-readable. These
approaches also require some techniques and tools to
support the 'operationalization' step consisting in
bridging the gap between the formalized and
machine-readable learning situations and their
concrete setting-up into a dedicated learning
environment.
The LAMS solution (Ghiglione et al, 2007)
consists in integrating a graphical internal editor to
some LMSs like MOODLE. It offers a user-friendly
interface to designers but produced scenarios or
courses are related to a specific runtime engine to
add to the LMS. This approach does not rely on the
LMS internal semantics. Other approaches focus on
the proposition of specific EMLs or Visual
Instructional Design Languages (VIDLs) with
'larger' semantics (Botturi et al., 2007) but they also
raise operationalization issues like the loss of
information. Excepting the all-in-one infrastructures
and EML/VIDL for practitioners, specified and built
together (e.g. the LDL language and the LDI runtime
infrastructure dedicated to play LDL scenarios
(Martel et al., 2006), none of the current
instructional design propositions concerns a direct
operationalization of practitioners-centered learning
scenarios on some LMS or direct transformations
towards equivalent scenarios conformed to some
LMS centered languages.
The COLLAGE proposition (Hernández-Leo et
al., 2006) is interesting because the collaborative
design patterns proposed to practitioners have been
specified and developed on top of the IMS-LD
standard: semantics about concepts/relations
transformations have been taken into account when
building the patterns; these patterns are so fully-
compatible with IMS-LD. The operationalization of
COLLAGE models then tackles the problem of
operationalizing IMS-LD models. Unfortunately,
existing LMSs are still not compatible with this
standard (Berggren et al., 2005).
Although CopperCore can be used as an IMS-LD
runtime engine, such complex tool is, as far as we
know, rarely used or integrated to LMSs. Moreover,
the scenarios specified by Collage, or other editor
dedicated to specific EMLs (IMS-LD, LDL, CPM,
etc.) do not focus on LMSs languages (ie. the LMSs
learning paradigms and features).
Also, most of research works that deal with the
exportation or transcription of learning scenarios
have highlighted the semantic learning design gap
that appears when considering learning scenarios
concepts and platforms features (Abdallah et al.,
2008, Caron et al., 2005). Such scenarios
transcriptions lead to some losses of information
from the source scenario or to some incomplete
informations into the platform transcription (lack of
sufficient information from the source model to
specify at the required level the platform elements).
This conceptual gap between two learning design
languages is inherent to the transformation process
when both languages have been elaborated with no
reciprocal relations.
3 FOCUSING ON THE LMS
SPECIFIC LANGUAGE
Current propositions rely on a same underlying idea
about evolving existent LMS by large add-ons
(editors or runtime engines) and new semantics in
order to integrate learning design standards or to
improve the design.
We do not aim to add new semantics to the
domain specific model embedded into the LMS. We
assume that each LMS is not pedagogically neutral
and that it embeds an implicit language for
describing the process of designing a learning
activity. Thus, our proposition is based on the
following ideas this language can be identified and
explicitly formalized in a computer-readable format;
this format can be used as a binding format for
various external tools which will focus on different
designing facets. LMSs have to be able to
import/export learning scenarios in conformance
with this language: current platforms have
notwithstanding to evolve in order to offer this new
functionality. From an LMS viewpoint, our
proposition is to add a similar 'import/export'
functionality like the SCORM one but with their
own language. We propose so a kind of new labeled
standard: self-compliance LMS. This will warrant e-
learning tools developers that they could exploit this
explicit language (that will have to be accessible
through an XML schema for example) for
communicating with the LMS. Operationalizing a
learning scenario from this LMS-centered viewpoint
will consist then in the importation of a learning
scenario formalized in conformance to this explicit
LMS language.
We also propose an original TEL-centered
Model-Driven Engineering and Domain-Specific-
Modeling (DSM) (Kelly et al., 2008) approach both
to identify/formalize the LMS language and to use it
as a basis for the elaboration of LMS-centered
A MODEL-DRIVEN AND EXTERNAL APPROACH FOR LEARNING DESIGN UPON LEARNING MANAGEMENT
SYSTEMS
399