IMS Learning design?

January 30, 2007

Yesterday we discussed can we use IMS Learning design for describing the Activity-theory driven pattern descriptions of learning activities with social software. Our ideas about how the elements of the activity system constrain the operation level of the activities are here:

Here are my comments about IMS Learning design:
We can use a this framework if (Activity Theory – IMS Learning design):
subjects=roles
tools=environments; *services (their affordances to perform certain activities)
artifacts=environments: *learning objects
general learning sequence? = play
part of the general learning sequence, will it be separated by events? = act
simple activities or sequenced activities as workflows = activity structures

The UML activity diagrams seem to be an intermediate view, that is quite useful. However, where are EVENTS and OUTCOME? It is possible to add the EVENTS between ACTS and OUTCOME with EVENTS.

Sometimes OUTCOME may also become as a learnig object participating in he second ACTs, how is this solved?
How can we go to ACTION and OPERATION level? It seems to be related with the tools..services function where we can indicate the affordances of the tool.

Do REFERENCES to /environments *services/ enable to indicate certain different environments, and we could translate services into ACTION or even OPERATION level?

Services seem to be the affordances of tools to perform certain types of
activities.

In general using LMS LD might solve two problems: how we write down the workflows (UML and XML views), and we may stop using the Alexandrian Activity pattern approach, because the perliminary phase of making LMS LD descriptions involves quite understandable case description format.

Provides a means of expressing many different pedagogical approaches in a relatively succinct language what is pedagogically neutral. A system that has to interpret this language does not need to know the pedagogical approach underlying the design: it only needs to be able to instantiate the design, allocate activities and their associated resources to participants playing the various roles, and coordinate the runtime flow.

EML – Educational Modelling Language was the ancestor of IMS LD

From the Conceptual Model, the fundamental concepts behind a Unit of Learning include Role, Resource, Activity, and Method. Additionally, Units of Learning have various meta-data which include Objectives, Title, etc.

Developing the unit of learning
# n the analysis phase, a concrete educational problem (use case) is analyzed, usually by talking to the various stakeholders. What matters here is that the analysis results in a didactical scenario that is captured in a narrative, often on the basis of a checklist.
# The narrative then is cast in the form of a UML activity diagram in order to add more rigor to the analysis. This is the first design step. The UML activity diagram then forms the basis for an XML document instance that conforms to the LD spec. This is the second design step.
# This document instance subsequently forms the basis for the development of the actual content (resources) in the development phase.
# The content package with both the resources and the learning design will then be evaluated.

Learning Design specifies a time ordered series of activities to be performed by learners and teachers (role), within the context of an environment (this is tools?) consisting of learning objects (this is artifacts?)or services.

Most formal learning design strategies start reasoning from learning objectives, but one may also start from the learning activities, the support activities (usually provided by the teacher), or the environment

The major elements of the Learning Design Specification
learning-design
title
learning-objectives
prerequisites

activities (activity references an environment (tools?) which contains the learning-objects (artifacts?) and services (what is this in activity heory framework?) that are to be used by someone when they engage with the activity).

learning-activity* (activity (learning-activity or support-activity) has a number of parts. They can have their own learning-objectives, prerequisites, and meta-data. Typically, they also have a reference to an environment (tools?) which will contain the learning objects (artifacts?) and/or services (is services like the tool affordances?) to be used in that activity)
environment-ref*
activity-description

support-activity*
environment-ref*
activity-description

activity-structures* (activity-structure contains either simple activities e.g. learning-activity or a support-activity or other activity-structures, referencing other activity-structures means that you can form an arbitrarily complex structure of activities. )
environment-ref*

environments
environment*
title

learning objects*

services*
environment-ref*
metadata

method
play* (contains a number act elements in sequence, triggered by the end of the preceding one, if there is more than one play element, these will be run in parallel …is it the whole instructional sequence?).
act* (Within an act there is a set of role-parts run in together in parallel.)
role-parts*(role-parts are the element that links the method section to the components, contain a reference to a role and a reference to an activity, at runtime each player in that role gets separately presented with and separately uses the assigned activities and its associated learning objects and services)
role-ref
activity-ref
metadata

The hardest part of this process is determining what should go in the sequence of acts and what should go into activity-structures. (What is then act?). Referencing makes the elements reusable in different places.