I'm following up Staffan's and Ernie's communication here in order not to clutter
Kolja's survey post. Ernie's questions indicated to us that we may need to better explain what Curriculum is about, conceptually. Besides seeking to clarify the complementary relationship between Ernie's (?) Learning Object Repository (LOR) and Polyxena's Curriculum package, this post also aims at describing how simple sequencing fits into this picture.
Curriculum:
This package, which will be delivered within a few weeks' time, is a simple course management application that can be viewed as made up of two parts; a course design part for the teacher and a course participation part for the student.
The course design part is basically the forms / form-handling code that let the teacher create a map, or a table of content, if you will, that defines and describes the course as it is to be presented to all students. Note that Curriculum is just a pointer to various content found anywhere - it does not itself store the course content.
The course participation part has a navigation and a tracking component. The navigation component consists of the links in the curriculum bar, one for each learning element in the curriculum. The tracking component keeps track of what parts of the course each individual student has visited and denotes this by putting a cross in a box for each visited element.
Curriculum augmented with Simple Sequencing (SS):
A flat (non-branched) learning element structure and a manual (user-controlled) traversal of it, though useful enough in many cases, is only so exciting. The IMS SS spec, which we are going to follow to the letter as we enhance Curriculum, mandates that the curriculums are branched and sequenced (conditionally and automatically traversed).
Branching will entail changes in the course design part, both when it comes to the add/edit forms, which will be augmented to receive input regarding sequencing rules, objectives, etc., and when it comes to the course display page, which will need to show a learning activity tree interface pretty much resembling that of site-map. The activities in the tree, with their attached so called auxiliary resources, correspond to the elements of the first Curriculum version. These auxilliary resources, the actual content, will reside in the LOR (Learning Object Repository) or elsewhere. If the content is stored in the LOR, however, that will enable exporting of the sequence and of the content pieces that together make up the entire course. Also, by collecting all course content in the LOR, we'll get one step closer to being able to stick the "SCORM" label on dotLRN.
Sequencing will entail changes in the course participation part. The order of traversal through the curriculum will no longer be a matter of user preference, but will be regulated by the sequencing rules the course designer has set up for the activities in the sequence, and this will have to be reflected in the curriculum bar and other student UI areas. For instance, all but the active element(s) might be grayed out, there might be a "previous" link while the "next" link is grayed out because the course designer specified that only forward traversal was possible, etc, etc. By clicking a link, the user in effect gives the sequencing engine one of several acceptable "navigation requests" that triggers the overall sequencing process, which manages the triggering of possibly numerous other sub-processes. If all goes well, the end result should be the launching of the "next" (depending on traversal order, completion of tests, etc) learning resource.
The LOR connection:
As its name suggests, the Learning Object Repository is the place where course content should be stored, each individual object in its canonical place. It is not, however, the place where context-specific relations between content objects, as they appear in different course constellations, are defined. The LOR should store metadata about the content that is true regardless of its context. Curriculum, OTOH, defines course constellations by mapping activities, which have their special kind of metadata also defined by IMS/SCORM, to objects in the LOR. A map representing one course might be very similar to and might overlap a different map representing another course, kind of like using views in SQL... By doing this we don't duplicate learning objects that appear in different courses.
Ernie: To answer your questions - no, I don't believe there will be a public API to the simple sequencing engine. Since there is no obvious client to the SS engine besides the Curriculum package, I think it's quite clear that SS could as well reside within the Curriculum package borders. The navigation request that is passed from the curriculum navigation UI via an internal API is basically the only parameter the engine needs. The rest will be figured out by the engine by running its sub-processes and reaching out to the user and activity state data it maintains for itself. The only package that will need to know about the activity rules is the Curriculum package itself, thus there is no real need to pass that information.
Let me know if anything is unclear.
/Ola
