A Learning Design Ontology based on the IMS Specification

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
Departament of Electronics and Computer Science, Faculty of Physics.
Campus Univesitario Sur s/n, University of Santiago de Compostela.
15782 Santiago de Compostela, A Coruña, Spain.
rramorin@usc.es; lama@dec.usc.es; eduardos@usc.es; eladolfo@usc.es; vila@dec.usc.es


Abstract

In this paper, we present an ontology to represent the semantics of the IMS Learning Design (IMS LD)
specification, a metadata standard used to describe the main elements of the learning design process. The
motivation of this work relies on the expressiveness limitations found on the current XML-Schema imple-
mentation of the IMS LD conceptual model. To solve these limitations, we have developed an ontology
using Protégé at the knowledge level. In addition, we provide its implementation in OWL, the standard
language of the Semantics Web, and the set of associated axioms in first-order logic. The OWL file is
available at http://www.eume.net/ontology/imsld_a.owl.

Keywords: IMS Learning Design, Ontologies, Semantic description, Formal axioms.


1. INTRODUCTION

In the last years, the popularity of the Internet has opened the door to new ways of learning and numerous
educational tools and applications. In this context, the need to manage reusable resources has driven the
development of several metadata specifications in order to represent learning content, educational re-
sources and learning design methodologies. This paper focuses on the representational issues of the learn-
ing design, which describes the method that enables learners to achieve learning objectives after carrying
out a set of activities using the resources of an environment.

The specifications for the learning design, known as Educational Modelling Languages (EML), are mod-
els of semantic information and aggregation that describe, from a pedagogic point of view, the content as
well as the educational activities. These elements are organized into units of study with the aim of allow-
ing their reuse and interoperability (Rawlings et al., 2002). Moreover, EMLs facilitate the description of
pedagogic aspects that are related with LOs in educational processes (Koper, 2001). The principal EML
specifications are as follows:

