Skip to end of metadata
Go to start of metadata

Course Management Domain

To Do

This page needs to be more general. Include Problem Statement here?

This space is dedicated to developing a common understanding of the Course Management domain. Our work here is to create a shared set of documentation that will orient our team and the community to the important concepts in Course Management. Documentation can also be found in Course Management entry in the SakaiPedia.

First, we need to be clear on the distinction between enterprise institutional data (roughly "the world outside of Sakai web sites"; mostly, although not always, related to academic courses) and LMS/CMS/CLE data (roughly "what's controlled inside Sakai").

For the most part for most schools, enterprise integration is a matter of Sakai code consuming and making use of enterprise data in various ways: to set up site names and descriptions, find out administrative roles, get automatic membership feeds, and so on. In some cases, the LMS/CMS/CLE might send data back out to external systems – notably by submitting final grades for students, but also possibly by broadcasting section switches and so on – but even then the terms of the integration tend to be set by the external systems rather than by the LMS/CMS/CLE. Few registrars are going to change their rules for the benefit of a new LMS.

There are two sides to the problem of making integration simple and pluggable:

  1. Model the external institutional data that Sakai needs. (Not necessarily the whole world of higher education – just what an LMS/CMS/CLE most needs to know.)
  2. Change Sakai to take advantage of the external institutional data.
  • No labels


  1. Mark brought up the question of whether institutional units like "School" and "Department" were out of scope.

    My answer: They may have been out of scope for the OKI OSIDs and for Mark's CM API task from last year. But they're not out of scope for this project, since we have known requirements that depend on access to that data.

    One of Stanford's top priorities is to be able to identify Department Administrators and give them special privileges in sites: that indicates that the LMS somehow be able to find out that the Course associated with a site is connected to a Department.

    Other, longer-term, use cases involve organizing course sites by department or school. Again, this implies that there's some way to reach that information.

  2. As Mark suggested, I've changed the name of "Course" back to "CourseOffering" to eliminate ambiguity.

  3. I've tried to address the remaining issues with some revised naming and descriptions. I'll update the UML diagram next.

  4. Is the relationship between a CanonicalCourse and a CourseSet missing from this diagram?