IMS Learning Design Information Model
Version 1.0 Final Specification
|
IMS Learning Design Information Model Version 1.0 Final Specification |
Copyright © 2003 IMS Global Learning Consortium, Inc. All
Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Learning Design Information Model
Revision: 20 January 2003
IPR and Distribution Notices
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © IMS Global Learning Consortium 2006. All Rights Reserved.
If you wish to distribute this document or use this document to implement a product or service, you must complete a valid license registration with IMS and receive an email from IMS granting the license. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.
This document may be copied and furnished to others by Licensee organizations registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS work group.
Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/learningdesign/ldv1p0/ldv1p0speclicense.html.
The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
This document contains the Learning Design Information Model. It represents an integration of the Educational Modelling Language (EML) work, submitted to the Learning Design working group (LDWG) by the Open University of the Netherlands [LD1], and existing IMS Specifications, notably Content Packaging [LD2] that this specification extends and builds on, but also Meta-Data [LD3] and Simple Sequencing [LD4].
A key task of the LDWG was "the development of a framework that supports pedagogical diversity and innovation, while promoting the exchange and interoperability of e-learning materials".
The OU Netherlands carried out extensive examination and analysis of a wide range of pedagogical approaches prior to developing EML as a relatively concise 'meta-language' that could capture this diversity. Regardless of the pedagogy involved, in practice every learning design came down to: a Method prescribing various Activities for learner and staff Roles in a certain order. Each activity refers to a collection of specific objects and services (called the 'Environment') needed to perform the activity. In order to support the description of individualized learning designs, learner Properties, Conditions, and Notifications are needed. The designs which can be described by this meta-language might involve a single user or multiple users; the learning and instructional designers and providers might take a behaviorist, cognitivist, constructivist, or some other approach; they might require learners to work separately or collaboratively, but the OUNL studies found these could all be captured in terms of a Method containing Roles, Activity-structures, and Environments and a number of other concepts elaborated around these [LD5].
This meta-language approach has the great advantage that, rather than trying to capture the terminology of each approach, which could lead to an indefinitely large vocabulary or set of vocabularies, a single relatively small vocabulary can be used to express what, in concrete terms, each of these approaches asks of the learners and support staff involved. It also allows different pedagogical approaches to be integrated into a single 'learning design' where different approaches may be appropriate for different types of learners.
The language also supports mixed mode delivery ('blended learning'), enabling traditional approaches such as face-to-face teaching, the use of books and journals, lab work, and field trips to be also specified as learning activities and combined with ICT supported learning. What it brings to mixed mode teaching is the ability to specify both kinds of learning in a unit of learning that is itself in digital form.
By being expressive of pedagogical approaches, rather than prescriptive, the language facilitates the development of new pedagogical approaches. To the developer of learning technologies, the meta-language enables pedagogical diversity to be supported through the implementation of a single engine, rather than either having to implement multiple engines for each approach, or remaining 'pedagogically agnostic' by providing no specific support for any.
The remainder of this document sets out the vocabulary of this language, its syntax expressed in terms of its information structures, and its semantics, taken to mean how designs specified in this language should be interpreted in order to give rise to learning activities when instantiated and engaged with users.
Learning Design specifies three levels of implementation and compliance. This document is therefore partitioned to reflect this. However, each level is mapped to separate XML Schemas.
Learning Design Level A includes everything described so far. It thus contains all the core vocabulary needed to support pedagogical diversity. Levels B and C add three additional concepts and their associated capabilities in order to support more sophisticated behaviors.
Learning Design Level B adds Properties and Conditions to level A, which enable personalization and more elaborate sequencing and interactions based on learner portfolios. It can be used to direct the learning activities as well as record outcomes. The separation of Properties and Conditions into a separate Schema also enable it to be used independently of the rest of the Learning Design Specification, typically as an enhancement to IMS Simple Sequencing.
Learning Design Level C adds Notification to level B, which, although a fairly small addition to the specification, adds significantly to the capability, but potentially also to the implementation task where something similar is not already in place.
The approach taken in this specification is therefore not to define a single large schema with a core of mandatory elements and numerous optional elements, but rather to define a complete core that is yet as simple as possible, and then to define two levels of extension that capture more sophisticated features and behaviors.
We expect compliance to be both more rigorous and yet flexible, with Level A being relatively easy to achieve. The option lies with whether and when to implement the higher levels.
Complete compliance will then be expected of implementing systems for any given level. With respect to Learning Design, instance documents implemented in compliance with this specification, do not need to implement every element, so a distinction is made between compliance of content and compliance of supporting systems. Optional elements apply to document instances; systems must implement all the specification at a stated level and thus should be able to run all instances of that level whatever options these choose to make use of. Learning design instances that comply with this specification must be validated by a parser using the supplied XML schemas. However they should specify which Learning Design Level they expect a compliant runtime system to support, so that systems which do not specify all three levels can determine whether they are capable of running any particular learning design instance.
Learning Design can be considered as an integrative layer to many existing specifications. The IMS Learning Design Specification makes use of, includes, or is extendable with the following specifications:
The standard way to include specifications is through the mechanisms of XML Namespaces. All IMS specifications have their own namespace.
This document is the IMS Learning Design Specification. As such it will be used as the basis for the production of the following documents:
Taken together, the three documents constitute the IMS Learning Design Specification.
This information model describes a model for learning design that contains three primary components:
|
[LD1] |
EML reference manual (http://eml.ou.nl) |
|
[LD2] |
IMS Content Packaging Specification (http://www.imsglobal.org) |
|
[LD3] |
IMS Learning Resource Meta-Data Specification (http://www.imsglobal.org).
See also IEEE LTSC (http://ltsc.ieee.org)
LOM (Learning Object Metadata) |
|
[LD4] |
IMS Simple Sequencing Specification (http://www.imsglobal.org) |
|
[LD5] |
Modelling units of study from a pedagogical
perspective: the pedagogical metamodel behind EML, Koper E.J.R., 2001: (http://eml.ou.nl/introduction/docs/ped-metamodel.pdf) |
|
[LD6] |
IMS Question and Test Interoperability Specification (http://www.imsglobal.org) |
|
[LD7] |
IMS Reusable Definition of Competency or Educational
Objective (RDCEO) Specification (http://www.imsglobal.org) |
|
[LD8] |
IMS Learner Information Package Specification (http://www.imsglobal.org) |
|
[LD9] |
IMS Enterprise Specification (http://www.imsglobal.org) |
|
[LD10] |
ADL SCORM (http://www.adlnet.org) |
|
[LD11] |
CLEO, content aggregation (http://www.lsal.cmu.edu/lsal/expertise/projects/
cleo/report20010701/working/aggregation.html) |
|
[LD12] |
OASIS DOCBOOK (http://www.oasis-open.org/docbook/documentation/reference/html/docbook.html) |
|
[LD13] |
Unified Modeling Language (http://www.omg.org/technology/documents/formal/uml.htm) |
|
[LD14] |
W3C HTML 4.0 specification (http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2)
(for the definition of the 'class' attribute) |
|
[LD15] |
IETF (http://www.ietf.org),
relevant specifications: URI, ftp, news, smtp, http |
|
[LD16] |
W3C (http://www.w3c.org) consortium for Web-related
interoperability specifications: HTML, XHTML, XML 1.0, XML schema, XML
namespaces, XSLT |
|
[LD17] |
Vogten, H., Verhooren, M., & Koper, E. UML
diagrams (http://eml.ou.nl/introduction/docs/uml.pdf) |
Note: The objective of the Learning Design Specification is to provide a containment framework of elements that can describe any design of a teaching-learning process in a formal way. More specifically, the Learning Design Specification meets the following requirements:
R1. Completeness: The specification must be able to fully describe the teaching-learning process in a unit of learning, including references to the digital and non-digital learning objects and services needed during the process. This includes:
R2. Pedagogical Flexibility: The specification must be able to express the pedagogical meaning and functionality of the different data elements within the context of a unit of learning. It must be flexible in the description of all different kinds of pedagogies and not prescribe any specific pedagogical approach.
R3. Personalization: The specification must be able to describe personalization aspects within a learning design, so that the content and activities within a unit of learning can be adapted based on the preferences, portfolio, pre-knowledge, educational needs, and situational circumstances of users. In addition, the control over the adaptation process must be given, as desired, to the student, a staff member, the computer, and/or the designer.
R4. Formalization: The specification must describe a learning design in the context of a unit of learning in a formal way, so that automatic processing is possible.
R5. Reproducibility: The specification must describe the learning design abstracted in such a way that repeated execution in different settings with different persons is possible.
R6. Interoperability: The specification must support interoperability of learning designs.
R7. Compatibility: The specification uses available standards and specifications where possible, mainly IMS Content Packaging, IMS Question and Test Interoperability, IMS/LOM Meta-Data and IMS Simple Sequencing.
R8. Reusability: The specification must make it possible to identify, isolate, de-contextualize and exchange useful learning artefacts, and to re-use these in other contexts.
The conceptual model is expressed as a set of UML class models and a definition of the vocabulary used. It represents the overall conceptual model; it is not yet divided into levels A, B, or C, and it contains some elements that are not expressed in the information model but are needed for the better conceptual understanding. There are three basic models: an aggregation model, a structure model and a model representing the integration of the learning design within IMS Content Package to obtain a so-called 'unit of learning'. The models are all provided before the vocabulary is defined.
The first figure represents the conceptual model of the semantic aggregations levels in the Learning Design Specification [see also LD11]. The diagrammatic notation conforms to UML version 1.4 [LD13], and represents only aggregation relationships (including compositions) and the specializations of abstract classes ('types').
The model shows that learning design provides a semantic view of a collection of resources on one hand, and on the other hand it integrates a method, specifying the dynamic aspects of the learning design.
The model shows three levels of semantic aggregation (the three horizontal layers of grey colored classes). The semantically highest level is the learning design, it aggregates a collection of components, objectives/prerequisites (short for: learning objectives & prerequisites), and a method. The lowest level of aggregation are the resource, play, condition, and notification. The resources are aggregated into components and objectives/prerequisites. The plays, conditions, and notifications are aggregated into the method.
A component can be one of seven different types: role, property group, property, activity structure, activity, environment, or outcome. With the exception of outcome, these are all elements in the LD Information Model. Role can be one of two types: learner or staff.
A resource can be one of five different types: web content, imsld content, person, service facility, or dossier. These resources can be referenced from a Learning Design but are not explicitly part of the Information Model.
Specific types of components are bound to specific types of resources. The moment in time when the resource is bound in the learning design differs:
Example: The textual description of a learning objective for instance, can be written during the design and delivered as a fixed resource with the learning design. However also an absolute URL can be provided to a location where the file can be edited at any time.
The resources that are not bound during design time are not part of this specification. This applies to concrete persons and to the actual dossiers of persons. However, the roles that persons can take into the learning design and the properties that have to be present in the dossiers are part of the learning design.
The model also shows that the components, objectives/prerequisites, and resources are independent of the learning design. They can be referenced and used in many other learning designs. However the method has a composite relationship with the learning design meaning that it is an integral part of it and cannot stand on its own and cannot (easily) be re-used in other learning designs.
Another conceptual view of the learning design is provided in Figure 2.2. In this model, the emphasis is on the functional relationships between the classes.
The core concept of the Learning Design Specification, as expressed in Figure 2.s, is that regardless of pedagogical approach, a person gets a role in the teaching-learning process, typically a learner or a staff role. In this role he or she works toward certain outcomes by performing more or less structured learning and/or support activities within an environment. The environment consists of the appropriate learning objects and services to be used during the performance of the activities. Which role gets which activities at what moment in the process, is determined by the method or by a notification. Note: most of the concepts mentioned above are reflected in the information model, but some only exist at the conceptual level (person, outcome).
The method is designed to meet learning objectives (specification of the outcomes for learners), and presupposes certain prerequisites (specification of the entry level for learners). The method consists of one or more concurrent play(s); a play consists of one or more sequential act(s) and an act is related to one or more concurrent role-part(s), each role-part associates exactly one role with one activity or activity-structure. The teaching-learning process is modelled in the method on the notion of a theatrical play. A play has acts, and in each act has one or more role-parts. The acts in a play follow each other in a sequence (although more complex sequencing behavior can take place within an act). The role-parts within an act associate each role with an activity. The activity in turn describes what that role is to do and what environment is available to it within the act. In the analogy, the assigned activity is the equivalent of the script for the part that the role plays in the act, although less prescriptive. Where there is more than one role-part within an act, these are run in parallel.
A method may, at level B, contain conditions (i.e., If-Then-Else rules that further refine the visibility of activities and environment entities for persons and roles), by defining Boolean expressions on their properties. A property can be grouped into property-groups. Properties can be of different types, representing respectively global versus local properties and personal versus role properties. This is explained later.
In order to enable users to set and view the level B properties from content that is presented to them, so-called global elements are present in the model. These global elements are designed to be included in any content schema through namespaces. Content that includes these global elements is called 'imsldcontent'.
A notification is triggered by an outcome and can make a new activity available for a role to perform. The person getting the notification is not necessarily the same person who creates the outcome. For instance, when one student completes an activity (= an outcome), then another student or the teacher may be notified and set another activity as a consequence. This mechanism can also be used for learning designs where the supply of a consequent activity may be dependent on the kind of outcome of previous activities (adaptive task setting designs).
The explicit roles specified in this language are those of learner and staff roles. Each of these can be specialized into sub-roles, but no vocabulary is put forward for this. It is left open to the learning designer to name the (sub)-roles and specify their activities. For example, in simulations and games different learners can play different roles, each performing different activities in different environments.
Activities can be assembled into activity-structures. An activity-structure aggregates a set of related activities into a single structure, which can be associated to a role in a role-part. A structure can model a sequence or a selection of activities. In a sequence, a role has to complete the different activities in the structure in the order provided. In a selection, a role may select a given number of activities from the set provided in the activity-structure. This can, for instance, be used to model situations where students have to complete two activities, which they may freely select from a collection of e.g., five activities contained in the activity-structure.
Activity-structures can also reference other Activity-structures and reference external Units of Learning, enabling elaborate structures to be defined if required.
Environments can contain two basic types:
Note: if a discussion forum is to be used within a learning design, were it given a predefined URL, then all instances of the Unit of Learning that includes the learning design, wherever and whenever instantiated, would have the same one specific discussion forum. While this may lead to serendipitous learning, it is probably not what was intended by the learning designer! (However, should this be desirable, then a normal Resource element with a fixed URL can be provided.)
For this version of the specification, the types of services specified are limiting these to those that are now found in typical LMS systems. It is possible to inherit from a generic service and thus specify new types as extensions to the vocabulary. As many services are targeted for use in a specific instance of a learning design, the actual members will need to have been assigned to roles before the service is instantiated. As different roles may have different permissions within a service, there is the facility to specify these within the particular service definition.
EML included a complete content vocabulary based on the OASIS DOCBOOK specification [LD12]. For Learning Design it was decided not to include any content specification, but let the users of the Learning Design Specification decide which one to use. In order to allow for runtime interactions with the end users, specific global learning design elements are provided separately at level B which can be namespaced into any XML-based content schema. A suggestion is to use XHTML for content and to namespace the global elements of learning design into XHTML.
The primary use of IMS Learning Design is to model units of learning by including an IMS Learning Design in a content package, preferably - but not necessarily - an IMS Content Package. It this specification it is assumed that IMS Learning Design is being used with IMS Content Packages to model units of learning. How this is done is explained in this section.
IMS Content Packages describe their contents in an XML document called the 'package manifest'. The Manifest may include structured 'views' into the resources contained in that package; each 'view' is described as a hierarchy of items called an 'organization'. Each item refers to a Resource that, in turn, can refer to a physical file within the package. It can however also refer to an external resource. Figure 2.3 depicts the entire IMS Content Packaging conceptual model.
The Manifest is the information structure defined in the Content Packaging Specification. It is contained within a package as an XML file with a fixed, pre-defined name (imsmanifest.xml). This enables it to be found amongst the many other content files that may be contained in a package.
The integration of a Learning Design into the Content Packaging Structure is set out in the Figure 2.4.
To create a unit of learning, IMS Learning Design is integrated with an IMS Content Package by including the learning design element as another kind of organization within the <organizations> element, using the standard namespace for Learning Design. When the standard namespace is "[standard-namespace-for-learning-design]", then learning design elements are included as follows (ignoring irrelevant elements and attributes):
<manifest>
<metadata/>
<organizations>
<learning-design xmlns="[standard-namespace-for-learning-design]">
[add learning design elements here]
</learning-design>
</organizations>
<resources/>
</manifest>
The italics have to be filled in with the appropriate namespace and elements respectively.
In a package that includes a learning design element, the optional organization element within organizations is ignored. This mechanism is in conformance with the extensibility mechanisms IMS Content Packages provide. If an organizations element contains a learning design element, any 'organization' element in the same organizations element is ignored and only the learning design element is read by the runtime system. Where other content organization elements are desired, they can be included in sub manifests, as sub packages may be aggregated in the same way as in normal content packages.
In this section an overview will be given of the basic conceptual terms of the Learning Design Specification.
Unit
of Learning
A learning design is an integral part of any unit of
learning. A 'unit of learning' is an abstract
term used to refer to any delimited piece of education or training,
such as a course, a module, a lesson, etc. It is noted that a 'unit of
learning' represents more than just a collection of ordered resources
to learn, it includes a variety of prescribed activities (problem
solving activities, search activities, discussion activities, peer
assessment activities, etcetera), assessments, services and support
facilities provided by teachers, trainers and other staff members.
Which activities, which resources, which roles and which workflow is
dependent on the learning design in the unit of learning. A unit of
learning can be modelled as an IMS Content Package by including an IMS
Learning Design in the package.
An IMS content package is called a 'Unit of learning' if and only if it includes a valid IMS learning-design element in the organizations part of the package's manifest. A Unit of Learning includes a manifest, a learning design, resources, possible (sub-) manifests and physical files.
Learning
Design
A learning design is a description of a method enabling
learners to attain certain learning objectives by performing certain
learning activities in a certain order in the context of a certain
learning environment. A learning design is based on the pedagogical
principles of the designer and on specific domain and contexts
variables (e.g., designs for mathematics teaching can differ from
designs for language teaching; designs for distance education can
differ from designs which integrate face-to-face settings). Several
hundreds of designs are described in literature, each based on
different assumptions about the teaching and learning process [LD5]. In
daily practice, most teachers and trainers apply their own principles
of learning. This leads to a countless number of possible design
solutions for the same content domain. In order to allow all these
different designs to be effectively included into e-learning modules,
the approach of a meta-language is taken, enabling the description of
all kinds of learning designs without forcing a specific solution on
the designers.
The Learning Design element is the root element for the Learning Design Specification. It includes the core set of elements added by the Learning Design Specification to the existing Content Packaging Specification. It provides a semantically structured view on the resources along with learning process information. The following terms are the key additions.
Learning
Objectives
The learning objectives are the overall learning
objectives to be attained by learners who complete the unit of
learning. Learning objectives can be specified on several levels of
detail. In IMS Learning Design, designers can choose to specify
learning objectives at two levels, each with advantages and
disadvantages. First, it is possible to define the learning objectives
at the global level of the unit of learning. Second, it is possible to
specify learning objectives for every single activity in the learning
design. Designers can follow several approaches:
Prerequisites
The prerequisites specify the overall entry requirements
for learners for doing the unit of learning. As with learning
objectives, the prerequisites can be provided at the level of the unit
of learning and/or for individual learning activities.
Learning objectives and prerequisites can be described using the IMS Reusable Definition of Competency or Educational Objective (RDCEO) format, but can also refer to simple resources (e.g., a text) with a description of the learning objective.
Components
These are the declarations of the different components
that provide the 'building blocks' for the method section of the
learning design. In Learning Design Level A these are: roles,
activities, and environments In Learning Design Levels B and C these
are: roles, properties, activities, and environments. The components
are declared separately from the method to avoid duplication in the
method when using the same component more than once. The component and
the method sections can be compared to a cooking recipe: the components
are the list of ingredients and the method is the preparation
instructions.
Roles
Roles allow the type of participant in a unit of
learning to be specified. There are two basic Role types: Learner and
Staff. These however can be sub-typed to allow learners to play
different roles in certain types of learning activity such as
task-based, role-play and simulations. Similarly support staff can be
sub-typed and given more specialized roles, such as Tutor, Teaching
Assistant, Mentor, etc. Roles thus lay the basis for multi-user models
of learning.
The name a role is given depends on the pedagogy and setting used. In some instances a learner is called a 'student' in others a 'participants'. The names of staff roles are even more variant, e.g., teacher, trainer, tutor, facilitator, mentor, assessor. Every role can have its own 'title' which provides the name for it.
At runtime more than one user can be assigned to the same role, however restrictions can be set on the maximum and minimum number for each role. In this sense roles can be used for grouping purposes.
Properties
Properties are only available in level B and C of the
Learning Design Specification. They form the basis on which to build
user and role dossiers and portfolios. Properties are an essential part
of monitoring, personalization, assessment and for user-interaction.
Learning Design supports five types of properties: local properties,
local-personal properties, local-role properties, global-personal
properties and global properties. Furthermore, properties can be
grouped to e.g. create forms. The local properties are declared in the
learning design. The global properties are expected to be declared
externally, but a mechanism is included to declare new global
properties when they are not present.
Global
Elements
In Levels B and C, in order for users to be able to set
and view properties during the teaching and learning process, global
elements are provided as a separate part of the IMS Learning Design
Specification. There are four global elements: set-property,
view-property, set-property-group, and view-property-group. The
set-property element enables a user control in a Web (or other)
interface to change the current value of a specific property. The
view-property element shows the property value of a selected property
to the user as part of the learning content. The set-property-group and
view-property-group elements do the same for a set of properties.
Global elements are not a part of the learning-design tree, but are
provided separately. They are designed to be included in any XML
content schema by use of XML namespaces (e.g., for inclusion in XHTML).
Without these elements it is not possible to access or set the
properties. Content that uses global elements must be given a specific
resource type (referring to the type attribute of the resource element
of IMS Content Packaging), namely 'imsldcontent' instead of
'webcontent'. In the future, the set of global elements available for
inclusion in content schemas can be extended.
Activities
Activities are one of the core structural elements of
the 'learning workflow' model for learning design. They form the link
between the roles and the learning objects and services in the learning
environment. They describe the activities a role has to undertake
within a specified environment composed of learning objects and
services. They also specify their termination conditions and the
actions to be taken on termination. There are two basic types of
activities: learning activities and support activities. A learning
activity is directed at attaining a learning objective per individual
user. Any user performs a learning activity only once (until
completion). A support activity is meant to facilitate a role
performing one or more learning activities. More than one person can be
assigned to a role in runtime. In practice this means that a support
activity has to be performed as many times as there are users in the
supported role.
Activities can be aggregated into an activity-structure which provides the mechanisms to structure activities and referenced units of learning into a sequence or a user-selection.
An activity references the environment in which the activity must be executed. For the execution of any activity, a user needs, at a minimum, an activity description and, optionally, an environment with the learning objects and services needed to perform the activity.
Learning
Activity
A Learning Activity consists of a single activity-description
and several optional elements. The activity-description is the actual
cue given to the user (rendered in the user-interface) to describe the
activity to be performed by the user. In most cases the
activity-description is a text (of type webcontent). In other cases it
can be an audio-file (webcontent), a video file or any other cue to the
user. Whatever forms it takes, the activity-description is referenced
via an <item> element, derived from Content Packaging,
referencing a resource element in the content package.
In addition to Environment reference(s), the other optional elements include:
title, IMS metadata, learning-objectives, prerequisites (see above), and the new elements: complete-activity (which specifies when an activity is completed, in Level A either by user-choice, or on reaching a time-limit, and extended by Level B with when-property-value-is-set), and on-completion (which specifies actions that are to be executed on completion of the activity).
In level A, on-completion contains only one element, feedback-description, which references content to be displayed to the user when they finish.
on-completion is further extended at level B by the change-property-value element, and at Level C by the notification element).
Support
Activity
A Support Activity consists mostly of the same elements
as a Learning Activity, but without the learning-objectives,
prerequisites, and with a role-ref element
added. The role-ref element
indicates who will be supported by this activity. The supported role
can have more than one person in the role. This means in practice that
the support activity has to be repeated for every user in the supported
role before it is completed. This is a key difference from learning
activities, which is only performed once. Example: a staff role has the
support activity to grade reports made by persons in the learner role
named 'student'. Every person being a student creates his/her own
report. The tutor grades every report (repeating the 'grade report'
support activity).
Activity-Structure
An Activity-structure in turn consists of references
to one or more of:
In the case of the Unit of Learning, the reference is an HREF to the Unique Resource Identifier (URI) of the unit of learning. This URI can be any worldwide unique identifier, including a URL (as it is used in the W3C namespace specification to identify unique namespaces). When using IMS Content Packaging, this means that it refers to the 'identifier' attribute of the manifest, which must be a worldwide unique identifier of some format.
Like the single Activities, an Activity-structure may reference one or more environments. This allows for learning design models where a series of different activities are performed within the same environment. When an activity-structure references one or more environments, then these will overrule the environments specified within the referenced activities.
The environments will not be inherited between hierarchical levels of the Activity-structure, allowing environments to be omitted as well. As a consequence, for each hierarchical level of the Activity-structure the appropriate reference to an environment has to be made and possibly repeated.
A structure may contain information. This provides a CP Organization/Item structure which provides links to resources which contain further information about the activity-structure.
Environment
Activities take place in a so-called 'environment',
which is a structured collection of learning objects, services, and
sub-environments. The relationship between an activity and an
environment can be derived from the linguistic description of the
activities. Most nouns in the activity imply the availability of
learning objects in the environment; references to other persons imply
the availability of communication services; some verbs imply the
availability of supportive services or tools. For instance the
activity: 'read the problem and discuss solutions with your peers'
refers to environment components: 'the problem' which must be available
for reading; and 'peers' which must be available to communicate with
(including communication means).
Learning
Object
Learning objects are defined here, as any reproducible
and addressable digital or non-digital resource used to perform
learning activities or support activities. In IMS Content Packaging
they are represented with the element 'Resources'. Examples are: web
pages, text books, productivity tools (text processors, editors,
calculators, ...), instruments (microscope, etc.), test items. A
classification of different types of learning objects can be found in
the LOM specification (element 5.2 Learning Resource Type makes a
distinction between: exercise, simulation, questionnaire, diagram,
figure, graph, index, slide, table, narrative text, exam, experiment,
problem statement, self assessment, and lecture). A Learning Object may
reference any of these types. However this assumes a runtime system
that will be able to handle them.
Service
Besides resources which can be defined at design time,
there are numerous so-called 'service facilities' used during the
teaching and learning, for instance, a discussion forum or some other
communication facility. Service facilities are resources that cannot be
given a URL at design time. They have to be instantiated by a local
runtime service. This is because, if a service facility is bound at
design time, then that specific service would have to be used by all
users of all instances of the learning design. When what is needed is
an instance of the service that is unique to the runtime instance of
the learning design and its assigned users, (e.g., if a chat forum is
to be dedicated to the use of a specific group of learners and support
staff associated with an particular instance of a learning design),
then this has to be created and the local URL assigned after the
instance of the design has been set up and the group of learners and
staff associated with it. For this to work, it requires a well defined
set of service types, which are known to the runtime service, such as
chat, discussion forum, announcement channel etc. These are now
commonly found in learning management systems. In a learning design,
the use and setup of such a service is declared at an abstract level,
so that a runtime facility (or a human) can setup the necessary
facility according to the requirements. In the learning design
specification, the abstract declaration of a service facility is called
a 'service'. The instantiation of a service is called a 'service
facility'.
Current service types are: send-mail, conference, monitor (level B), and index search. The selection of services to be included needs to be driven by the community. We therefore decided to start with the most widely implemented and used services in online learning environments.
Send-Mail
Service
One of the services in any online learning facility is
the ability to send and receive mail. This is done with an e-mail
client. However, in learning situations it is often needed to know all
the e-mail addresses of your fellow students and teachers when sending
to groups. This information is available in the runtime system. In
order to help users to send e-mail to other users in the same run of
the unit-of-learning, the declaration of a send-mail facility is
included in the services part. When a send mail service is included as
part of a user's environment, the runtime system must provide a
facility to edit a message and attachments and to send them to a
selected list of e-mail addresses of users in the run of the
unit-of-learning. This can either be to all the users in a specific
role or to individuals selected from a role. The users receive the
messages in their regular inbox in the e-mail client.
Conference
Service
A typical communications service is a conference. The
conference service, in addition to a title and metadata, specifies four
conference system roles: participant, observer, conference-manager, and
moderator. These contain references to roles in the learning design.
When the learning design roles have been assigned players, this
information can be used to automatically set up the dedicated
conference space. It is not defined in this Learning Design
Specification what permissions the conference roles should have, so
this is left up to the implementer. However, these conference roles
have commonly understood meanings and learning designers would have the
expectation that implementers would stay within this range.
The conference service can be divided into three subtypes: synchronous conferences (like chats and audio/video conferences), asynchronous conferences (like newsgroups, forums), and announcements (one to many asynchronous conferences).
Monitor
Service
The monitor service provides a facility for users to
look at their own properties or that of others in a structured way. The
idea is that the author defines IMSLD content (e.g. XHTML tables with
global view-property elements) to view the properties. This IMSLD
content is referred to with the 'item' element. When creating a monitor
object, the author has to choose between allowing the user to see the
properties of their own dossier ( 'self' ), or those of all the users
in the specified role. With a monitor object, one can look at the
properties in the dossier of 'self' or in the dossiers of all users in
a certain role. When 'self' is selected, every property has exactly one
value. When a role is selected, the properties in the dossiers of all
the users in the specified role may be viewed. In this case the
learning designer has to be careful, because only one view-property is
specified, but the effect is recurrent for every user in the role. This
means that the list in the user interface must be extended
automatically when parsing the content:
Index-Search
Service
The Index-Search service enables a unit-of-learning to
be indexed, and searches to be then made across it. In addition to title
and metadata elements, it includes an index
element and a search element.
The index element is a wrapper for indexing aspects, used to set up a search service.
The index is made in the background (not visible to users). The visibility is determined with the search element.
The functionality of the index is dependent on the search element:
The search element specifies how a user can access the indexed entities. There are three possibilities:
Method
The method contains two core parts of the Learning
Design Specification: the play and conditions, along with some
completion and on-completion statements.
Play
The core part of the learning design is represented in
the 'play'. A play specifies the actual learning design, the
teaching-learning process, referring to the components declared
earlier. In the play, it is specified which roles perform what
activities in what order. When reading a learning design one basically
reads the play. This is true for human readers as well as machines.
Components not referenced in the play are not shown in the runtime
system. A play is modelled according to a theatrical play with acts and
role-parts. In general: a play consists of a sequence of acts. In each
act, different activities are set for different roles and are preformed
in parallel. When an act is completed, the next act starts until the
completion requirements for the learning design are met.
Conditions
Conditions are only available in Levels B and C of the
IMS Learning Design. They are used in conjunction with properties to
further refinement and to add personalization facilities in the
learning design.
Conditions have the basic format: IF [expression] THEN [show, hide, or change something or notify someone].
The expressions are mostly defined on the properties of the dossier of a learner (e.g., IF pre-knowledge-english="4"). The effects of a condition are mostly different for individual users, although they can be assigned to the same role. Conditions work in the context of the current active act. In practice, conditions are mostly useful within activity-structures of the type 'selection'.
Notification
Notifications are only available at Level C of the
Learning Design Specification. With notifications it is possible to
send a message to a role or to assign new learning or support
activities to roles based on certain events. These events are:
Item
When a component, a learning objective, or a
prerequisite needs a resource, an 'item' element is used in the similar
way as in the organization part of IMS Content Packaging. The learning
design provides a semantic context for these items, so that runtime
systems can know what to do with the resource. For example in the
following case:
<learning-objectives><item identifierref="o123"/></learning-objectives> it is clear that the resource with identifier 'o123' is a learning objective description. In the case of:
<activity-description><item identifierref="o345"/></activity-description> the item is an activity description. A runtime system can position the learning objectives in a certain place in the user-interface, different from the activity-description, and activity-descriptions can be handled differently from other learning content (this can vary from implementation to implementation, within the boundaries of the behavior descriptions provided in this information model).
The information model for the level A, B, and C will be presented in the following format:
Note: Due to the table format, the same elements are often described more than once in different tables. The description of the elements in the different tables is kept exactly the same, as they are generated from UML diagrams [LD17]. When the same element occurs more than once in a table, the information is not repeated, but referred to with 'see above'.
The diagrams use the following format:
The tables describe the elements and attributes of the diagram under which they are positioned. Tables have the following format:
The conceptual UML model for Level A is in Figure 3.1.
See previous diagram. This information table comes from IMS Content Packaging.
