Content Aggregation: OKI Arcs
Mark J. Norton
May 25, 2001
I met today with Jeff Merriman, Phil Long, and Lois Brooks of the Open Knowledge Initiative. Although we agreed to defer discussions of architecture to a future meeting, Jeff briefly sketched the following diagram on the board:
Jeff explained that Atoms are media objects which can’t be broken down further. They exist and can be copied, referred to, etc. Examples of Atoms are pictures, text, audio, etc. Content is a container that organizes one or more atoms. An Arc is another container that organizes one or more content objects. Jeff indicated that Arcs and Content objects can have meta-data. I have extended this slightly to allow Atoms to have meta-data also.
I’d like to speculate and examine this structure without the bias that additional information from OKI would represent. There is a certain amount of risk in this in that I might make some invalid assumptions about how these entities are organized and used. As things stand, however, this diagram fits well into the framework that IMS is developing, and the SCORM work that ADL is doing.
Organization
In many ways, this is a classical organizational structure. We have low level objects which possess certain basic characteristics and properties (Atoms). These objects can be combined in certains ways to form useful organization (Content). These organization can then be combined to form a higher level of organization which is recursive.
In some of my other research notes, I refer to these objects using different terms. Atoms are media elements or content elements. The Content entity is often referred to as a Learning Object. Learning objects are organized by sequencing. Sequenced objects can also be grouped into higher level sequences. From this organizational strategy arises the typical kinds of aggregation found in classical learning management systems: events, topics, modules, courses, curricula, etc.
The OKI diagram above doesn’t provide any indication of how Atoms are organized to form Content elements. If we assume that the Content element (or object) is intended to present atoms to the user in some structured manner, then some means is needed to describe a layout, ie. a 2D organization of Atoms. There are many ways to represent this organization, HTML probably being the most common. Alternatively, an XML schema could be developed to provide a layout description system better suited to OKI’s needs.
In a similar manner, the diagram doesn’t say anything about how Content objects are organized into Arcs. Jeff mentioned that Arcs could evoke story arcs. He also mentioned an acronym such as Academic Resource Control. I was immediately drawn to arcs in graph theory. To me, all of these things lead to the same concept: Arcs are used to represent the order in which Content objects are presented. In the other documents I’ve written, this is referred to as sequecing and aggregation.
Years ago, I gave some thought to how learning objects could be sequenced. Some examples of sequencing can be found in Process Diagrams. This is further expanded in Classifying Learning Model Components. It is my belief that all possible approaches to content object sequencing can be expressed using graph theory with various restrictions on branching and directed links. This definition needs to include dynamically generated graphs as well as static ones, however. If sequencing can be represented as a graph, then there are well understood ways to represent and manipulated them as data structures.
Behavior
As with most entity relation diagrams, the OKI diagram gives no clues into how these objects behave or interact with a user. As I have explained in Representing Learning Object Behavior and SCO Behavior, describing how objects are collected together is not the hard part, rather, describing how they interact with the user is more difficult.
I have separated behavior into two parts in these documents: interactive and sequecing behavior. Interactive behavior defines how the user interacts with a learning object, the results of inputs from the user, and how to report these interactions back to a central server. Sequencing behavior determines what learning object should be presented to the user next, based on interactions with the current object and information stored in the aggregated learning object package, which OKI calls an Arc.
Of these two kinds of behavior, I belive that interactive behavior is the harder of the two to represent in a manner that allows the object to be portable across learning systems. Computer Science has developed a formalism for representing behavior of data objects called programming languages. For reasons I won’t go into here, most of these languages are highly dependent on an operating environment and are not generally portable. There are some exceptions to this which people have tried to leverage. One is Java, which was intended to be platform independent (write once, run anywhere). Another is JavaScript, which is intended to run in client browsers. JavaScript is exploited by the SCORM model to represent portable interactive behaviors. JavaScript had severe incompatibility problems in early versions of web browsers. Some of these have been resolved, while others remain (such as DOM implementations). Other candidates for portable, platform independet langauges could include Perl, PHP, and TCL (all web scripting languages). We could envision creating a language specifically for this purpose, such as the OPUS scripting language I created a while back.
If we are going to create systems which are based on portable, re-usable, interoperable learning objects, we need a general solution to this problem of describing interative behavior. Simplistic behavior can be handled in several ways such as embedded data flags, pre-defined widgets (user interface, web forms, hyper-links, etc.), templated behaviors, and others. Ultimately, this fails to capture all that needs to be done. Consider conditional display of content objects based on data drawn from a user profile: conditions and objects vary considerably. Representing display behavior in this manner probably will require something more expressive than canned gadgets or interpetive data.
I’ll touch briefly on sequencing behavior. I mentioned above that sequecing can be described using graph structures. If we assume that sequencing is uniform within an Arc package, then the behavior can be disassociated from the content elements and represented as meta-data on the aggregated package. This is essentally the approach that Learning Structures take. Different styles of learning correspond to different types of sequencing representation. Styles can be mixed in higher levels of aggregation as long as content objects are sequenced consistently in their package. Incidentally, where I’ve mentioned the work package or aggregation structure, think IMS Content Package. This spec is designed to capture and bundle objects.
Mapping onto SCORM
I mentioned to Jeff today that the OKI Arc model is very similar to the ADL Structured Content Object Reference Model (SCORM). Again, the terminology is different:
