Definitions

Course Managment Terminology

To Do

Define any CM-centric terms (non enterprise data) here...

Data Dictionary

Here's our current LMS-centric view of enterprise data across the surveyed institutions. Many of the fields are optional and can be null.

Membership - A user-role pair associated with something.

Enrollment - The official relationship of a student to something that gets a final grade (or equivalent), including StudentUid, EnrollmentStatus, GradingScheme, Points, and so on.

CourseSet - Models "School" and "Department" as well as more ad hoc groupings. Includes a name, other CourseSets, CanonicalCourses, and Memberships (users with roles).
We may need to be more explicit about institutional hierarchies. But for the use cases we've looked at so far, it doesn't seem as if we need to know different sorts of information about "schools" than about "departments".

CanonicalCourse - Aspects of a course that stay the same across instances of a course. The CanonicalCourse exists whether there's any instances of the course or not. Includes a name, a department, a title, a number, a description, and cross-listed CanonicalCourses, among other things.
Ray: Craig pointed out in email that we may need to take versioning into account, so that old CourseOfferings don't end up bringing out newly revised CanonicalCourse data. Another approach would be templating the interface – that is, letting the CourseOffering effectively subclass CanonicalCourse, including its properties. Behind the scenes, the implementation could still use versioning. The essential point at the interface level is that our logic needs to decide whether two CourseOfferings are instances of the "same" CanonicalCourse by using a CanonicalCourse ID rather than full object equality.

AcademicSession - An institutional context for CourseOfferings, distinguishing one instance of a course from another. It generally has both a short name and a longer descriptive name. In higher educational institutions, it almost always includes a time range. However, self-paced "sessions" are apparently also possible. At any rate, AcademicSession includes a notion of ordering and currency to support queries such as "Find all current course offerings" and "Sort past course offerings in reverse session order".
Ray: I've borrowed the terminology from the PESC Core Data Dictionary. "Term" is considered USA-centric, and "Session" alone is too ambiguous.

CourseOffering - An instance of a course. Includes a name, default instructors and possibly other Memberships, a Term, Sections, EnrollmentSections, and cross-listed CourseOfferings.

Section - Models a "cohort" (a stable group which enrolls in multiple courses as a unit) as well as officially delimited course "groups" and "sections". Includes a name, a SectionCategory, Memberships (notably students, although possibly also instructors and TAs), and possibly other Sections. Depending on the institution and the circumstances, section memberships might include people from different CourseOfferings, or might be restricted to the sum of EnrollmentSections in a CourseOffering, or might be restricted to the members of a single EnrollmentSection. But such business rules are taken care of by the enterprise system; so far as we know, the LMS/CMS/CLE doesn't have to know about them.

EnrollmentSet - This lets the LMS/CMS/CLE ask the question "Who is allowed to submit the final grade for this student, and what is the grade for?" Includes Enrollments, official graders, a CourseOffering, and an enterprise integration ID. Every Enrollment appears in one and only one EnrollmentSet. In contrast, any student might have Memberships in any number of Sections. An EnrollmentSet is often very tightly associated with a Section. This is a common enough case that we may find it worthwhile to create an "EnrollmentSection" to combine the two interfaces. At UC Berkeley, the type of Section associated with an EnrollmentSet is called a "Primary Section". At some other schools, it's just called a "Section". At some institutions (U. Arizona and UC Davis, for example) a single student might be in multiple EnrollmentSets for a single CourseOffering (and therefore receive multiple final grades from different instructors for a single course). At still other institutions, there's just one EnrollmentSet for the whole course: students enroll in the course and pick their sections afterwards. In either case, users tend not to think of the EnrollmentSet as a separate object, but instead identify it with the associated Section or CourseOffering attributes.

Ray: In our last face-to-face, we went back and forth for a while about whether EnrollmentSet should be expressed as an extension of Section or should be expressed as its own interface. Practically speaking, most of the use cases we'd examined strongly associated EnrollmentSets with sections, and so the logic might be simplified if we could talk about them as one thing. We don't want to end up with a situation in which we show the instructor a list containing both "LECT 1" (the section) and "LECT 1" (the enrollment set). However, my first attempt to describe this as a subtype of Section caused confusion of its own, and we do have cases in which EnrollmentSets are associated with a CourseOffering rather than with any particular section. Therefore I'm now trying it the other way.