Learning activity reference model

The educational technology and digital learning wiki
Revision as of 10:52, 29 October 2010 by Daniel K. Schneider (talk | contribs) (→‎The pedagogical model)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Learning Activity Reference Model (LARM) was an attempt to define a general technical reference model for learning activities, in particular with relation to learning design and associated technical frameworks. LARM was developed as part of Learning Activity Design in Education (LADIE), itself part of e-Learning Framework funded by JISC until 2007. This project is over now, but some ideas developed will probably enter into the design of new kinds of service-oriented e-learning architectures.

See also e-framework, a follow project in the same spirit.

Within the LARM framework, “Learning Activity can be defined as: an interaction between a learner or learners and an environment (optionally including content resources, tools and instruments, computer systems and services, ‘real world’ events and objects) that is carried out in response to a task with an intended learning outcome” (Falconer et al, 2006).

Description and characteristics of learning activities are very much similar to the ones that were developed in parallel in the more operational DialogPlus Toolkit project.

Why a reference model ?

By reference model the authors mean “an unambiguous means of sharing a common understanding of a precisely defined domain among people for whom the reference model definition may be the only point of contact.” (Learning Activity Reference Model, retrieved 12:04, 26 February 2009 (UTC)) Target population for such models can be:

  • Teachers and practitioners: To formulate activities in a form that can be stored and exchanged.
  • Implementers, learning technologists: To build what the teacher wants using their institutions existing technology.
  • Vendors and developers: To create systems that conform to a service oriented approach to make the implementers lives easier.

The model

LARM attempts to define a wide area of learning domains, e.g. they refer to the DialogPlus Toolkit taxonomy of activities. It also attempts to define a vendor and educational modeling language independent orchestration, e.g, support systems and/or notation languages like IMS LD, BPEL, LAMS, traditional IMS CP/Scorm 1.2 based LMS, etc.

According to Falconer et al. (2006), the LARM is described in three separate guides

  • Teachers/Practitioners: the Pedagogy guide which has teaching and learning as its primary focus
  • Technologists/Implementers: the Implementation Guide which describes how to configure learning activities from existing environments
  • Developers/Vendors: the Services Guide which defines the reference model so that those creating new educational technology applications can ensure they can be used through the LARM.

Falconer et al. (2006), “The Learning Activity Reference Model (LARM) coordinates a number of technological tools and services that you might want to use in creating and implementing a learning activity. Some of these exist at present, while others are currently being developed and will exist in the future.” The following picture provides a summary of the elements that would enter a production and deployment process:

LARM Architecture, source: PPT slides by Charles Duncan and Ed Barker, 2004

This figure makes two distinctions:

  • between learning activity authoring (on top) and learning activity delivery (bottom)
  • between components that are central to creating and running the learning activity (centre), the tools and services that the activity calls on (eg. wikis, blogs, quizzes) (right), and fairly static information components that may be institutionally based (eg. the student records system) (left). (Falconer et al, 2006).

The pedagogical model

The e-learning framework produced some documents related to pedagogy, e.g. Falconer et al. (2006 and Currier et al. (2005). There are two main outcomes

  • A taxonomy of learning activities elements, in particular:
    • a glossary of characteristics of a learning activity
    • a glossary of teaching approaches
    • a glossary of teaching techniques
  • A template for designing a learning activity based on these glossaries is then suggested.

The closest implementation of this approach can be found in the on-line DialogPlus Toolkit.

A todo list for the IT folks

In terms of IT, one could look at the problem in the following way:

  • There is a set of "learning domain services" that represent the tasks carried out by the members of a teaching organization, e.g. manage learning activities, grade students, track what they do etc.
  • In addition, there is a whole range of supporting "common services" that must be implemented.
  • Both these services can be assembled in various kinds of different environments, e.g. an LMS. Daniel K. Schneider believes that this table is fairly incomplete, but it does show the spirit of the problem, i.e. how to integrate all kinds of computer-supported user activities both at a service level that is hidden from the users and a user agent level.

Therefore a first step is to make a list of services and user agents. The following table was found in some

The E-Learning Framework

A similar table can be found on the E-Learning Framework web site (retrieved 14:19, 26 February 2009 (UTC)). Yet some other variants can be found in other design documents on this web site.



  • Currier Sarah, Lorna M. Campbell, Helen Beetham (2005). Pedagogical Vocabularies Review, JISC Pedagogical Vocabularies Project, Final Draft, 23rd December 2005 Pedagogical vocabularies project
  • Falconer, Isobel, Gráinne Conole, Ann Jeffery, and Peter Douglas (2006). Learning Activity Reference Model – Pedagogy, LADIE reference model guides, The e-learning framework. word doc -archive (broken)