− CDF (http://www.ariadne-eu.org). It uses the ARIADNE Course Description Format (A-CDF) for the
description of courses (Verbert & Duval, 2004). A course in A-CDF consists of XML documents
along with a course generator LMS. It places special emphasis on the content and its aggregation, but
it is expressive enough to describe the learning process in accordance with a pedagogic model. The di-
dactic material that can be managed through CDF is restricted to text format. It uses a combination of
tools developed by the ARIADNE consortium (curriculum editors, LMS, KPS) and establishes the
concept of Course as a unit of study.
− LMML (http://www.lmml.de). An acronym of Learning Material Mark-up Language. It is based on a
meta-model in order to be used in different application domains. LMML relies on XML for the de-
scription of e-learning material (Slavin et al., 1999), and comprises various learning material modules,
each one containing other sub-modules. Focused on a conceptual, modular and hierarchical structure
of e-learning content, LMML can be adapted to different learning situations and students. It uses the
concept of Course as a unit of study.
− PALO (http://sensei.lsi.uned.es). It is a modelling language that has been developed by the UNED
(Universidad Nacional de Enseñanza a Distancia, Spain) (Rodríguez-Artacho et al., 1999). PALO de-
scribes courses organized into modules that contain learning activities, content, and an associated

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
204
teaching plan. The language provides templates to define types of Learning Scenarios with their asso-
ciated pedagogic properties. By using the language features, it is possible to establish the sequencing
of both modules and learning tasks. According to the course constraints, these attributes also allow to
define deadlines and dependencies between modules and tasks. It uses the concept of Module as a unit
of study.
− Targeteam (http://www.targeteam.net). An acronym of TArgeted Reuse and GEneration of TEAching
Materials. This language supports the production and management (use and reuse) of learning material
(Koch, 2002), including notes and contents such as explanations, motivation, and examples. All these
elements can be carefully structured in an interrelated manner. It is focused on the use of an XML-
based language, TeachML, and uses the concept of Issue as a unit of study. This EML allows the use
of material in different learning situations and pedagogic domains (primary, secondary and higher edu-
cation).
− TML/Netquest (http://www.ilrt.bris.ac.uk/netquest). It uses the Tutorial Mark-up Language (TML), an
extension of HTML, to produce questions (Brickley, 2004). This language was designed to separate
the semantic content of the layout, or on-screen format, from a question. The TML files are in text
format, and can be generated from other formats or other questions in a database. This EML does not
support the concept of unit of study.
− IMS Learning Design (IMS LD) (http://www.imsglobal.org/learningdesign). This specification, drawn
up by the IMS/LDWG work group, is an integration of the EML developed by the OUNL (Open Uni-
versity of Netherlands), with other existing IMS specifications for the exchange and interoperability of
e-learning material. The OUNL EML is a meta-vocabulary that is defined based on the diversity of
concepts existing in a wide range of pedagogic techniques. The IMS EML incorporates the OUNL
EML, and describes the structure and educational processes based on a pedagogic metamodel, using
units of learning called Learning Design (IMS, 2003a). IMS LD describes a method that is made up of
a number of activities carried out by both learner and staff in order to achieve some learning objec-
tives. It allows the combination of various techniques (traditional, collaborative, etc.), and facilitates
the description of new ones. From the proposed specifications, the IMS LD has emerged as the de
facto standard for the representation of any learning design that can be based on a wide range of peda-
gogical techniques.

The metadata specifications are useful to describe educational resources, and thus to facilitate interopera-
bility and reuse between learning software platforms, as they represent the vocabulary describing the dif-
ferent aspects of the learning process. However, the main drawback is that the meaning of the specifica-
tion is usually expressed in natural language. Although this description is easy to understand for humans,
it would be difficult to be automatically processed by software programs. To solve this issue, ontologies
(Gómez-Pérez et al., 2004) come handy to describe formally and explicitly the structure and meaning of
the metadata elements; that is, an ontology would semantically describe the metadata concepts. In the edu-
cational domain, several ontologies have been proposed: (1) to describe the learning contents of technical
documents (Kabel et al., 1999); (2) to model the elements required for the design, analysis, and evaluation
of the interaction between learners in computer supported cooperative learning (Inaba et al., 2001); (3) to
specify the knowledge needed to define new collaborative learning scenarios (Barros et al., 2002); or (4)
to formalize the semantics of learning objects that are based on metadata standards (like LOM) (Brase &
Nejdl, 2004). The focus of that research is either on the development of a taxonomy of concepts on the
basis of a established theory or specification (1 to 3), or on the formal definition of the metadata using an
ontology language (4). However, none of them deal with the formal description of the meaning of the con-
cepts, and they do not address the ontological modelling of any specification for learning design.

In this paper, we present a learning design ontology based on the IMS LD specification, the de facto
metadata standard for the learning design. In this ontology, the IMS LD elements are modelled in a con-
cept taxonomy in which the relations between the concepts are explicitly represented. Furthermore, a set of
axioms constraining the semantics of the concepts has been formulated from the restrictions (expressed in
natural language) identified in the analysis of the IMD LD specification.

The paper is structured as follows: in next section, the limitations of the XML-Schema language on repre-
senting the IMS LD specification are outlined; then, the concept taxonomy and the ontology axioms are
described, and an example illustrates how the ontology could be used; then, a description of how the on-
tology was implemented and used in an educational environment is presented; and finally, the presented
work is discussed and the main contributions are summarized.

A Learning Design Ontology based on the IMS Specification
205

2. THE NEED FOR A LEARNING DESIGN ONTOLOGY

The IMS Learning Design specification is a metadata standard that describes all the elements of the design
of a teaching-learning process (IMS, 2003a). This specification is based on: (1) a well-founded conceptual
model that defines the vocabulary and the functional relations between the concepts of the LD; (2) an in-
formation model that describes in an informal (natural language) way the semantics of every concept and
relation introduced in the conceptual model; and (3) a behavioural model that specifies the constraints
imposed to the software system when a given LD is executed in runtime. In other words, the behavioural
model defines the semantics of the IMS LD specification during the execution phase.

To facilitate the interoperability between software systems, the IMS LD specification has been formally
modelled through the XML-Schema language (Thompson et al., 2004;IMS, 2003b). However, the knowl-
edge model of this language is not expressive enough to describe the semantics (or meaning) associated to
the elements of the IMS LD. Thus, the main limitations of the XML-Schema language are (Gil & Ratna-
kar, 2002):

− Hierarchical (is-a) relations between two or more concepts cannot be explicitly defined. Therefore,
there are no inheritance mechanisms facilitating the representation of concept taxonomies. For exam-
ple, in the IMS LD specification, the Learner and Staff elements do not inherit the attributes and
relations of the Role element: they are just included as XML sub-elements of the Role element. Fig-
ure 1 compares both the OWL and XML-Schema specifications based on the definition of the
Learner concept. In OWL, the hierarchical relation between the Learner and Role concepts is
explicitly defined through the rdfs:subClassOf, and, therefore, the attributes of Role will be automati-
cally inherited by Learner. In XML-Schema, however, the attributes of Role are directly added to
the definition of Learner, but no hierarchical relation is established between them.
− Properties of relations cannot be defined. XML-Schema language does not provide primitives to repre-
sent neither mathematical properties (like symmetry or transitivity) nor taxonomic properties (like dis-
joint and exhaustive partitions) of a relation. For example, the IMS LD specifies that an instance of the
Staff cannot be a Learner for any given unit of learning, what means that Staff and Learner
are disjoint concepts. Figure 1 shows how this taxonomic property can be explicitly expressed in
OWL.
− General and formal constraints (or axioms) between concepts, attributes, and relations cannot be speci-
fied. These axioms describe more precisely the semantics of the concepts as they constrain how the in-
stances of the concepts could be created. For instance, the axiom “if an Act is executed in the context
of a Play, and both have a given value for the time limit attribute, the value of this attribute for
the Play should be greater or equal than the value for the Act” could not be represented in the
XML-Schema language. This restriction, however, could be defined in ontology languages like F-
Logic (Kiefer al., 1995) or Ontolingua (Gruber, 1993). In order to describe these kinds of axioms in
OWL, a new language, called SWRL (Horrocks et al., 2004), has been submitted to the W3C.

Therefore, the IMS LD specification requires a modelling capable of describing explicitly and formally the
semantics of its elements. To achieve this goal, we have developed an ontology (Gómez-Pérez et al.,
2004), as it facilitates the semantic description of the conceptual model as well as the definition of formal
axioms related to both information and behavioural models. This ontology is based on a knowledge model
that includes complex taxonomic relations (like both hierarchical and ad-hoc relations, disjoint and ex-
haustive partitions, etc.) as well as formal axiom descriptions.

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
206

3. THE LEARNING DESIGN ONTOLOGY

To develop the Learning Design ontology we have created a concept taxonomy, which describes the ele-
ments of the IMS LD conceptual model and the IMS LD information model, and a set of axioms, which
formally constraint the semantics of the concept taxonomy on the basis of the explanations formulated in
natural language in both information and behavioural models.

3.1. DESCRIPTION OF THE CONCEPT TAXONOMY

The upper node of the LD ontology is the Unit of Learning concept (Figure 2) that defines a gen-
eral module of an educational process, like a course or a lesson. Following the IMS LD specification, a
unit of learning is modelled as a content package (IMS, 2003a) that integrates the description of both the
LD and the set of resources related to it. The Resource concept allows representing various entities, like
physical resources (Web pages, files, etc.), and concepts whose attribute description is domain-dependent
(learning objectives, prerequisites, etc.). To model the different kinds of resources, we have extended the
IMS LD specification with a new hierarchy of concepts (grey boxes in Figure 2 In this way, when a LD
concept refers to any of the resource properties, it establishes a relation with the Item concept, which in
turn, has a set of subclasses that replicate the hierarchical structure of the resources (following a one-to-
one correspondence). These two hierarchies have been introduced to decouple the references to the re-
sources (Item hierarchy) from their modelling (Resource hierarchy). Thus, if two applications use the
same LD to model a course, but define the resources in a different way (for example, if the learning objec-
tives are specified either as textual description or through their corresponding attributes), the LD does not
need to be changed because the links to the resources are indirectly established through the Item hierar-
chy.


Learning Design Description

The Learning Design concept is related to the Learning Objective and Prerequisite
concepts, which define the intended outcomes when the unit of learning is carried out, and the previous
knowledge needed to participate in it, respectively. Both concepts are subclasses of the Item concept, and
Staff Learner
disjoint partition
<xs:complexType name="learnerType">
<xs:sequence>
<xs:element ref="title" minOccurs="0"/>
<xs:element ref="information" minOccurs="0"/>
<xs:element ref="learner" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="metadata" minOccurs="0"/>
</xs:sequence>
<xs:attributeGroup ref="attr.role"/>
</xs:complexType>
<xs:attributeGroup name="attr.role">
<xs:attributeGroup ref="attr.create-new"/>
<xs:attributeGroup ref="attr.href"/>
<xs:attributeGroup ref="attr.identifier.req"/>
<xs:attributeGroup ref="attr.match-persons"/>
<xs:attributeGroup ref="attr.min-persons"/>
<xs:attributeGroup ref="attr.max-persons"/>
</xs:attributeGroup>
XML-Schema specification
<owl:Class rdf:ID="Role">
<rdfs:subClassOf>
<owl:Restriction>
<owl:cardinality rdf:datatype="#int">1</owl:cardinality>
<owl:onProperty>
<owl:DatatypeProperty rdf:ID="identifier"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Learner">
<rdfs:subClassOf>
<owl:Class rdf:ID="Role"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="Staff"/>
</owl:disjointWith>
</owl:Class>
Role
OWL specification

Figure 1. Comparison between the OWL and XML-Schema specifications

A Learning Design Ontology based on the IMS Specification
207
therefore they will be mapped onto the Learning objective and Prerequisite concepts of the
Resource hierarchy.



Figure 2. Upper concepts of the Learning Design ontology.

The Learning Design concept has a number of Components used to describe the learning process:
the Execution Entities to be carried out, which can be Activities or Activity Struc-
tures (groups of activities that will be executed in sequence); the Roles that participate in the execu-
tion of those activities as instances of the Learner and Staff concepts; and the Environments that
describe the educational resources to be used in the activities. These concepts constitute an exhaustive and
disjoint partition, because an instance of a Component must necessarily be an instance of one of its sub-
classes.

The Learning Design concept is also related to the Method concept, which describes the dynamics
of the learning process (Figure 3): a method is composed of a number of instances of the Play concept
that could be interpreted as the runscript for the execution of the unit of learning. All the play instances
have to be executed in parallel, and each one consists of Act instances, which could be understood as a
stage of a course or module. The Act instances must be executed in sequence (according to the values of
the execution order attribute), and they are composed by a number of Role Part instances that
will be executed concurrently. A Role Part associates a Role(s) with an Execution Entity to
be carried out in the context of the act. Finally, every Execution Entity requires an Environ-
ment, which manages Learning Objects as resources. In summary, the execution of an act consists
on the simultaneous participation of roles in an activity or group of activities, and once the activities are
completed, the associated roles could participate in the execution of any other activity through different
role part instances.

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
208

Figure 3. Concept taxonomy that describes the dynamics of a learning design


The Activity concept has two subclasses: the Learning Activity concept and the Support
Activity concept. A Learning Activity models an educational activity that establishes a relation
with the Prerequisite and the Learning Objective concepts. The Support Activity,
however, is introduced to facilitate the execution of a learning activity, but it does not cover any learning
objective. These two classes constitute a disjoint and exhaustive partition, because an instance of the Ac-
tivity concept should be either a learning or a support activity.

Every concept involved in the dynamics of the learning process (Method, Play, Act, and Activity)
establishes a relation with one of the subclasses of the Complete Unit concept, which indicates when
an execution is finished. In the IMS LD Level A, this condition can be specified through the time
limit attribute, which define the temporal duration of the execution, or referred to an instance of the
entity of which is composed by. For example, an act would be completed when the instance of the Role
Part indicated by the relation when-role-part-completed has finished. Furthermore, in both
Level B and C of IMS LD, the modelling of these subclasses will be extended to enable the specification
of more complex completion conditions.

A Learning Design Ontology based on the IMS Specification
209
3.2. DESCRIPTION OF THE LEARNING DESIGN ONTOLOGY AXIOMS

From a modelling point of view, the formal definition of the semantic constraints of the LD concepts is the
main advantage of the learning design ontology when compared with the IMS LD XML-Schema specifi-
cation. On one hand, the semantics of the concepts is completely included in the ontology (not only the
taxonomic structure), and, on the other hand, the programmers of LD software systems will not need to
understand the descriptions of the IMS LD models in order to translate its meaning in sentences of pro-
gramming code.

The three models of the IMS LD specification contain a natural language description of the semantics of
all the taxonomy concepts, including the constraints that should verify their instances when created and
managed by a software system. To incorporate these restrictions to the LD ontology we have applied the
following procedure: first, the description of the constraints is identified in the text of IMS LD; then, if
necessary, this description is reformulated considering the elements of the LD concept taxonomy (con-
cepts, relations, and attributes); and, finally, the restrictions are represented in a declarative, formal, and
language-independent way as axioms declared in first order logic. Following this procedure, we have iden-
tified and formalized a number of axioms that can be classified depending on the phase where the axioms
are applied. Thus, two general kinds of axioms are distinguished (Figure 4): design axioms and runtime
axioms.

On one hand, runtime axioms are associated with the management and monitoring of the execution of the
learning design created during the design phase. For example, one of the axioms of this category should
guarantee that the plays that compose a method will be executed in parallel. However, to specify many of
these axioms it is necessary to extend the LD ontology for including a runtime model (not defined in the
IMS LD specification) that would represent the different states of execution of the learning design. Most
of these axioms have been extracted from the behavioural model.



Design
axioms
(20)
Role
axioms
(4)
Activity
axioms
(4)
Runtime
axioms
IMS LD
axioms
Time limit
axioms
(5)
Completion
axioms
(8)
Complete
entity axioms
(3)
Visibility
axioms
(4)

Figure 4. Classification of the axioms identified in the IMS LD ontology.


On the other hand, design axioms determine how the instances of the taxonomy concepts will be created
when a given learning design has been specified. For example, the first axiom of Table 2 will not allow to
create a method with a value for the time limit attribute less than the time limit of any of its plays. This
kind of axioms guarantee the consistence of all the components of the design created for modelling a unit
of learning. Currently, we have extracted and formally defined 20 axioms, most of them from the IMS LD
concept and information models. In this paper, we will focus on the description of this kind of axioms.

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
210
Design Axiom Description

The axioms have been specified in first order logic as sentences made up with: an antecedent, which con-
tains the conditions to be verified, and a consequent, which describes the constraints to be applied to the
concepts, attributes or relations of the ontology (these ontology elements are the universe of discourse).
According to this, the axioms could be classified on the basis of the ontology elements whose values or
relations are affected by the axiom’s consequent part. The following types have been identified (Figure 4)
completion axioms, role axioms, visibility axioms, and activity-related axioms.

The completion axioms are obtained from the restrictions related to the ending conditions of the elements
involved in the runscript (Method, Play, Act and Role-Part). Particularly, these axioms specify
both the values of the attributes and relation range associated to the sub-lasses of the Complete Unit
concept. Considering this, two kinds of completion axioms could be distinguished (Figure 4): time limit
axioms, and entity completion axioms.

The entity completion axioms (Table 1) will restrict the instances of the concepts associated to the range of
the relations when-last-act-completed, when-play-completed, and when-role-part-
completed, which indicate what are the runscript elements, REI, whose execution marks the ending of a
given runscript element, REG. Taking this into account, this kind of axioms establishes that REI must be
necessarily a subset of the runscript elements executed in the context of REG.

IMS LD
Specification
Page 42 (item 0.4.1): “This element states that an act is completed when the referenced role-part(s) is (are) completed.
More than one role-part can be selected, meaning that all the referenced role-parts must be completed before the act is
completed.”
Explanation The Role Part(s) referred as the value of the attribute when-role-part-completed of an Act must be a subset of the Role Part(s) associated to the Act.
1
Formal
Description
∀ a, ca, rp ⏐a ∈ Act ∧ ca ∈ Complete-Act ∧ complete-act-ref(ca, a) ∧ rp ∈ Role-Part ∧ when-role-part-completed(rp,
ca) → role-part-ref(rp, a)
IMS LD
Specification Page 40 (item 0.5.1): “This element states that a play is completed when the last act is completed.”
Explanation The Act referred as the value of the attribute when-last-act-completed of a Play must be one of the Acts associated to the Play. 2
Formal
Description
∀ p, cp, a ⏐ p ∈ Play ∧ cp ∈ Complete-Play ∧ complete-play-ref(cp, p) ∧ a ∈ Act ∧
when-last-act-completed(a, cp) → act-ref(a, p)
IMS LD
Specification
Page 38 (item 0.4.1): “This element states that an unit-of-learning is completed when the referenced play(s) is (are)
completed. More than one play can be selected, meaning that all the referenced plays must be completed before the
unit-of-learning is completed.”
Explanation The Play(s) referred as the valued of the attribute when-role-part-completed of a Method must be a subset of the Plays associated to the Method.
3
Formal
Description
∀ m, p, cm ⏐ m ∈ Method ∧ p ∈ Play ∧ cm ∈ Complete-Method ∧ complete-method-ref(cm, m) ∧
when-play-completed(p, cm) → play-ref(p, m)
Table 1. Formal definition of the entity completion axioms.

A Learning Design Ontology based on the IMS Specification
211

IMS LD
Specification
Page 38 (item 0): “The method contains a sequence of elements for the definition of the dynamics of the learning
process. It consists of one or more play(s).”
Page 38 (item 0.2.2): “The time limit specifies that it is completed when a certain amount of time has passed, relative
to the start of the run of the current unit of learning. The time is always counted relative to the time when the run of
the unit-of-learning has started. Authors have to take care that the time limits of role-parts, acts and plays are logical.”
Explanation
The value of the attribute time limit associated to a Method (through its Complete Method) must be greater
than the value of the time-limit associated to any Play (through its Complete Play) that is executed in the
context of the Method. That is, the Plays cannot finish after the Method.
4
Formal
Description
∀ m, p, cm, cp ⏐ m ∈ Method ∧ p ∈ Play ∧ cm ∈ Complete-Method ∧ cp ∈ Complete-Play ∧ play-ref(p, m) ∧
complete-unit-of-learning-ref(cm, m) ∧ complete-play-ref(cp, p) → time-limit(cm) ≥ time-limit(cp)
IMS LD
Specification
Page 39 (item 0): “A Play consists of a series of acts and an act consists of a series of role-parts. When there is more
than one play, these are interpreted concurrently and independent of each other.”
Page 40 (item 0.5.2): As the item 0.2.2 in page 38.
Explanation
The value of the attribute time-limit associated to a Play (through its Complete Play) must be greater or
equal than the value of the time limit associated to any Act (through its Complete Act) that is executed in
the context of the Play. That is, an Act cannot finish after the Play.
5
Formal
Description
∀ p, cp, a, ca ⏐p ∈ Play ∧ cp ∈ Complete-Play ∧ complete-play-ref(cp, p) ∧ a ∈ Act ∧ ca ∈ Complete-Act ∧
complete-act-ref(ca, a) ∧ act-ref(a, p) → time-limit(cp) ≥ time-limit(ca)
IMS LD
Specification
Page 42 (item 0.4.2): As the item 0.2.2 in page 38.
Page 41 (item 0.3): “A play consists of a series of acts and an act consists of a series of role-parts. A role-part relates
exactly one role to exactly one type of activity (including the performance of another unit-of-learning and activity-
structures). Role-parts within one act, are performed concurrently.”
Explanation
The value of the attribute time limit associated to an Act (through its Complete Act) must be greater than
the value of the time-limit associated to any Activity related to a Role-Part that is executed in the context
of the Act. That is, the Role-Parts cannot finish after the Act.
6
Formal
Description
∀ a, ca, actv, as, rp ⏐a ∈ Act ∧ ca ∈ Complete-Act ∧ complete-act-ref(ca, a) ∧ rp ∈ Role-Part ∧ role-part-ref(a, rp)
∧ actv ∈ Activity ∧ cactv ∈ Complete-Activity ∧ complete-activity-ref(cactv, actv) ∧ as ∈ Activity-Structure ∧
(execution-entity-ref(actv, rp) ∨ (execution-entity-ref(as, rp) ∧ execution-entity-ref(actv, as))) → time-limit(ca) ≥
time-limit(cactv)
IMS LD
Specification
Page 41 (item 0): “When there is more than one act in a play, these are presented in sequence from first act to last act.
Only one act in a play is the active act at any moment in time, starting with the first. When the first act is completed,
the second act is made the active act. When the second act is completed, the third act is made active, etc.”
Explanation
If the value of the attribute execution-order of an Act is greater than the value of the execution-order for
other Act, and both Acts are executed in the context of a same Play, the value of the attribute time-limit
associated to the first Act (through its Complete Act) is greater than the value of the attribute for the second Act.
7
Formal
Description
∀ p, a, b, ca, cb ⏐ p ∈ Play ∧ a, b ∈ Act ∧ act-ref(a, p) ∧ act-ref(b, p) ∧ ca, cb ∈ Complete-Act ∧ complete-act-ref(ca,
a) ∧ complete-act-ref(cb, b) ∧ (execution-order(a) ≥ execution-order(b)) → time-limit(ca) ≥ time-limit(cb)
IMS LD
Specification Page 31 (item 0): “An activity structure groups activities in sequences or selections.”
Explanation
If the value of the attribute structure-type of an Activity Structure is “sequence”, and there are two
activities executed in the context of the same Activity Structure with consecutive values for the attribute
execution order, the value of the attribute time limit associated to these Activities must be consistent
with the values of the execution order attribute.
8
Formal
Description
∀ as, a, ca, b, cb ⏐ as ∈ Activity-Structure ∧ structure-type(as) = “sequence” ∧ a, b ∈ Activity ∧
execution-entity-ref(a, as) ∧ execution-entity-ref(b, as) ∧ complete-activity-ref(ca, a) ∧ complete-activity-ref(cb, b) ∧
(execution-order(a) = execution-order(b) + 1) → time-limit(ca) ≥ time-limit(cb)

Table 2. Formal definition of the time limit axioms.

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
212

The time limit axioms (Table 2) constrain the possible values of the attribute time-limit that indicates
the time interval in which a runscript element is executed. Following the IMS LD specification, for any
runscript element the origin of this interval will be the time instant associated to the beginning of the unit
of learning. Taking this into account, this kind of axioms establishes that: if the time-limit attribute of
the Complete Unit related with a runscript element REI has assigned a value, it must be necessarily
greater than the values of the attribute of the Complete Units related to the runscript elements exe-
cuted in the context of REI (axioms 4 to 6); and the values of the time-limit attribute for the Com-
plete Unit concept must be consistent with the values of the execution-order and struc-
ture-type attributes associated with the Acts and Activity Structures concepts respectively
(axioms 7 and 8). These axioms guarantee the correct design of the runscript elements whose execution is
in sequence.
IMS LD
Specification
Page 83 (item 17): “Environments are connected to activities, activity-structures or roles (in a role-part). When
an activity-description is visible, always the connected environment (including the content structure of the envi-
ronment) must be made visible. It must be possible to access and see the activity-description and the content of
one of the objects or services within the environment at the same time.”
Explanation
When the value of the isvisible attribute of an Activity Description is “true”, the value of that
attribute for the Environments connected to the Activity associated to the Activity Description
must be also true.
9
Formal
Description
∀ a, ad, e, lo, s ⏐ a ∈ Activity ∧ ad ∈ Activity-Description ∧ activity-description-ref(ad, a) ∧ e ∈ Environment
∧ lo ∈ Learning-Object ∧ s ∈ Service ∧ learning-object-ref(lo, e) ∧ service-ref(s, e) environment-ref(e, a) ∧
isvisible(ad) = “true” → isvisible(lo) = “true” ∧ isvisible(s) = “true”
IMS LD
Specification
Page 94 (item 6): “When a role is tagged to allow for the creation of new roles, the visibility rules and the users
for the parent are applied to the children.”
Explanation
If the value of the attribute create-new of the Role is “allow”, the values of the attribute isvisible of the
activities related to the Role are the same as the values of the attribute isvisible of the activities related to
the (sub) Roles of that Role. 10
Formal
Description
∀ r, r1, rp, rp1, a, a1, as ⏐ r ∈ Role ∧ r1 ⊂ r ∧ create-new(r) = “allow” ∧ rp, rp1 ∈ Role-Part ∧ role-ref(r, rp) ∧
role-ref(r1, rp1) ∧ a, a1 ∈ Activity ∧ as ∈ Activity-Structure ∧ (execution-entity-ref(a, rp) ∨
(execution-entity-ref(as, rp) ∧ execution-entity-ref(a, as))) ∧ (execution-entity-ref(a1, rp1) ∨
(execution-entity-ref(as, rp1) ∧ execution-entity-ref(a1, as)) ∧ a = a1 → isvisible(a) = isvisible(a1)
IMS LD
Specification
Page 16: “When an activity-structure references one or more environments, then these will overrule the envi-
ronments specified within the referenced activities.”
Explanation
The value of the attribute isvisible for the Learning Objects and Services of an Environment
associated to an Activity must be “false” when there are Learning Objects and Services of an En-
vironment associated to an Activity Structure in which such Activity is executed.
11
Formal
Description
∀ as, a, e, e1, e2 ⏐ as ∈ Activity-Structure ∧ a ∈ Activity ∧ execution-entity-ref (a, as) ∧ e ∈ Environment ∧
e1, e2 ∈ e ∧ environment-ref(e1, as) ∧ environment-ref(e2, a) ∧ (∃ lo1, lo2⏐ lo1, lo2 ∈ Learning-Object ∧
learning-object-ref(lo1, e1) ∧ learning-object-ref(lo2, e2)) → isvisible(lo2) = “false”

∀ as, a, e, e1, e2 ⏐ as ∈ Activity-Structure ∧ a ∈ Activity ∧ execution-entity-ref (a, as) ∧ e ∈ Environment ∧
e1, e2 ∈ e ∧ environment-ref(e1, as) ∧ environment-ref(e2, a) ∧ (∃ s1, s2⏐ s1, s2 ∈ Service ∧ service-ref(s1, e1)
∧ service-ref(s2, e2) → isvisible(s2) = “false”
IMS LD
Specification
Page 83 (item 12): “The learning-design/learning-objectives/item(s) and /prerequisites/items(s) must be accessi-
ble for all the roles, at all times in the user-interface.”
Explanation The value of the attribute isvisible of the Prerequisites and Learning Objectives associated to the Learning Design concept must be “true”. 12
Formal
Description
∀ ld, lg, pr ⏐ ld ∈ Learning-Design ∧ lg ∈ Learning-Objective ∧ pr ∈ Prerequisite ∧ prerequisite-ref(pr, ld) ∧
learning-objective-ref(lg, ld) ∧ isvisible(ld) = “true” → isvisible(lg) = “true” ∧ isvisible(pr) = “true”
Table 3. Formal definition of the visibility axioms.

A Learning Design Ontology based on the IMS Specification
213

The visibility axioms (Table 3) restrict the value of the attribute isvisible associated to the learning
design elements, establishing the conditions under which they can be accessible to the user through a
graphical interface. Based on that, these axioms determine the value of the attribute isvisible for the
following elements: the Activities executed in the context of an Activity Structure (axiom
9); the Environments used in the execution of either Activity Structures or Activities
(axioms 10 and 11); and the Prerequisites and Learning Objectives related to the learning
design (axiom 12). This kind of axioms must be also applied in the runtime phase as the visibility con-
straints have to be guaranteed during the execution of the unit of learning.

The role axioms (Table 4 constrain how the instances of the Role concept must be created in the learning
design. Thus, depending on the values of the Role attributes (match-persons, min-persons, and
create-new), a number of instances of that concept could be created (axioms 14 and 15). Furthermore,
there are instances that restrict how the Role instances can be used in the definition of the other learning
elements (axiom 16). The role axioms are also applied to the subclasses of Roles that typically are cre-
IMS LD
Specification
Page 25 (item 0.2.6): “Specifies the minimum number of persons bound to the role before starting a run. When the
attribute min-persons and max-persons are empty, there are no restrictions. When used, the following rule applies:
0 <= min-persons <= max-persons.”
Explanation The value of the attribute max-persons of a Role must be greater than the value of the attribute min-persons of that Role.
13
Formal
Description ∀ r⏐r ∈ Role → max-persons(r) ≥ min-persons(r)
IMS LD
Specification
Page 25 (item 0.2.1): “This attribute [create-new] indicates whether multiple occurrences of this role may be created
during runtime. When the attribute has the value "not-allowed" then there is always one and only one instance of the
role.”
Explanation If the value of the attribute create-new of a Role is “not allowed”, there is a unique instance of that Role.
14
Formal
Description ∀ r ⏐ r ∈ Role ∧ create-new(r) = “not-allowed” → ¬ ∃ r1 ⏐ r1 ∈ r
IMS LD
Specification
Page 25 (item 0.2.4): “This attribute is used when there are several sub roles (e.g. chair, secretary, member). Persons
can be matched exclusively to the sub roles, meaning that a person, who has the role of chair, may not be bound to
one of the other roles at the same time.”
Explanation If a Role has (sub) Roles and the value of the attribute match persons of that Role is “exclusively-in-roles”, the (sub) Roles must be disjoint.
15
Formal
Description
∀ r, r1, r2, p1, p2 ⏐ r ∈ Role ∧ match-persons(r) = “exclusively-in-roles” ∧ r1, r2 ∈ r ∧ p1, p2 ∈ Person ∧ p1 ∈ r1 ∧
p1 ∈ r1 → p1 ≠ p2
IMS LD
Specification
Page 90: “The same role can be associated with different activities or environments in different role-parts, and the
same activity or environment can be associated with different roles in different role-parts. However, the same role
may only be referenced once in the same act. If multiple activities or environments need to be associated for the same
role an activity-structure or wrapper environment should be used.”
Explanation For a same Act, a given instance of a Role can just appear once in the Role Parts executed in the context of that
Act.
16
Formal
Description
∀ a, r, rp ⏐ a ∈ Act ∧ r ∈ Role ∧ rp ∈ Role-Part ∧ role-part-ref(rp, a) ∧ role- ref(r, rp) → ¬ ∃ rp1 ⏐ rp1 ∈ Role-Part ∧
rp1 ≠ rp ∧ role-part-ref(rp1, a) ∧ role-ref(r, rp1)
Table 4. Formal definition of the role axioms.

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
214
ated to specify different categories of teachers or users of the Services managed the Environments
associated to the Execution Entities of the learning design.

Finally, the activity axioms (Table 5) constrain the relations between the Execution Entities and
the other components of the learning design. Thus, there are axioms to determine what Roles are in-
volved in the Support Activities (axioms 17 and 18), to restrict the values of the attributes of the
Activity Structure concept (axiom 19), and to constrain the relation between the Acts and the
Execution Entities of a given design (axiom 20).







IMS LD
Specification
Page 29 (item 0): “When the optional role-ref element is set, it is expected that the support activity will act for every
single user in the specified role(s). That is: the same support activity is repeated for every user in the role(s).”
Explanation
If a Support Activity has assigned a Role (that is, the attribute role-ref has a value), this activity will be
executed by all the instances of the subclasses of such Role. On the other hand, it is necessary to define a Role-
Part for each subclass of the Role that is applied to the Support Activity. 17
Formal
Description
∀ a, rp, sa, r, p ⏐ a ∈ Act ∧ rp ∈ Role-Part ∧ role-part-ref(rp, a) ∧ sa ∈ Support-Activity ∧ r ∈ Role ∧ role-ref(r, sa)
→ ∃ r1, rp1 ⏐ rp1 ∈ Role-Part ∧ role-part-ref(rp1, a) ∧ r1 ∈ r ∧ role-ref(r1, rp1) ∧ execution-entity-ref(sa, rp1)
∀ sa, r, r1 ⏐ sa ∈ Support-Activity ∧ r ∈ Role ∧ role-ref(r, sa) ∧ r1 ∈ r → role-ref(r, rp)
IMS LD
Specification
Page 29 (item 0): “When the role-ref is not available, the support activity is a single activity (like the learning-
activity).”
Explanation If a Support Activity has not assigned a Role (that is, the attribute role-ref has not a value), it will be considered as a simple Activity, and there would not be applied to every instance of the Role. 18
Formal
Description
∀ rp, sa, r, as ⏐ rp ∈ Role-Part ∧ sa ∈ Support-Activity ∧ as ∈ Activity-Structure ∧ r ∈ Role → ¬ ∃ r1 ⏐ r1 ∈ r ∧
role-ref(r1, rp) ∧ (execution-entity-ref(sa, rp) ∨ (execution-entity-ref(as, rp) ∧ execution-entity(sa, as)))
IMS LD
Specification
Page 31 (item 0): “When the attribute 'number-to-select' is set, the activity-structure is completed when the number of
activities completed equals the number set. The number-to-select must be the same as or smaller than the number of
activities (including unit-of-learnings) which are at the immediate child level.”
Explanation
The value of the attribute number to select of the Activity Structure must be smaller than the number
of the Activities of that Activity Structure. To express this axioms it is necessary to define a variable that
is the number of Activities of which an Activity Structure is composed of.
19
Formal
Description
∃ na ∈ Integer ⏐na = 0 → ¬ ∃ as, a ⏐as ∈ Activity-Structure ∧ a ∈ Activity ∧ execution-entity-ref(a, as)
∀ as, a⏐as ∈ Activity-Structure ∧ a ∈ Activity ∧ execution-entity-ref(a, as) → na = na + 1
∀ as⏐as ∈ Activity-Structure ∧ number-to-select(as) ≤ na
IMS LD
Specification
Page 76: “Each role-part associates exactly one role with exactly one type of activity (including the performance of
another unit-of-learning and activity-structures), or with one environment (equivalent to an organization in Content
Packaging).”
Explanation
In an Act must exist at least an Role Part that has assigned an Activity or Activity Structure. If this
axiom is not included in the ontology specification, it could be possible that all the Role Parts of an Act establish
relations with the Environment, which is not an Execution Entity and, therefore, does not define any ending
condition (through the when-role-part-completed or time-limit attributes).
20
Formal
Description
∀ act ⏐ act ∈ Act → ∃ rp, as, a ⏐ rp ∈ Role-Part ∧ role-part-ref(rp, act) ∧ as ∈ Activity-Structure ∧ a ∈ Activity ∧
(execution-entity(a, rp) ∨ (execution-entity(as, rp) ∧ execution-entity(a, as)))
Table 5. Formal definition of the activity axioms.

A Learning Design Ontology based on the IMS Specification
215
3.3. MODELLING ISSUES OF THE LEARNING DESIGN ONTOLOGY

− The learning design ontology has been developed for describing semantically every element of the
IMS LD specification, solving the drawbacks of its representation in XML-Schema. In this develop-
ment, new classes (or concepts) were introduced with the aim of improving the modelling of the IMS
LD elements, but these classes do not add new learning elements that would extend the IMS LD speci-
fication (such as an ontology of educational organizations). In fact, it would be possible to carry out a
straightforward translation from the XML-Schema representation of the IMS LD into the learning de-
sign ontology, and vice versa. Considering this, these new classes would be translated foin the follow-
ing way:The Execution-Entity, Complete-Unit and Item classes are abstract, which
means that they are not inostantiated when a learning design is specified. Therefore, these three classes
will not be translated, because they are not considered as part of a given learning design, and they were
introduced in the LD ontology to improve the structure of the taxonomy by taken advantage of the in-
heritance and subsumption mechanisms (particularly useful for description logic reasoners).
− All the subclasses of the abstract classes are directly related to an XML-Schema element, or groups of
elements, that represents an entity of the IMS LD specification: both ontology classes and XML-
Schema elements have the same attributes, which means that the translation between them will be
straightforward. Nevertheless, in the translation from the ontology classes into XML-Schema, there
exist semantic (or knowledge) loss because the ontology classes are more expressive.

To improve the semantic description of the taxonomy concepts of the LD ontology and increase the rea-
soning capabilities of the ontology, taxonomic (such as disjoint and exhaustive) and mathematical (such as
inverse, symmetric and transitive) properties of relations have also been added to the LD ontology. How-
ever, these properties cannot be considered extensions of the IMS LD specification, because they do not
introduce new elements of the learning design.

Finally, the axioms formulated in the LD ontology are the formal specification of the constraints among
the elements of a learning design. In the IMS LD specification these constraints are expressed in natural
language, while in the LD ontology they are represented in first order logic. Therefore, the axioms of the
ontology are not an extension of the IMS LD specification either: they are the same entities represented in
a different way.

4. MODELLING EXAMPLE: DESCRIPTION OF THE JIGSAW METHODO-
LOGY

Cooperative learning is a technique in which learning is achieved by means of group activities. In this type
of learning, the acquisition of knowledge and skills comes about as the result of the interaction among
groups, being based on aspects such as individual responsibility, positive interdependence (each individual
depends on all the others fin order to success) and the development of the interpersonal abilities that are
necessary in real life situations. With the use of cooperative learning techniques, educational processes
may obtain many benefits from the perspective of motivation, cognoscence and social cohesion (Sub,
1995). Broadly speaking, cooperation-based teaching/learning processes can be organized according to the
following procedures:

1. The didactic objectives are presented to the students.
2. An initial assessment is made.
3. The objectives of each group are defined.
4. The content and evaluation criteria are explained in detail.
5. The groups carry out the activity.
6. The students evaluate each other’s work.
7. The professor provides an individual evaluation.
8. Each group is evaluated.
9. Those groups that failed on achieving the objectives are reorganized.

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
216
There are various didactic techniques aimed at establishing cooperational relationships during learning
activities: jigsaws, investigation groups, STAD (Student Team-Achievement Divisions) technique, TGT
(Teams-Games Tournaments) and peer tutorship. To demonstrate the application of the IMS-LD ontology,
the Jigsaw methodology has been chosen (Figure 5). Besides its popularity, this technique is suitable to
understand how cooperation-based learning activities are carried out in activities that can easily be broken
down into their constituent parts. In short, the Jigsaw follows the general procedure described above, or-
ganizing the students into groups of 4 or 5 individuals, and assigning different learning material to each
member of the group, so that each student receives a fragment of the information of any given topic that is
the matter of the study. Each member prepares the topic with his personal material, joining up with the
members of the other groups who have the same topic. After that, he returns to his own group in order to
explain and discuss the topic along with the other members.




Figure 5. Definition of the Method, Plays and Acts of the Jigsaw example.

A Learning Design Ontology based on the IMS Specification
217
As it can be seen in Figure 5, the Method representing the Jigsaw approach has a Play made up of a set
of Acts, which are executed in sequence. Each Act comprises a set of concurrent Role Parts that
relates roles (professor, student, etc.) with activities. The Complete Act concept is used to control the
end of an Act, either stating the maximum time for the realization of the Act, or the associated Role
Parts that must be completed. For example, the First-Moment Act refers to the activities to be per-
formed during the initial stage of the Jigsaw (corresponding to the general steps 1-4 described above ) and
is made up of two Role Parts (Ap_Work and In_Att). A relation jsfm-wrpc:when-role-part-completed
between the instances jsfm-cp of Complete Act and In_Att of Role Part is used to indicate when
this Act is completed. In this Act, the professor carries out the following activities with the groups: ob-
jectives presentation, in which he explains the topic of the subject; student assessment, in which an as-
sessment in order to verify the students' prospects and needs is carried out; group creation, in which the
activities to be realized and the rules and criteria of the evaluation are explained. These activities are rep-
resented by a series of Support or Learning Activities that are grouped into Activity
Structures. Each Role Part associates a single Support Activity, Learning Activity
or Activity Structure to a certain Role, as it is shown in Figure 6. An activity Structure
is completed when the value of the number-to-select attribute is equal to the number of the activi-
ties in the set that have been completed. In the example shown in Figure 6, Ap-Wrk-AS will be completed
when 6 activities have been completed.

The two Acts following the First-Moment are the key moments in the Jigsaw technique. The Jigsaw Part
1 comes when the groups are formed with students with the same study topic. Each topic is a part of the
whole subject to be studied, around which the students carry out the activities according to the information
that has been supplied by the professor. In the Jigsaw Part 2 each group comprises students that, collec-
tively, possess all the study material. In this Act, each student explains the topic that he has previously
studied to the rest of the group. In parallel, the professor monitors and guides the activities carried out by
each group.

The Acts and Role-Parts shown in Figures 5 and 6 partially represent the dynamics of the educa-
tional process. Using Activity-Structures this dynamics can be described in much more detail,
according to workflows determining the way in which Support and Learning Activity will be
executed in an educational process. Figure 7 shows the order and conditions in which the activities of the
professor and the groups are carried out in the First-Moment Act.
Figure 6. Definition of the Role Parts of the Jigsaw example.

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
218
The order in which the activities in an Activity Structure are carried out is determined by means
of the execution-order and structure-type attributes. The Activity Structure Ap-Wrk-
AS, associated with the professor, presents a structure-type attribute with value “sequence”, indicat-
ing that the professor executes the Support Activity in a sequence, while the Activity Struc-
ture In-Att-AS, related to the groups, shows a “selection” value, indicating that the order of execution
depends on a parameter. In this case, the order of the students' activities depends on the professor. Using
the Complete Activity concept, activities may be completed by a decision of the role, or at the end
of a given time. The support activity Introduction is completed with a decision made by the pro-
fessor (setting the user-choice attribute), and the Support Activity Initial-Evaluation is com-
pleted after the completion of a given time interval (setting the time-limit attribute). The Support
Activities Introduction and Explain-Rules determine the beginning of the Learning Activi-
ties Introduction and Clarify-Doubts. When an activity is finished, an action to be carried out can be
indicated with the Completion Unit and Feedback Description concepts, which are related by
the completion-ref relation. For example, with these concepts, a resource can be assigned to present infor-
mation regarding activity feedback. This may be highly useful when considering the individual reforming
of those groups that did not attain the objectives, or when considering future activities.

Figure 7. Definition of the Activity Structures of the Jigsaw example.

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
220

Figure 9. Protégé and OWL description of the IMS LD ontology

The EUME agents use the IMS LD ontology as a common language to manage the information about the
educational resources available in the environment. This is done by means of a set of JADE classes that
were implemented to enable the agents (1) to manage the OWL code, and (2) then to generate messages in
accordance with the FIPA-SL style sheet. Figure 10 illustrates the mechanism by describing how the de-
scription of a certain Activity is requested. The client agent (A/C) defines a template (FIPA-SL) according
to this request, which is sent to the service agent (Search A/S) in the Services tier. After that, this agent
generates another template to communicate with the specific resource to access the database.

A Learning Design Ontology based on the IMS Specification
221
The EUME system is intended to facilitate the design and realization of different learning activities. The
process begins with the professor specifying the learning design by using the out-of-classroom interface, a
web interface that enables the introduction of Units of Learning and their corresponding Meth-
ods, Plays as well as other learning design elements. Figure 11 shows a screenshot of this web interface
to illustrate the introduction of a number of Activities (Introduction, Verify-level and Present-
Doubts) associated to the Presentation Act of a Java Programming Overview Play. For each Activ-
ity, a Powerpoint file was selected as a Learning Object resource. Once this design stage is com-
pleted, the learning activities are ready to be used in the classroom. Here, the professor uses a PDA inter-
face, which contains the agent client to control the available hardware and software resources as well as to
access the learning elements previously designed. After log into the system (Figure 12 A), the EUME
agents automatically retrieve the information from the database and show the Activities associated to
the current Java Programming Overview Play (Figures 12 B-C).

Finally, the LD ontology could be also used in a learning management system that implements the IMS
LD specification following the XML-Schema language. In such case, a translator from the ontology (ex-
pressed in OWL) into the XML-Schema representation, and vice versa, would be required. For instance, in
a service oriented architecture, the translation operation could be offered by a Web service that would re-
ceive SOAP messages whose content is (part of) the ontology to be translated, and would send the result
of the translation.

Figure 9. Protégé and OWL description of the IMS LD ontology



Figure 10. Mechanism to request an Activity in EUME.

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
222

6. DISCUSSION AND FUTURE WORK

The IMS LD specification is expressive enough from the point of view of the learning process designers.
Nevertheless, the informal specification of the IMS information and behavioural models increases the
complexity of the IMS LD to be understood by programmers, as they are not usually educational special-
ists. This complexity could provoke misinterpretations and, even, errors when the IMS LD specification is
incorporated to the development of applications.

The XML-Schema language is not enough expressive to represent al the knowledge compiled in the three
models of the IMS LD specification. Mainly, hierarchical taxonomies, relation properties, and semantic
constraints between the learning design elements cannot be represented in XML-Schema. To solve these
limitations, the software system used to design and execute the unit of learning could codify the semantics
of the specification in the programming language in which it is developed. This strategy has been followed
by the Reload (JIST, 2004) and CopperCore (Vogten & Martens, 2004) environments to allow to users the
design and execution of a unit of learning respectively. However, the main drawback of this approach is
that the software programs are not easy to maintain, because of if the IMS LD specification is modified, it
would be needed to re-codify the programs for including such modifications.

These two issues are solved with the learning design ontology. On one hand, as the semantics of the con-
cepts is precisely defined, there should be no misinterpretations or errors when the instances of the con-
cepts are created and managed in runtime. In this sense, new concepts, attributes/relations, and formal
axioms have been identified and formalized in the ontology. It is important to emphasize that these add-
ons neither change nor extend the IMS LD specification, but they enrich the description of the semantics
of the IMS LD elements. On the other hand, as the semantics of the IMS LD specification is explicitly
described, it is not necessary to codify such semantics in the development of the software program that
allow to users to design and execute the unit of learning. Thus, general reasoner following the logic para-
digm associated to the language in which the ontology is represented can be used to check the consistence
of the unit of learning in both the design and runtime phases. For example, we can use a reasoner in de-
scription logic (like Pellet or Racer) to carry out inferences with the learning design ontology expressed in
OWL.

The main drawback of the LD ontology is focused on the limitations of the expressiveness and reasoning
capabilities of the ontology representation languages. For example, if the goal of an application is to guar-
antee that the edition and execution of the learning design satisfies the IMS LD specification, the OWL
language would not be the best choice as it currently does not support the definition of axioms that check
constraints between concepts. However, OWL could be an appropriate language for solving the interop-
erability issues between applications.

Figure 11. Interface used to define the Activities of the Jigsaw example.

A Learning Design Ontology based on the IMS Specification
223

As future work we have planned to translate the ontology axioms into SWRL (Horrocks et al., 2004),
which is the language currently proposed to express restrictions in OWL. On the other hand, we are work-
ing on the extension of the ontology to include the concepts and axioms of the levels B and C of the IMS
LD specification.


ACKNOWLEDGMENTS

The authors would like to thank the Xunta de Galicia for their financial support in carrying out this work
under the project PGIDT02TIC20601PR.


REFERENCES

Barros, B., Verdejo, F., Read, T., & Mizoguchi, R. (2002). Applications of a Collaborative Learning On-
tology. Proceedings of the Second Mexican International Conference on Artificial Intelligence (MICAI
2002), Yucatan, Mexico, 301-310.

Brase, J., & Nejdl, W. (2004). Ontologies and Metadata for eLearning. In Staab, S. & Studer, R. (Eds.)
Handbook on Ontologies, Berlin: Springer-Verlag, 555-574.

Brickley, D. (1996). Towards an open question-interchange framework, retrieved 20 May, 2005 from
http://www.ilrt.bris.ac.uk/netquest/about/lang/motivation.html

Dean, M., & Schreiber, G. (editors). (2004). OWL – Web Ontology Language Reference, retrieved May
20, 2005 from http://www.w3.org/TR/owl-ref.

Dublin Core Metadata Initiative. (2003). Dublin Core Metadata Element Set, Version 1.1. Reference De-
scription, retrieved May 20, 2005 from http://dublincore.org/documents/dces.

Gil, Y., & Ratnakar, V. (2002). A Comparison of (Semantic) Markup Languages. Proceedings of the Fif-
teenth International FLAIRS Conference, Pensacola Beach, Florida: AAAI Press, 413-418.

Gómez-Pérez, A., Fernández-López, M., & Corcho, O. (2004). Ontological Engineering, Springer Verlag:
Berlin.

Gruber, T. (1993). T. Gruber, A Translation Approach to Portable Ontology Specifications. Knowledge
Acquisition, 5, 199-220.


Figure 12. In classroom PDA interfaces.

Ricardo R. Amorim, Manuel Lama, Eduardo Sánchez, Adolfo Riera, Xosé A. Vila
224
Horrocks, I., Pater-Schneider, P., Boley, H., Tabet, S., Grosof, B. & Dean, M. (2004). SWRL: A Semantic
Web Rule Language Combining OWL and RuleML, retrieved May 20, 2005 from.
http://www.w3.org/Submission/SWRL.

IEEE Learning Technology Standard Committee (LTSC). Draft Standard for Learning Object Metadata
(LOM), retrieved May 20, 2005 from
http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf.

IMS Global Learning Consortium. (2003a). IMS Learning Design Information Model. Version 1.0 Final
Specification, retrieved 20 May, 2005 from
http://www.imsglobal.org/learningdesign/ldv1p0/imsld_infov1p0.html.

IMS Global Learning Consortium. (2003b). IMS Learning Design Binding. Version 1.0 Final Specifica-
tion, retrieved May 20, 2005 from
http://www.imsglobal.org/learningdesign/ldv1p0/imsld_bindv1p0.html.

Inaba, A., Tamura, T., Ohkubo, R., Ikeda, M., Mizoguchi, R., & Toyoda, J. (2001). Design and Analysis
of Learners Interaction based on Collaborative Learning Ontology. In Dillenbourg, P., Eurelings, A., &
Hakkarainen, K. (Eds.) Proceedings of the Second European Conference on Computer-Supported Col-
laborative Learning (Euro-CSCL'2001), Maastricht, 308-315.

Kabel, S., Wielinga., B., & de How, R. (1999). Ontologies for indexing Technical Manuals for Instruction.
Proceedings of the AIED-Workshop on Ontologies for Intelligent Educational Systems, LeMans,
France, 44-53.

Kiefer, M., Lausen, G., & Wu, J. (1995). Logical Foundations of Object-Oriented and Frame-Based Lan-
guages Journal of ACM, 42:741-843.

Koch, M. (2002). Interoperable Community Platforms and Identity Management in the University Do-
main. International Journal on Media Management, , 4(1), 21-30.

Koper, R. (2001). Modelling units of study from a pedagogical perspective the pedagogical meta-model
behind EML, retrieved May 20, 2005 from http://dspace.learningnetworks.org/retrieve/33/ped-
metamodel.pdf

Noy, N., Fergerson, R., & Musen, M. (2000). The knowledge model of Protege-2000: Combining interop-
erability and flexibility. In Proceedings of the 12th International Conference in Knowledge Engineer-
ing and Knowledge Management (EKAW), Juan Les Pins, France: Springer-Verlag, 450-455.

JIST, Joint Information Services Committee. (2004). RELOAD Editor. Introductory manual, retrieved
May, 20, 2005 from http://www.reload.ac.uk/ex/editor_v1_3_manual.pdf

Rawlings, A., Rosmalen, P., Koper, R., Rodríguez-Artacho, M., & Lefrere, P. (2002). Survey of Educa-
tional Modelling Languages. CEN/ISSS WS/LT Learning Techonologies Workshop.

Riera, A., Sánchez, E., Lama, M., Amorim, R., Vila, X., & Barro, S. (2004). Study of Communication in a
Multi-Agent System for Collaborative Learning Scenarios. Proceedings of the Twelfth Euromicro
Conference on Parallel, Distributed and Network based Processing (PDP2004), A Coruña, Spain:
IEEE Press, 233-240.

Slavin, R. (1995). Cooperative learning: Theory, research, and practice. Allyn & Bacon: Boston.

Sub, C., Burkhard, F., & Brössler, P. (1999). Metamodeling for Web-Based Teachware Management. In
Proceedings of the International WWWCM-Workshop on the World-Wide Web and Conceptual Model-
ing, Paris, France: Springer-Verlag, 360-373.

Rodríguez-Artacho, M., Verdejo, F., Mayorga, J., & Calero, M. (1999). Using a High-Level Language to
Describe and Create Web-Based Learning Scenarios. In Proceedings of the IEEE Frontiers in Educa-
tion Conference (FIE), San Juan, Puerto Rico: IEEE Press.

A Learning Design Ontology based on the IMS Specification
225
Sánchez, E., Lama, M., Amorim, R., Riera, A., Vila, X., & Barro, S. (2003). The EUME Project: Model-
ling and Design of an Intelligent Learning Management System. In Proceedings of the AIED-
Workshop on Intelligent Learning Management Systems, Sydney, Australia, 183-191.

Thompson, H., Beech, D., Maloney, M., & Mendelsohn, N. (2004). XML-Schema Part 1: Structures Sec-
ond Edition, retrieved May 20, 2005 from http://www.w3.org/TR/xmlschema-1.

Verbert, K., & Duval, E. (2004). Towards a global architecture for learning objects: a comparative analy-
sis of learning object content models. In Proceedings of the World Conference on Educational Multi-
media, Hypermedia and Telecommunications (ED-MEDIA), 202-208.

Vogten, H., & Martens, H. (2005). CopperCore 2.2.2, retrieved May 20, 2005 from
http://www.coppercore.org.

Wiley, D. (2000). Learning Object Design and Sequencing Theory. Department of Instructional Psychol-
ogy and Technology, Brigham Young University, Doctoral Thesis.