An Abstract System Model for eLearning

Mark J. Norton

April 3, 2001

In the few years of it’s existence, the IMS Global Learning Consortium has made several major contributions towards specifying components of eLearning systems which will be able to inter operate and share data. Some of these components were obvious in the needs for definition. As more specs are created, however, it becomes increasingly important to understand how they fit together to form a cohesive whole. This document proposes, describes, and raises questions about an abstract system model which could be used to define the relationships between specs and to point out what components need to be developed or refined.

Shown here is an abstract system model of an eLearning system. The components included in it are present in virtually all existing learning delivery systems. Terms are selected to correspond to IMS specs where they exist. Each component is examined in more detail, below.


Learning Objects and Sequencing

Learning is the purpose of an eLearning delivery system. Older systems encouraged learning by sequencing fixed pages of content with interactions, but limited intelligence. This approach is embodied by the AICC standard for computer based training (CBT). IMS, IEEE, ADL, and others are trying to expand the scope, power, and flexibility of on-line learning, which is led to the notion of a learning object.

The learning object is a vague term with a contentious definition. ADL has attempted to be more precise with their Structured Content Objects (SCOs), but the idea of a unit of learning which can be bundled with other units to form larger ones has been around for many years. Let’s consider a very abstract view of a learning object for the purpose of understanding the specification development effort and where IMS should be heading. Further, let’s leave aside the philosophical and pedagogical discussions of what a learning object should be (for now).

I propose that we take an object-oriented programming view of a learning object, for purely self-serving, practical reasons: it will be easier to implement. That being the case, we can (possibly) agree that a learning object consists of learning data and learning behavior.

Learning objects have not really been defined in terms of IMS specs, yet, but there is a lot to learn from the SCORM in terms of what kinds of data are associated with them, and how they are likely to behave. Lack of learning object definition does not prevent us from describing some of the things which they are likely to inherit. The diagram shows two kinds of inheritance: data and behavior. In the object oriented programming paradigm, these are not normally separated, but since IMS work seems to have gone in that direction, they are identified as such here.

Meta data is data which is commonly held by all learning (and other) objects. It provides a broadly useful way to identify, name, and describe an object. Some recent work has also been done in data modeling, though the consensus seems to be that we will adopt data models developed by other organizations. Meta Data and Data Modeling is not all that we need to consider for learning object data, however. The Learning Design work group is actively scoping work to determine what will be the scope of their efforts. Capturing and describing the data and dynamics will certainly be included in their future work.

On the behavioral side, we start to see emerging work on defining how learning objects will communicate with each other and the learning system. The Accessibility group is in the process of creating a scope document which will include guidelines on how to make eLearning systems generally accessible to all. One way to embody these (and other, existing) guidelines is to represent them as inheritable behaviors similar to the Java Accessibility Package. Presentation of a learning object is an important behavior that IMS specs have not touched upon, yet. Presentation is a complicated issue made more difficult by the need to be platform and device independent.

So far, we’ve presented a very traditional view of a learning object, such as an interactive content page. Our view should not be so narrow, however. We should try to be as open-minded as possible when thinking about how learning can be accomplished. Collaboration opens up many possibilities for on-line learning. What does a learning object represent in a collaborative environment? Can it be used to represent mentoring or tutoring relationships? By pushing the envelope in this area, IMS can go way beyond the simplistic approaches being developed by other organizations.

Finally, there is testing. In many ways, an on-line test is not that different than any other piece of content: it has displayable elements and defined ways to interact with them. Testing, however, has requirements over and above simple content pages. Tests are sometimes required to be random in their presentation and supports varying levels of test aids (hints, link-backs, etc.). Above all, tests are required to gather data about a user’s understanding. Models of what can be understood and tested as such are the focus of the Competencies work group. If a test object is distinct from a learning object (an open question), then it could inherit or access competency data and behaviors.

Other aspects of learning objects to consider include how an object may serve as a container for other objects and how they are sequenced. My personal belief is that most pedagogical approaches to learning can be described as a collection of content elements, how they are displayed, how the user can interact with them, and how they are sequenced.


Packaging

Content packaging is intended to collect all the material needed to engender learning on some topic or collection of concepts. It describes a way to represent content data in a portable and inter operable way. It includes a way to determine what is contained in a package without extensive analysis (the manifest).

When a content package is opened and loaded into a learning delivery system, learning objects are created to contain content data and manage its display and interactive behavior. How this happens has not been defined yet.

The process of creating content packages could be referred to as content authoring. IMS needs to develop specifications, recommendations, best practices, and examples to foster good authoring tool development.


Tracking

As users move through content material and interact with it, various tracking information is commonly extracted and retained. Typically, this information is used to bookmark the current position for later resumption, mark learning events as completed, etc. Tracking data is also used for statistical analysis of system usage.

Sometimes this information is recorded separately from the user profile, but it might also be made part of the profile, since it tracks a users performance.


Learner Information

In addition to the tracking information identified above, the Learner Information Package or Profile is used to capture information about a user. This includes material completed, certificates offered, skills and competencies mastered, preferences, user choices, other customizations, etc.

Learner Information can be used by the content delivery component to customize the presentation according to the user’s preferences. This is an important aspect of making the overall eLearning system be accessible to those with disabilities.

The relationship between the content delivery system, enterprise interface, and learner information has not been sufficiently defined.


Enterprise Interface

The enterprise interface recognizes the fact that other kinds of systems need to interface with and guide a user. Job performance and qualifications are part of many human resource (HR) systems. Administrative and security systems control access to content and system resources. The enterprise interface also defines an interface with a library and/or course management system.


Issues

Although significant progress has been made towards defining the components needed to build a next generate eLearning system which will inter operate with others based on the same specifications, much remains to be done. In particular, the relationships between these components and and how they coexist has not been addressed.

Learning design, presentation, and delivery remains a area which needs definition. If IMS is going to adopt recommendations made by other organizations such as ADL, this should be embodied in a specification which references that material and expands on it.

Content authoring needs to be addressed also. How is an author modeled as a special kind of user? What kinds of restrictions will be placed on a content developer? Should we specify various roles such as graphic artist, writer, instructional designer, etc?

If learning objects are to be modeled on an object oriented programming basis, some form of multiple inheritance is likely needed. This is not supported in all programming languages (Java, for example) and introduces complexities of its own into system development. If used, how can it best be employed. If not, how can learning objects naturally inherit the properties and behaviors that it needs?