Sakai Course Management Service Ray Davis most slides

Sakai Course Management Service Ray Davis (most slides by Josh Holtzman & Duffy Gillman) University of California, Berkeley

Why CM API? We needed our LMS/CLE to associate • Courses, sections, departments with sites • Courses, sections with groups • Instructors, students, TAs with permissions • Site data with registrar data

Who we? • • • MIT Stanford University of Arizona University of California, Berkeley University of California, Davis A cast of dozens

CM Project Goals • Bring enrollment and course data into Sakai – Flexible enough to support many different course structures – Concrete enough to build tools and services upon • Solve course-site mismatch issue – Courses are not sites – Sites are not courses – More later… • Deliver new site admin tools…?

Why a new API? • IMS Enterprise? • OKI OSID?

Course Data • Three problems to solve – Definitions vary widely among institutions – Structures vary widely within institutions! – Business rules vary widely

Problem #1: Definitions vary widely among institutions Semester = Quarter = Term = Session Section = Class = Course Offering Our Solution: Use vague terms (with help from OKI OSID)

Problem #2: Structures vary widely within institutions Our Solution: (Hopefully) Flexible API

Problem #3: Business rules vary widely Our Solution: Punt

Added to Sakai • • Integration with Authz Integration with Section Management Integration with Site Management Integration with Roster

Automated Section Creation

Student enrollment data

Site creation with CM

Institutional Structures in the UI

Don’t thank us yet • • Complex API Unfamiliar terminology Documentation lacking Sample implementations lacking Inconsistent OOTB authorizations Legacy code still hard to customize Didn’t replace Site admin tools

Decide integration strategy 1. Understand CM object model 2. Understand your institution’s model 3. Understand what your users want out of an LMS / CME 4. See what data you can get from where

Use Case: Simple Course

Use Case: Large Lecture (multiple lectures and sections)

Institutional Decisions • • Sites managed by central admin? By instructors? Course Site & Section Creation – Automated, based on institutional structures • Requires either CM or some custom data feed – Manual (custom), as required by Instructors • • • Requires a CM implementation Requires a Section. Field. Manager implementation May require other customizations to Site Manage / Authz

Development approach 1. Decide mappings between institutional data & CM 2. Start from demo DB or from scratch 3. WRITE INTEGRATION TESTS! 4. Configure the Group. Provider 1. How do institutional roles map to Sakai roles 2. How does enrollment status affect Sakai roles 3. Which Sakai roles take precedence over others 5. Implement Section. Field. Manager for Site Manage 6. Fork legacy code as needed : (

Group Provider • Exposes enterprise defined groups in Sakai – Map get. Group. Roles. For. User(String user. Id); – Map get. User. Roles. For. Group(String id); – String preferred. Role(String one, String other); • Defines how to do compound group IDs – String pack. Id(String[] ids); – String[] unpack. Id(String id);

Group Provider (continued) • OOTB Implementation (in “providers”) maps hierarchical enterprise memberships to flat Sakai site & group memberships – Resolves roles in higher level structures – Resolves roles based on enrollment status – Resolves roles based on instructor status • You might not have to customize

CM impl. of the Group Provider (continued)

CM impl. of the Group Provider (continued) From https: //source. sakaiproject. org/svn/providers/branches/sakai_2 -4 -x/component/src/webapp/WEB -INF/components. xml

Section Info integration • Instructors can switch between SIS and selfmanaged Sections • System Admins can choose among 4 configuration options – A) Exclusively manual. Sections are never automatically created for a site. – B) Manual by default. Sections are not automatically created for a site. – C) Automatic by default. Sections are automatically created for a site. – D) Exclusively automatic. Sections are always automatically created for a site.

Section. Field. Manager • Simple provider that translates from user input to Section EIDs in Site Manage

Course Management API • Seeks a common abstraction for course data across institutions • Essential data: Enrollment in institutionally recognized units • Design Abstraction – Avoiding model lock-in before enough community input is gathered – Intentionally anemic model

Course Management API (continued) • Parts – Two service interfaces • Read-only • Writable – Business objects • Anemic model by design – Factoring “for the wire” – Cross-service dependencies – Simplification of persistence layer caching/session management

Course Management Service Business Objects

Academic. Session Read-only properties: Eid Provides a time-based context for Course. Offerings within a Canonical. Course. This will generally reflect semesters or terms (e. g. Fall and Spring), but may be used to represent any time-based ordering of Course. Offerings Title Description Start. Date End. Date Used for time-based ordering and determining which course data is current

Canonical. Course Read-only properties: Eid Title Description Reflects a curriculum or academic program that is offered repeatedly.

Course. Offering Read-only properties: Represents an instance of a Canonical. Course offered during an Academic. Session. Eid Title Description Academic. Session Start. Date End. Date Enables Course. Offerings to have unique schedule. * *Roadmap plans to abstract dates into Schedule object where Academic. Session and Course. Offering would each have a Schedule.

Course. Set Read-only properties: Model a related group of Canonical. Course or Course. Offering objects. Used in API to group child course objects. [hierarchy] Eid Title Description Category Parent Institution-specific metadata for filtering/searching

Enrollment Read-only properties: User. Id Enrollment. Status Credits Grading. Scheme Represents the enrollment of a single student in a single Course. Offering or Section.

Membership Relates a user to a particular role within a course data unit. Read-only properties: User. Id Role e. g. Department Admin (Course. Set), T. A. (Course. Offering), lecturer (Course. Offering), Default Instructor (Canonical. Course)

Enrollment. Set Read-only properties: Eid Contains Enrollments for a particular Section or Course. Offering and metadata about enrollment in general. Separated from Section as some institutions have Sections that do not carry credit themselves. Title Description Institution-specific metadata (e. g. lab, lecture, …) Category Default. Enrollment. Credits Official. Instructors Some registrars provide this data in aggregate; this applies to all contained enrollments.

