An IMS Archtectural Model

Mark J. Norton

April 23, 2001

Using the diagram in the IMS Content Packaging Specification, v1.1, I have created a simpler digram which can be used to investigate architectural issues.

A few changes where made in order to simplify the diagram. Content packages are referred to simply as packages, since they can contain things like user profiles and compentency descriptions. The organization of the package has been reduced to its manifest and resources.

Previously, Data Store was identified as the collection of informational components in the system. I have renamed this to be Information Objects, in part to highlight the fact that more than just data storage is going on here. I have added a new box to indicate that content is represented as an information object apart from its packaged form.

The LMS box has been made more abstract with interface calls deliberately removed from the picture. This allows us to discuss the interfaces and services provided by the LMS more abstractly.

Finally, several user activities are defined where before only a learning one was implied.

Observations

An IMS package is defined as a way to achieve interoperability between learning systems. It can be used to package any information which might be useful to move between learning systems. Because it is a self-contained aggregation of elements, it allows organized information to be easily moved. Packages can be created out of existing content managed by an LMS, or created from scratch using authoring tools.

A particular learning system will have a means to define and store information objects. Information objects are used to describe courses, people, groups, user preferences, tests, questions, courses, etc. Some of this information will be static, others can be modified by interactions with users. IMS packages can be imported or exported from the information objects storage environment. Information objects can be created, modified, and deleted by administrators and the learning management system.

A run time system is used to present activities to a learner and allow interactions. Several kinds of activites will likely be needed: learning, testing, collaboration, system, etc. Activities communicate with information objects via a learning management system. The LMS is a collection of services which allows information to be retrieved, created, and modified. Information is accessed via services, which are LMS interfaces.

Three kinds of users are represented in this diagram (though others likely exist): author, administrator, learner. These users interact with the learning system using a custom interface. Authors use a set of authoring tools to create, manipulate, and pre-view content. Administrators use a set of management tools to manage the overall learning system and get reports on its usage. Learners interact with activites via user interface provided by the run time environment.


What’s Missing?

Several things are not identified in this diagram, or have not been addressed by IMS to date. Each of these needs to be considered and made part of a more detailed system architecture.

Packages have been largely used to contain and move content. This needs to be explanded to show how any organized information can be packaged and moved. The whole area of authoring tools needs to be considered in terms of the kinds of operations needed. Requirements for creating content need to be developed which address accessibility, internationalization, system resources and connect speeds, etc.

Considerable work has been done on defining information objects such as enterprise objects, learner information objects, test and question objects, and others. Work has begun on defining competency objects, and learning design. Additional work is needed to define how content objects (including tests) are sequences and aggregated. Information objects need to be defined in terms of storage and how they are maintained. Administrative management tools need to be described in terms of their operations, the data they manipulate, and outputs.

Communication is at the heart of the learning management system. We need to define the various services and interfaces which make up the LMS. We should look at systems such as SCORM to see how they approach learning management. The Advanced Communication group might be pushed to address messaging and communication between an LMS, Run Time System, and various activities.

User activities need to be further defined, especially ones not directly associated with learning or test taking. Run time sequencing needs to be addressed. Presentation and accessibilty plays a big role in run time activities.