RELOAD Project: Learning Design

We are currently working on the Reload Learning Design Editor and the first version is available now. A LD Player will follow. In the meantime, here are some notes about the Learning Design specification.

The IMS Learning Design Specification was published in January 2003. The LD specification attempts to describe instructional strategy in a consistent and machine readable manner. This specification provides a means whereby reuse and interoperability of teaching content is facilitated, but pedagogical neutrality is retained.

Learning Design grew out of the EML developed by OUNL.

Learning Design includes the following elements for Level A (see IMS LD BP&Iv1s3.2.2):

a series of activities (assessment, discussion, simulation),
performed by one or more players (learners, teachers etc.) - roles,
in an environment consisting of learning objects or services.

Level B adds properties (storing information about a person or group), and conditions (placing constraints upon flow).

Level C adds notifications (triggered events - e.g. if a student asks a question, the teacher needs to be notified that a response is needed).

Learning Design is typically embedded in an IMS content package, placed within an organizations element. Thus, instead of packaging a group of items into an organization, the CP packages not just the resources, but instructions on how to use that resource. IN LD, it is usual to reference resources remotely rather than include them within the Learning Design - this encourages re-use.

The hierarchy of the learning design element is as follows:

learning-design	The base level container
title	A title for the learning design
learning-objectives	What this unit of learning achieves
prerequisites	Whether there are dependencies?
components	The reusable elements of the learning design - this is the key level of granularity
roles	The Role List
learner*	Learner-role
staff*	Tutor-role
activities	The Activity Container: Activities (can) have objectives, prerequisites and metadata. They have an activity description (typically a web page containing instructions for how to perform the activity). If the activity is offline, then no further content is needed. if online, there would also normally be reference to an environment.
learning-activity*	e.g. view this learning object
environment-ref*	A reference to the environment for this activity
activity-description	A narrative description of the activity
support-activity*	e.g. pose question to class
environment-ref*	A reference to the environment for this activity
activity-description	A narrative description of the activity - usually a web page, This is kept separate from the resources in the environment, and so the runtime system can treat it differently - perhaps keeping it always available as a tab.
activity-structures*	A grouping of activities (with attributes to determine whether individual activities are presented as selection or in sequence). At this point there is no facility for coordination of different users doing different things - that has to be done one level up.
environment-ref*	A reference to the environment for this activity-structure
environments	The Environment Container: which contains learning objects and/or services to be used in that activity
environment*	Container for an individual environment (an environment is the collection of resources, services etc necessary for an activity)
title	A short-name for the environment
learning objects*	Learning content utilised within this environment
services*	A service needed for this environment to be utilised
environment-ref*	ref to another environment in the package
metadata	metadata about the environment
method	The key container - cf simple sequencing.
play*	Usually only one, but more than one would run in parallel.
act*	Acts run in sequence, with start triggered by the end of the preceding act. Transitions between acts form synchronisation points for roles. any coordination of events has to be done at this level - it can't be done at the activity level.
role-parts*	Run in parallel - so different roles do different things at the same time. Usually used for learners and teachers, but can be sophisticated - e.g. to support group-setting and role-play
role-ref	ref. to a specific role for this role-part.
activity-ref	ref to activity(-structure) for this role-part.
metadata	Descriptive Metadata for the LD

Note the heavy use of references - this is a feature of Learning Design, intended to foster re-use. In fact it is essential in Learning Design where it is expected that the same resources might be used by different actors at different times.