Section Read-only properties: Eid Title Description Category Parent Enrollment. Set Represents a cohort or group within a Course. Offering. There may be multiple Sections related to a Course. Offering. Sections may also contain other Sections as subsections.

Service Management Interfaces • Contain semantic ‘glue’ of the APIs • Two interfaces – Course. Management. Service (read-only) – Course. Management. Administration (writeable)

Course. Management. Service Set get. Child. Course. Sets(String parent. Eid); List get. Current. Academic. Sessions(); Set get. Course. Sets(); Academic. Session get. Academic. Session(String eid); Set get. Course. Set. Memberships(String eid); Course. Offering get. Course. Offering(String eid); Canonical. Course get. Canonical. Course(String eid); Set get. Equivalent. Course. Offerings(String course. Offering. Eid); Set get. Equivalent. Canonical. Courses(String canonical. Course. Eid); Set get. Course. Offering. Memberships(String course. Offering. Eid); Set get. Canonical. Courses(String course. Set. Eid; Set get. Course. Offerings(String course. Set. Eid); List get. Academic. Sessions(); Set find. Course. Offerings(String course. Set. Eid, String academic. Session. Eid);

Course. Management. Service (continued) Set find. Currently. Enrolled. Enrollment. Sets(String user. Id); Set find. Currently. Instructing. Enrollment. Sets (String user. Id); Set find. Instructing. Sections(String user. Id, String academic. Session. Eid); Set find. Current. Sections. With. Member(String user. Id);

Course. Management. Service (continued) List find. Course. Sets(String category); Enrollment. Set get. Enrollment. Set(String eid); boolean is. Empty(String course. Set. Eid); Set get. Enrollment. Sets(String course. Offering. Eid); Section get. Section(String eid); Set get. Sections(String course. Offering. Eid); Set get. Enrollments(String enrollment. Set. Eid); Set get. Child. Sections(String parent. Section. Eid); Set get. Instructors. Of. Record. Ids(String enrollment. Set. Eid); Set get. Section. Memberships(String section. Eid); boolean is. Enrolled(String user. Id, Set enrollment. Set. Eids); String get. Section. Role(String section. Eid, String user. Id); boolean is. Enrolled(String user. Id, String eid); Enrollment find. Enrollment(String user. Id, String eid);

Course. Management. Administration boolean remove. Course. Offering. From. Course. S et(String cs. Eid, String co. Eid); void create. Enrollment. Set(String eid, String title, String description, String category, …); void update. Enrollment. Set(Enrollment. Set enrollment. Set); void add. Or. Update. Enrollment(String user. Id, String enrollment. Set. Eid, String enrollment. Status, String credits, String grading. Scheme); boolean remove. Enrollment(String user. Id, String enrollment. Set. Eid); public void create. Section(String eid, String title, String description, String category, String parent. Section. Eid, String …); public void update. Section(Section section); void add. Or. Update. Course. Set. Membership(String user. Id, String role, String course. Set. Eid); boolean remove. Course. Set. Membership(String user. Id, String course. Set. Eid); void add. Or. Update. Course. Offering. Membership (String user. Id, String role, String course. Offering. Eid);

Course. Management. Administration (continued) public boolean remove. Course. Offering. Membership(String user. Id, String course. Offering. Eid); void create. Course. Set(String eid, String title, String description, String category, String parent. Course. Set. Eid); public void add. Or. Update. Section. Membership(String user. Id, String role, String section. Eid); void update. Course. Set(Course. Set course. Set); public boolean remove. Section. Membership(String user. Id, String section. Eid); void create. Canonical. Course(String eid, String title, String description); void update. Canonical. Course(Canonical. Course canonical. Course); void create. Academic. Session(String eid, String title, String description, Date start. Date, Date end. Date); void add. Canonical. Course. To. Course. Set(String course. Set. Eid, void update. Academic. Session(Academic. Session academic. Session); String canonical. Course. Eid); boolean remove. Canonical. Course. From. Course. Set(Str ing course. Set. Eid, String canonical. Course. Eid);

Course. Management. Administration (continued) void set. Equivalent. Canonical. Courses(Set canonical. Courses); boolean remove. Equivalency(Course. Offering course. Offering); boolean remove. Equivalency(Canonical. Course canonical. Course); void add. Course. Offering. To. Course. Set(String course. Set. Eid, String course. Offering. Eid); void create. Course. Offering(String eid, String title, String description, String academic. Session. Eid, String canonical. Course. Eid, Date start. Date, Date end. Date); void update. Course. Offering(Course. Offering course. Offering); void set. Equivalent. Course. Offerings(Set course. Offerings);

Course Management Implementation • Sakai 2. 4 comes with a Hibernate-based reference implementation • Institutions may: – Use the RI, populating the hibernate tables with the Course. Management. Administration API – Use the RI, customizing the hibernate mappings to your custom DB schema – Write a custom implementation of the CM API

CM Implementations • UC Berkeley – Spring JDBC against Oracle Views from SIS • Stanford – RI, loading tables via XML feeds from SIS • UC Davis – RI against Oracle views from SIS • Others, see http: //confluence. sakaiproject. org/confluence/x/Apc

Resources • Production Working Group http: //bugs. sakaiproject. org/confluence/display/PROD/Production+Work+Group • Old CM Project home http: //bugs. sakaiproject. org/confluence/display/CM/Home • UC Davis sample https: //source. sakaiproject. org/contrib/ucd/cm-ucd-impl • UC Berkeley sample https: //source. sakaiproject. org/contrib/ucb-integration-samples • Stanford description http: //bugs. sakaiproject. org/confluence/display/~caseyd/Stanford_Integration