Institutional Data Mappings

Owned by Former user (Deleted)
Last updated: Mar 15, 2007 by Former user (Deleted)Version comment
4 min read

Gather real-world enterprise data scenarios and integration needs here, and compare them to our model.

Boston University

BU includes the concept of student Teams which span courses and sites. Each Team coordinates on a long-term project and attends courses as a Team. Group grades are factored into individual grades. In MBA and some other programs, a similar long-lived student grouping is called a Cohort, and the Cohorts are enrolled in course offerings as a unit.

Ideally in such an arrangement, the following site hierachy would be supported: A primary site would operate as the Team or Cohort collaboration space, and administered by a special coordinator not necessarily represented by enterprise data. Sub-sites would be course sites governed by individual instructors and registrar data. The course sites tend to be peripheral to the students' collaborative work.

  • Team, Cohort => Section without a CourseOffering parent

Massachusetts Institute of Technology

The data we use is obtained through the Data Warehouse, their data perspective is at:

http://web.mit.edu/warehouse/metadata/tables/star/subject_enrollment.html and graphically at
http://web.mit.edu/whdev/docs/images/subject_enrollment.jpg

In practice, there are independent subjects which meet together and share a course web site, but also subjects where separate sections each have their own course web site.

Stanford University

Example pdf of analysis of RegistrY XML docs
which was generated from our local confluence, useful if you have a Stanford login.
You probably don't. So here is a copy, stuck like a bugzilla in amber.

I think we're the only folks who have done an integration with the 2.3 Course Management code. This is deployed at Stanford.

Mappings under 2.3

  • CourseClass => Canonical Course
  • Organization name => 'Dept' /Subject (calculated based on % of multidepartment ownership of Offering)
  • CourseClass Offering(s) => Offering(s)
  • Offering Section(s) => EnrollmentSet(s), Section(s)
  • Section Meeting (s) => Meeting

Notes I may well get rid of EnrollmentSets in 2.4; I'm not clear on what the impact would be at this point, but we don't pass grades out and up. (otoh they are there and work so what the hey) I may also push the 'Dept' mapping up into a hierarchy which represents our backend, translating current 'Dept' records into 'Subject' and mapping our Organizations directly. Former user (Deleted)

U. Arizona

UC Berkeley

The major types of institutional data at UC Berkeley are Term, Department, Course, Primary Section, and Secondary Section. Primary Sections play the central registrar role: they're what holds official enrollment data, decides the instructor of record, determines the number of units available, the allowable set of grading schemes, and cross-listings. In SIS's consolidated enterprise database, "Course" is not abstracted as a separate object, but just consists of some fields that multiple Primary Sections share. However, a student is never enrolled in more than one Primary Section of a single Course, and only one final grade is given for a student-course combination. Secondary Sections hold memberships (generally drawn from the pool of students enrolled in all Primary Sections) but do not formally effect grading. TAs and GSIs tend to be assigned informally, outside the registrar systems. In most cases, the registrar drops management of Secondary Section membership after the first few weeks of class; some departments and courses prefer to handle their own section management from the beginning.

Known examples exist for the following course-to-site combinations:

  • One site = One Course, multiple Primary Sections, multiple Secondary Sections
  • One site = Multiple Courses, multiple Primary Sections, multiple Secondary Sections
  • One site = Single Primary Section
  • One site = Single Secondary Section

Mapping to model:

  • Course => CourseOffering
  • Primary Section => EnrollmentSection
  • Secondary Section => Section

UC Davis

A single course may have multiple required sections, each with their own final grades, enrollment records, and point values, and official graders. Students may take the different sections (e.g., "lab" and "lecture") in different semesters. They may take one pass/fail and the other for a letter grade.

Mapping to model:

  • Course => CourseOffering
  • Section => EnrollmentSection

UCLA

So far, UCLA has taken what's arguably the most efficient possible approach to cross-language integration: All enterprise data of interest is maintained in a consolidated DB and reached through stored DB procedures. It's possible to get a good idea of what sort of course management data is being used and how by going to their Data Feeds page.

For the UCLA pilot, the UCLA registrar has provided its Sakai team with three views:
ucla.course - term, srs_number, subj_area, catlg_no, sect_no, act_type, course_title, section_title, course_description, meet_start_time, meet_end_time, meet_days, max_enrollment
ucla.person -  ucla_id, first_name_person, last_name_person, email, email_source
ucla.role - ucla_id, subj_area, catlg_no, sect_no, term, srs_crs_num, status

In Sakai 2.1.1, this data is mapped to Sakai site objects as follows:
sakaiSite.title =  course.term + course.subj_area + course.catlg_no + course.sect_no
sakaiSite.shortDescription = course.course_title + course.section_title
sakaiSite.description =  course.term + course.subj_area + course.catlg_no + course.sect_no + course.course_title + course.section_title + ~instructor + ~instructorEmail + course.meet_days + course.meet_start_time + course.meet_end_time + course.max_enrollment + course.course_description
sakaiSiteProperties."edu_ucla_course_id" =  course.term + course.subj_area + course.catlg_no + course.sect_no
sakaiSiteProperties."contact-email" = ~instructorEmail
sakaiSiteProperties."contact-name" = ~instructor
sakaiSiteProperties."term" = course.term
sakaiUserProperties."edu_ucla_id" = person.ucla_id
sakaiSite.authzGroup.member =  ~sakaiID + ~role + ~status

U. Wisconsin

Wisconsin has some courses with multiple Graded Sections. In such cases, a student might have two enrollment records and receive two final grades. Subsections are supported. Other sorts of sections (such as a Course consisting of a Lecture and multiple Labs) are called Groups. Courses may be cross-listed, or may be joined by a "meets with" relation. Some professional programs rely on Cohorts: a group of students who move together through the programe over time.

Mapping to model:

  • Cohort => Section without a CourseOffering parent
  • Graded Section => EnrollmentSection
  • Group => Section