Coexistence of Content Objects
in the Tabula Framework

Mark J. Norton

May 21, 2001

When browsing around current literature on learning systems, it quickly becomes apparent that there are many definitions of content objects, learning objects, learning activities, etc. People with different perspectives on the problem have developed different solutions towards creating structured content which is portable and will inter operate in a variety of learning environments. This diagram is derived from the Tabula Overview shows four kinds of content objects coexisting in a shared Tabula-based learning architecture:

At the top, an SCO manger handled structured content objects based on the SCORM model. Next, an EdML based model manages objects based on Educational Markup Language. This approach was developed at the Open University in the Netherlands, and is being considered for use by the IMS Learning Design group. Learning Structures is the basis for done by Mark Norton in the Private Campus and OPEN learning environments. Finally, we have a QTI manager which provides an interface for Questions and Tests.

Can all of these content objects coexist in the same system? Tabula provides a framework for developing components which can control each of these kinds of objects. As long as there is some commonality between these various kinds of objects, such as accessing meta-data, storing and retrieving them, etc., then the answer could be yes.

Do we really need this much diversity in a learning system? Why can’t we just pick one type of learning object representation, and make it be a global standard? Either systems of the future have to accept and manage diversity of content objects, or provide the means to convert them to a common object representation. Conversion will prove to be difficult. There are widely different assumptions made in the delivery methods mentioned above. Furthermore, each is a moving target. Wouldn’t it be more interesting to be able to mix and match different kinds of objects, perhaps based on different models, to achieve the kind of results that the teacher or learner is looking for? This kind of open system is able to expand and adapt as new styles of learning are developed, or new technologies come into existence.

Another question we need to examine is how different kinds of behavior are represented. At least two kinds of behavior are present in most learning systems: interactive and sequencing. Interactive Behavior describes how the user interacts with a single learning object or activity. Sequencing Behavior describes how the user moves from one learning situation to the next.

The SCORM model separates these two kind of behavior. Version 1.1 defines an interactive behavior based on HTML and a Run Time communication adaptor which provides a two-way communication link with the server. Sequencing behavior is defined to be controlled by the LMS, and is TBD in version 1.1. SCORM behavior is explored in greater depth in SCORM Behavior.

Current implementations of the Learning Structure model does not separate these behaviors. Instead, it attempts to apply uniform interactive behavior over a single kind of sequencing behavior. Different structures are selected to provide different kinds of behavior.

The QTI specification defines interactive behavior. The working group has started on a way to describe how questions are organized into blocks which are presented to the user and make up a test. The spec goes further and also defines an administrative behavior in the form of output results and reports.

Could these different approaches to content delivery be merged into a single behavioral representation system? Probably. Should they? Maybe not, it depends on the trade-offs between standardization and flexibility. Standardized learning objects are more likely to inter operate. On the other hand, supporting a variety of learning objects fosters creativity and experimentation.

These questions can be debated independently of the need to develop an over-arching framework in which these kinds of architectures can be realized. Tabula can be made to be sufficiently flexible to encompass all of these approaches and others which are not described here.