1EdTech Candidate Final

1EdTech Course Planning and Scheduling (CPS/LIS)

Version 1.0 Candidate Final

Date Issued: 31 December 2013

Latest version: /cps

IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: sites/default/files/imsipr_policyFinal.pdf.

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

© 2013 1EdTech Consortium, Inc.
All Rights Reserved.

The 1EdTech Logo is a trademark of the 1EdTech Consortium Inc.
Documents Name: 1EdTech Course Planning and Scheduling – Revision: 31 December 2013

1 Introduction

1.1 Course Planning & Scheduling Overview

1.2 Scope and Context

1.3 Structure of this Document

1.4 Nomenclature

1.5 References

2 CPS/LIS Key Use Cases

3 CPS/LIS Architecture

3.1 System Architecture

3.2 Service Orchestration

3.3 Logical Data Model

4 LIS Profile for CPS

4.1 LIS Interface

4.2 Core Service Choreography

4.3 Update Service Choreography

4.4 LIS Data Model and extensions

4.4.1 Modifications to Membership

4.4.2 Modifications to Course Section

4.4.3 Modifications to Course Offering

4.4.4 Modifications to Section Association

5 CPS Event Interoperability

5.1 Event Service Interface

5.2 Event Service Description

5.2.1 SimpleSchedule

5.2.2 AdvancedSchedule

5.3 iCalendar Data Model

6 CPS/LIS Binding

6.1 LIS

6.2 Event Service

7 Best Practices and Implementation Guide

7.1 General

7.2 Specifying the Academic Session

7.3 Delivery Rules

7.4 Validation

7.5 Event Service Best Practice

8 Conformance & Compliance

8.1 Bulk Data Exchange Service Statement

8.1.1 Service Statement: SIS to PAS

8.1.2 Payload Data: SIS to PAS

8.1.3 Service Statement: PAS to SIS

8.1.4 Payload Data: PAS to SIS

8.2 Membership Management Service Statement

8.2.1 Service Statement

8.2.2 Data Model Statement

8.3 Course Management Service Statement

8.3.1 Service Statement

8.3.2 Data Model Statement

8.4 Event Service Statement

8.4.1 Service Statement

8.4.2 Data Mode Statement

Appendix A – Glossary

Appendix B – Configuration and Scheduling Rules

Table of Figures

Figure 3.1 CPS/LIS architecture

Figure 3.2 Service Orchestration

Figure 3.3 Logical data model

Figure 4.1 Bulk Data Exchange Management Service

Figure 4.2 Membership Management Service

Figure 4.3 Course Section Service

Figure 4.4 Section Association Service

Table 4.1 Bulk Data from the SIS to the PAS

Table 4.2: Bulk Data from the PAS to the SIS

Figure 4.5: SIS initiated Core Data Service Choreography

Figure 4.6 PAS initiated Core Data Service Choreography

Figure 4.7 SIS initiated Update Service Choreography

Figure 4.8 PAS initiated Update Service Choreography

Figure 4.9 Membership Data Structure [LIS, 13b]

Figure 4.10 Course Section Data Structure [LIS, 13b]

Figure 4.11 Course Offering Data Structure [LIS, 13b]

Figure 4.12 Section Association Data Structure [LIS, 13b]

Figure 5.1: Event Service Interface

Figure 5.2 iCalendar base types

Figure 5.3 iCalendar base types

Figure 5.4 iCalendar base types

1 Introduction

1.1 Course Planning & Scheduling Overview

The Course Planning & Scheduling (CPS) specification is an application profile of Learning Information Services (LIS) [LIS, 13a]. CPS is the definition of how systems manage the exchange of information used for the planning and scheduling of courses, the optimal use of facilities within an institution and the corresponding timetables for people within the institution. The CPS application profile is constructed following the recommendations documented in the 1EdTech Abstract Framework (IAF) [IAF, 03a], [IAF, 03b], [IAF, 03c]. This means that this specification is based upon the concepts of:

· Interoperability – CPS focuses on the exchange of people, courses, enrolments and event information between systems. There are no definitions in the specification on how the data is managed within the systems;

· Service-oriented – CPS defines the exchange of information in terms of the services being supplied by the collaboration of the systems;

· Component-based – for example, the CPS makes use of, profiled versions of, the Person Management Service (PMS), Course Management Service (CMS), Membership Management Service (MMS) and the Bulk Data Exchange Management Service (BDEMS) services within the LIS specification [LIS, 13a];

· Behaviors and Data Models – the CPS is defined in terms of its behaviors and data models. The behaviors cause changes in the state of the data model and the state of the data model will only be altered as a result of a clearly defined behavior;

· Multiple Bindings – the CPS information model is to be defined using the Unified Modelling Language (UML). This enables reliable mapping of the information model into a range of different bindings. The CPS/LIS uses a combination of WSDL and REST-based bindings;

· Adoption – whenever appropriate, the CPS specification makes use of other 1EdTech and non-1EdTech standards and specifications. The CPS uses the IETF RFCs 5545 and 6321 as the data representation format for the timetables and schedules.

1.2 Scope and Context

This information model defines the CPS Abstract Application Programming Interface (a-API). The Learning Information Services specification, of which the Group Management Service is a component, is a series of behavioral models that define how the data models are to be manipulated. These behavioral models are described using UML [SDN07, 07].

1.3 Structure of this Document

The structure of this document is:

2. CPS/LIS Key Use-cases	The Key use cases that this work is designed to address
3. CPS/LIS Architecture	The overall system architecture
4. LIS Profile for CPS	Modifications to LIS in order to support the CPS
5. CPS Event Interoperability	Information Model for the event service
6. CPS/LIS Binding	Binding information for CPS
7. Best Practices & Implementation Guide
8. Conformance & Compliance
Appendix A Glossary
Appendix B Configurations and Delivery Rules	The original email description of the configuration and delivery rules

1.4 Nomenclature

a-API Abstract Application Programming Interface

API Application Programming Interface

BDEMS Bulk Data Exchange Management Service

IAF 1EdTech Abstract Framework

IETF Internet Engineering Task Force

1EdTech 1EdTech Consortium Inc.

LIS Learning Information Services

PAS Planning and Allocation System

PIM Platform Independent Model

PSM Platform Specific Model

RFC Request For Comment

SDN Specification Development Note

UML Unified Modelling Language

1.5 References

[IAF, 03a] 1EdTech GLC Abstract Framework: Applications, Services & Components v1.0, Ed. C.Smythe, 1EdTech Consortium, July 2003.

[IAF, 03b] 1EdTech Abstract Framework: Glossary v1.0, Ed. C.Smythe, 1EdTech Consortium, July 2003.

[IAF, 03c] 1EdTech Abstract Framework: White Paper v1.0, Ed. C.Smythe, 1EdTech Consortium, July 2003.

[LIS, 13a] 1EdTech Learning Information Services v2.0.1 Overview Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[LIS, 13b] 1EdTech Learning Information Services v2.0.1 Specification Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[LIS, 13c] 1EdTech Learning Information Services v2.0.1 Specification Final Release, L.Feng and P.Nicholls, 1EdTech Consortium, September 2013.

[RFC5545, 09] Internet Calendaring and Scheduling Core Object Specification (iCalendar), RFC 5545, B.Desruisseaux, IETF, September 2009.

[RFC6321, 09] xCAl: The XML Format for iCalendar, RFC 6321, C.Daboo, M.Douglass and S.Lee, IETF, August 2011.

2 CPS/LIS Key Use Cases

The core use cases[1] to be addressed by this release of the CPS are (the use-case summaries follow the Cockburn format) as adopted by 1EdTech [SDN, 06];

· Student-optimized Educational Offering – Students pre-enroll on Courses and an optimized schedule is built by the PAS and moderated by the SIS;

· Student-optimized Educational Offering – Students pre-enroll on Courses and an optimized schedule is built and moderated by the PAS.

Use-case Title:	Student Optimized Education Offering
Use-case Local ID:	UC-3
Brief Description:	The schedules are optimized around the pre-enrolment Course choices of students. The SIS supplies the PAS with the provisional Courses to be offered and the student academic records, core rules, etc. The PAS captures the student Course choices (via the Web) and confirms the selection is valid. The PAS creates the minimum number of Activities, Students are allocated to pathways and the Staff workload is managed. The corresponding set of Schedules is created. Via the PAS, the students now adjust their class allocations. The SIS is then informed of the set of Activities and Student pre-enrolment. Students now formally register/enroll via the SIS.
Level:	Summary
Actors:	Primary: PAS
Actors:	Secondary: SIS and Student.
Stakeholders & Interest:	Stakeholder: Institution
	Interest: To get students enrolled on courses and to minimize the number of activities required for the teaching.
	Stakeholder: Student
	Interest: To enroll on the preferred courses.

Use-case Title:
Use-case Local ID:	UC-3/Variant A
Brief Description:	The schedules are optimized around the pre-enrolment Course choices of students. The SIS captures the Student Course pre-enrolment choices. The SIS supplies the PAS with the provisional Courses to be offered and the student academic records, core rules, etc. PAS creates the minimum number of Activities, Students are allocated to pathways and the Staff workload is managed. The corresponding set of Schedules is created. Via the PAS, the students now adjust their class allocations. The SIS is then informed of the set of Activities and Student pre-enrolment. Students now formally register/enroll via the SIS.
Level:	Summary
Actors:	Primary: PAS
Actors:	Secondary: SIS and Student.
Stakeholders & Interest:	Stakeholder: Institution
	Interest: To get students enrolled on courses and to minimize the number of activities required for the teaching.
	Stakeholder: Student
	Interest: To enroll on the preferred courses.

3 CPS/LIS Architecture

3.1 System Architecture

The CPS/LIS architecture is shown in Figure 3.1. The key use-case is for data exchange between an SIS and a PAS with the PAS creating all of the correspond set of schedules/timetables.

Figure 3.1 CPS/LIS architecture

Schedules/timetables are created for:

People – Typically Learners and Educators, who will likely be enrolled into a number of different course sections, and thus need a schedule across many course sections.

Courses – Sections are timetabled in isolation; the schedule for an offering is the sum of the schedules of the sections.

Resources – Equipment, rooms and other resources that might be used by one or more people and as part of one or more different courses, for different purposes.

3.2 Service Orchestration

Figure 3.2 Service Orchestration

The basic operational model of the CPS specification is for reference data about courses and people to be sent to the PAS from the SIS. The reference data typically consists of LIS persons, Course Templates, Course Offerings and Groups. The Offerings may be extended to describe a desired configuration, which describes a hint to the scheduling system based on previous experience on how the course has been run historically. For more details, see later sections and the appendix. This process might be initiated by the PAS or the SIS.

At some point, students will register their intention to take one of the courses. The SIS will then need to inform the PAS of these choices.

The PAS then creates the optimal number of course sections for the course. This process is out of scope for this interoperability specification. The PAS informs the SIS of the course sections, and the memberships (i.e. enrolments) of students into both the sections and the parent offering. The PAS would also create a schedule or timetable at this time. The PAS also updates the initial offering, to show the actual delivery configuration used.

Changes might be subsequently made to enrolments, either via the SIS or via the PAS. Both systems need to keep the other informed.

At some point, final enrollment will occur, which would indicate the end of this interoperability process.

3.3 Logical Data Model

Figure 3.3 Logical data model

The logical data model shows the principal data interoperability points – the data that is shared between SIS and PAS.

Typically, reference data related to people, course templates and course offerings is sent from the SIS to the PAS. When this is coupled with membership “intentions” the PAS is able to create a schedule of activities and events, and then return the optimal number of sections aligned with the schedule back to the SIS, along with enrollments (memberships) of students into those sections.

The PAS creates the required sections as well as updates the offerings to show all potential configurations of sections related to that offering (the “configurations”). Section Associations are used to show “cross listed” sections. Cross listed sections, are sections with common scheduling that are related to different offerings (e.g. a class on organic chemistry from both the chemistry and biochemistry offerings).

The PAS is also expected to return a set of delivery rule extensions, which are expressed as a set of Section Associations. These associations are used by the SIS should students wish to alter their enrolments.

4 LIS Profile for CPS

4.1 LIS Interface

The primary LIS interfaces that are used for CPS are:

Bulk Data Exchange Management Service
Membership Management Service
Course Section Service
Section Association Service

Figure 4.1 Bulk Data Exchange Management Service

Figure 4.2 Membership Management Service

Figure 4.3 Course Section Service

Figure 4.4 Section Association Service

Within those services, the following methods are used (dependent on the specific choreographies used):

Bulk Data Exchange Management Service
- RequestBulkDataExchange
- AnnounceBulkDataExchange
- AnnounceFailureBulkDataExchange
- reportBulkDataExchange
Membership Management Service
- ReplaceMembership
- DeleteMembership
Course Section Service
- ReplaceCourseSection
- DeleteCourseSection
Section Association Service
- ReplaceSectionAssociation
- DeleteSectionAssociation
Group Service
- replaceGroup

The following tables illustrate the messages that need to be included within the Bulk Data File (see the Bulk Data Exchange Specification [LIS, 13b]. “Produces” means that the particular system SHOULD be able to produce a Bulk Data File that contains that type of LIS message. “Consumes” means that a particular systems SHOULD be able to consume a Bulk Data File that contains that type of LIS message. Note that Replace messages of whatever type should create a new instance of that object, if the object does not already exist on the consuming system.

Messages	SIS Produces	PAS Consumes
replacePerson	P	P
deletePerson	P	P
replaceGroup	P	P
deleteGroup	P	P
replaceMembership (INTENTION)	P	P
replaceMembership (SCHEDULED)	P	P
deleteMembership	P	P
replaceCourseTemplate	P	P
deleteCourseTemplate	P	P
replaceCourseOffering	P	P
deleteCourseOffering	P	P
replaceCourseSection
deleteCourseSection
replaceSectionAssoication
deleteSeectionAssociation
replaceGroup	P	P

Table 4.1 Bulk Data from the SIS to the PAS

Messages	PAS Produces	SIS Consumes
replacePerson
deletePerson
replaceGroup
deleteGroup
replaceMembership (INTENTION)
replaceMembership (SCHEDULED)	P	P
deleteMembership	P	P
replaceCourseTemplate
deleteCourseTemplate
replaceCourseOffering	P	P
deleteCourseOffering	P	P
replaceCourseSection	P	P
deleteCourseSection	P	P
replaceSectionAssoication	P	P
deleteSeectionAssociation	P	P
replaceGroup

Table 4.2: Bulk Data from the PAS to the SIS

Data flows - as follows

People (From the SIS to the PAS)
Groups (From the SIS to the PAS)
Memberships (INTENTIONS from the SIS to the PAS; SCHEDULED bidirectional)
Course Templates (From the SIS to the PAS)
Course Offerings (initial form the SIS to the PAS; Configured from the PAS to the SIS)
Course Sections (From the PAS to the SIS)
Section Associations (From the PAS to the SIS)

Further information on the interfaces can be found in the LIS Specification [LIS, 13b]

4.2 Core Service Choreography

Figure 4.5: SIS initiated Core Data Service Choreography

Figure 4.5 shows the loading of reference data and student intentions in an SIS initiated choreography. The basic scenario is:

The SIS announces to the PAS that a bulk data transfer is ready. (The bulk data being reference data for the PAS as outlined below).
The PAS downloads (via HTTPS), an XML file containing Course Templates, Course Offerings (enhanced with an extension to show configuration (see section4.4.3)), People (students and teachers) and Groups. As per the core profile, this reference data would be “replace” and (potentially) “delete” messages [LIS, 13b]
The PAS sends a report message which outlines any errors on the data import.
At some point in the future, the SIS announces to the PAS that a bulk data transfer is ready. (The bulk data being student intention data for the PAS, as outlined below).
The PAS downloads (via HTTPS), an XML file containing Memberships between People (Students) and Course Offerings. Membership is enhanced with an extension to show the type of membership (see section 4.4.1). As per the core profile, this intentions data would be “replaceMembership” messages [LIS, 13b]
The PAS sends a report message which outlines any errors on the data import.

The PAS will then undertake preliminary scheduling based on the data it has received from the SIS, plus any local out of band data that it requires. Once the preliminary schedule is calculated:

· The PAS announces to the SIS that a bulk data transfer is ready. (The bulk data being preliminary enrolments, course sections and delivery rules, as outlined below).

· The SIS downloads (via HTTPS) an XML file containing Course Offerings (enhanced with an extension to describe the configuration definitions used), Course Sections (enhanced with an extension to show the configuration used, section type and order within section type (see section 4.4.2), Section Associations (enhanced with an extension to show delivery rules (see section 4.4.4) or cross listing, Memberships of Course Sections and Course Offerings (both enhanced with an extension to show the type of Membership (see section 4.4.1). As per the core profile, this data would consist of “replace” messages [LIS, 13b]

· The SIS sends a report message which outlines any errors on the data import.

· (The PAS makes schedules available via the Event Service)

At this time the initial loading scenario is completed. Changes are handled via the PAS or SIS (see below)

Figure 4.6 PAS initiated Core Data Service Choreography

Figure 4.6 shows the loading of reference data and student intentions in a PAS initiated choreography. The basic scenario is:

The PAS requests a bulk data exchange from the SIS.

The SIS will need to either announce a failure (announceFailureBulkDataExchange), or marshal the reference data and continue with the process:

The SIS announces to the PAS that a bulk data transfer is ready. (The bulk data being reference data for the PAS as outlined below).
The PAS downloads (via HTTPS), an XML file containing Course Templates, Course Offerings (enhanced with an extension to show configuration (see section 4.4.3)), People (students and teachers) and Groups. As per the core profile, this reference data would be “replace” and (potentially) “delete” messages [LIS, 13b]
The PAS sends a report message which outlines any errors on the data import.
At some point in the future, the SIS announces to the PAS that a bulk data transfer is ready. (The bulk data being student intention data for the PAS, as outlined below).
The PAS downloads (via HTTPS), an XML file containing Memberships between People (Students) and Course Offerings. Membership is enhanced with an extension to show the type of membership (see section 4.4.1). As per the core profile, this intentions data would be “replaceMembership” messages [LIS, 13b]
The PAS sends a report message which outlines any errors on the data import.

The PAS will then undertake preliminary scheduling based on the data it has received from the SIS, plus any local out of band data that it requires. Once the preliminary schedule is calculated:

· The PAS announces to the SIS that a bulk data transfer is ready. (The bulk data being preliminary enrolments, course sections and delivery rules, as outlined below).

· The SIS sends a report message which outlines any errors on the data import.

· (The PAS makes schedules available via the Event Service)

At this time the initial loading scenario is completed. Changes are handled via the PAS or SIS (see below)

4.3 Update Service Choreography

Figure 4.7 SIS initiated Update Service Choreography

Figure 4.7 shows the updating of student enrolments in an SIS initiated choreography. The basic scenario is:

Students use the SIS to register themselves on different course sections and/or course offerings. The SIS will use the delivery rules that it has previously received from the PAS, along with the maximum student numbers properties within Course Sections, and other out of band data, to ensure that the changes are valid.
The SIS sends live DeleteMembership and ReplaceMembership messages to the PAS which reflect the changes in Memberships to Course Sections and Course Offerings. This enables the PAS to update the schedules for students.

It is expected that a number of iterations of changes are expected. At some point, final registration (for an individual student) will happen, at which point further notifications to the PAS are not required (until pre-registration opens in the following academic year).

Figure 4.8 PAS initiated Update Service Choreography

Figure 4.8 shows the updating of student enrolments in a PAS initiated choreography. The basic scenario is:

Students use the PAS to register themselves on different course sections and/or course offerings.
The PAS sends live DeleteMembership and ReplaceMembership messages to the SIS which reflect the changes in Memberships to Course Sections and Course Offerings.
As part of the changes it is possible that the PAS may modify Course Sections and Delivery Rules [For example if a bigger lab is assigned following extra student demand]. Such changes need to be notified to the SIS. (via Replace and Delete messages, modified with extensions (see below) [LIS, 13b]).

It is expected that a number of iterations of changes will be needed. At some point, final registration (for an individual student) will happen, at which point further notifications to the SIS are not required (until pre-registration opens in the following academic year).

Note that between final registration and subsequent pre registration, schedule changes may occur (for example, due to staff illness or room closure - such schedule changes would not be notified to the SIS).

4.4 LIS Data Model and extensions

The Data Model for LIS is described in detail in the LIS Specification [LIS, 13b]. CPS does not alter that model, rather certain data members become mandatory and a number of extensions are introduced.

4.4.1 Modifications to Membership

Figure 4.9 Membership Data Structure [LIS, 13b]

The “Role” class is modified to include an extension:

Descriptor	Definition
Extension Name	MembershipType
Data Type	Enumerated vocabulary
Value Space	Enumerated as { INTENTION, SCHEDULED }
Multiplicity	1
Description	This value is used to signify the type of the membership for the Role. The value space for this vocabulary is approved by 1EdTech GLC. The syntax and semantics of the approved list of terms shall be supported by all software components implementing this Information Model.

4.4.2 Modifications to Course Section

Figure 4.10 Course Section Data Structure [LIS, 13b]

The “Course Section” class is modified to include three mandatory extensions, and a number of optional extensions.

Mandatory Extensions:

Descriptor	Definition
Extension Name	Configuration.Id
Data Type	String
Value Space	See Table 5.1 [LIS, 13b]
Multiplicity	1
Description	GUID of the configuration that this Course Section has been derived from

Descriptor	Definition
Extension Name	SectionType
Data Type	Enumerated Vocabulary
Value Space	Enumerated As {LECTURE, LABORATORY, DISCUSSION, CLINICAL, CONTINUANCE, FIELD STUDIES, INDEPENDENT STUDY, PRACTICUM, RESEARCH, SEMINAR, SUPERVISION, THESIS RESEARCH, TUTORIAL }
Multiplicity	1
Description	The type of this section. This type needs to be specified in the configuration rules used for Course Templates. The value space for this vocabulary is approved by 1EdTech GLC. The syntax and semantics of the approved list of terms shall be supported by all software components implementing this Information Model.

Descriptor	Definition
Extension Name	Order
Data Type	Integer
Value Space	1 to x
Multiplicity	1
Description	The order of the type in the configuration that this course section refers to. For example, with a configuration of {LECTURE, LECTURE, TUTORIAL, TUTORIAL}, the generated course sections would have orders of 1 or 2 (either the section is the first lecture, second lecture, first tutorial or second tutorial). NOTE: This is a mandatory element, so should be set even when there is only one instance of a particular type in the rule. NOTE: The order is not the absolute position within the configuration (so in the above example, there should NOT be section with an order of 3 or 4).

Optional Extensions to Course Section

The following extensions are considered optional. The purpose of these extensions is to help the SIS to create the course sections that are required using sensible defaults that are passed in by the PAS. Receiving Systems MUST be able to receive these parameters without error, but are not required to process all of them further. Sending systems are not required to send any of these optional extensions.

Descriptor	Definition
Extension Name	Student_Consent
Data Type	String
Value Space	Enumerated as [DEPARTMENT, INSTRUCTOR]
Multiplicity	0..1
Description	If the section requires the student to obtain consent to be registered a section, this is the type of consent required.

Descriptor	Definition
Extension Name	Display_Section
Data Type	Boolean
Value Space	See Table 5.1 [LIS, 13b]
Multiplicity	0..1
Description	An instruction to the receiving system as to whether this course section should be displayed.

Descriptor	Definition
Extension Name	Section_Gradable
Data Type	Boolean
Value Space	See Table 5.1 [LIS, 13b]
Multiplicity	0..1
Description	An instruction to the receiving system as to whether this course section should be gradable.

Descriptor	Definition
Extension Name	Instruction Mode
Data Type	String
Value Space	See Table 5.1 [LIS, 13b]
Multiplicity	0..1
Description	A hint to the receiving system as to how the course will be delivered (e.g. online, in person etc.). The precise values that are required to be passed for this vary widely between systems, so an out of band agreement is required,

4.4.3 Modifications to Course Offering

Figure 4.11 Course Offering Data Structure [LIS, 13b]

The “Course Offering” class is modified to include three extensions:

Descriptor	Definition
Extension Name	Configuration.x.Description
Data Type	String
Value Space	[Human readable]
Multiplicity	0..1
Description	This field MAY exist in the SIS to provide a human readable description of the configuration, which MAY be used by the PSA. This is informational only. The initial value of this field MAY be set in the SIS. This value MAY be updated by the PSA when a schedule has been calculated. The SIS should update the offering record to contain this data.

Descriptor	Definition
Extension Name	Configuration.x.Id
Data Type	String
Value Space	See Table 5.1 [LIS, 13b]
Multiplicity	1
Description	GUID of this configuration. This value is set by the PSA when a schedule has been calculated. The SIS should update the offering record to contain this data.

Descriptor	Definition
Extension Name	Configuration.x.Rule
Data Type	String
Value Space	Comma delimited list of Strings using the vocabulary for Section Type (see section 4.4.2)
Multiplicity	1
Description	The rule for this configuration, a comma delimited list of section types that are required to make an instance of this course. This value is set by the PSA when a schedule has been calculated. The SIS should update the offering record to contain this data.

Note that the semantics of these fields is that they are representing complex objects via dot notation. Each configuration element should have the value of x incremented. X should be an integer value between 1 and 20 inclusive. There is no implication of order in the value assigned to x.

For the purposes of conformance, both fields are required.

A maximum of 20 configurations is permitted for a given course template.

Valid Examples:

Configuration.1.Id = uk.ac.sheffield.engineering.dcs.com6011.1

Configuration.1.Rule = LECTURE

Configuration.2.Id = uk.ac.sheffield.engineering.dcs.com6011.2

Configuration.2.Rule = LECTURE

Configuration.3.Id = uk.ac.sheffield.engineering.dcs.com6011.3

Configuration.3.Rule = LECTURE, LECTURE, TUTORIAL

All of the above are pairs, use GUIDS, use terms from the rule vocabulary and use commas to delimit the rule string.

Invalid Examples

Configuration.1.Id = uk.ac.sheffield.engineering.dcs.com6011.1

Configuration.2.Rule = LECTURE

The above are invalid because they are missing the other element of the pair.

Configuration.3.Id = uk.ac.sheffield.engineering.dcs.com6011.3

Configuration.3.Rule = Wibble, LECTURE

The above is invalid because the term “Wibble” is not in the rule vocabulary.

Configuration.x.Id = uk.ac.sheffield.engineering.dcs.com6011.3

Configuration.x.Rule = LECTURE

The above is invalid because “x” is not an integer between 1 and 10.

Other errors would include having 21 or more pairs of extensions, not using commas to delimit the rules etc.

4.4.4 Modifications to Section Association

Figure 4.12 Section Association Data Structure [LIS, 13b]

The “Section Association” class is modified to include three extensions:

Descriptor	Definition
Extension Name	ParentCourseSection
Data Type	String
Value Space	See Table 5.1 [LIS, 13b]
Multiplicity	0..1
Description	This extension describes the parent course section for which the other course sections listed in the courseSectionIdList are children of. Used to describe the delivery rules.

Descriptor	Definition
Extension Name	AssociationType
Data Type	Enumerated Vocabulary
Value Space	Enumerated as {DELIVERY_RULE, CROSS_LIST}
Multiplicity	1
Description	The type of this association. This applies to all SectionAssociations. The value space for this vocabulary is approved by 1EdTech GLC. The syntax and semantics of the approved list of terms shall be supported by all software components implementing this Information Model.

Descriptor	Definition
Extension Name	MaximumNumbers
Data Type	Enumerated Vocabulary
Value Space	Enumerated as {ADDITIVE, MAXIMUM}
Multiplicity	0..1
Description	Instructions on how the maximum numbers for the section are to be calculated. This MUST only appear in cross listed SectionAssociations. The value space for this vocabulary is approved by 1EdTech GLC. The syntax and semantics of the approved list of terms shall be supported by all software components implementing this Information Model.

4.4.5 Recommended Minimum Data – CORE Reference Data:

Course Offering {SourcedId, Title, Org, Academic Session, Configuration Extensions }
Course Template {SourcedId, Title, Org}
Person {SourcedId, Name, role=Instructor}
Person {SourcedId, Name, role=Learner}
Group {SourcedId, GroupType, Description, TimeFrame}

4.4.6 Recommended Minimum Data – Student Intentions

A membership record which:

Contains SourcedId
Contains SourcedId of Course Offering
Contains SourcedId of Person
Contains Role = Learner
Contains Extension: MembershipType = “INTENTION”

4.4.7 Recommended Minimum Data – from PAS

Course Offering:

Sourced Id
All other reference data received from SIS
Configuration IDs (that is, of all configurations to apply to sections of this offering)
Configuration Rules (that is, of all configurations to apply to sections of this offering)
Optionally, Configuration Descriptions (is, of all configurations to apply to sections of this offering)

Course Section:

Sourced Id
Parent Sourced id (of offering)
Title
Location
Max Number of Students
TimeFrame
Meeting (see below)
Academic Session (see best practices)
Configuration ID (that this section is related to)
Section Type
Order of the section within the Section Type

Timing information needs to be passed as follows:

TimeFrame should show the absolute start and end dates and times for the section.
Meeting should be used to describe when the section will take place. iCalendar information should be used to describe this data. (The minimum required: Dates, Times and Rooms).

Membership:

SourcedId
SourcedId of Course Offering
SourcedId of Person
Contain Role = Learner
Contain Extension: MembershipType = “SCHEDULED”

Membership:

SourcedId
SourcedId of Course Section
SourcedId of Person
Contain Role = Learner
Contain Extension: MembershipType = “SCHEDULED”

Delivery Rules:

In order to allow SIS systems to offer sensible choices for student redeployment, a set of delivery rules need to be passed from the PSA to the SIS. These rules are described in SectionAssociation records:

SectionAssociation:

SourcedId
SourcedId of CHILD CourseSections
Status = Active
Extension: PARENT CourseSection
Extension: AssociationType=”DELIVERY_RULE”

Cross Listed Sections:

SourcedId
SourcedId of equivalent CourseSections
Status = Active
Extension: MaximumNumbers
Extension: AssociationType=”CROSS_LIST”

4.4.8 Recommended Minimum Data – Live Updates from SIS

Membership:

SourcedId
SourcedId of Course Offering
SourcedId of Person
Contain Role = Learner
Contain Extension: MembershipType = “SCHEDULED”

Membership:

SourcedId
SourcedId of Course Section
SourcedId of Person
Contain Role = Learner
Contain Extension: MembershipType = “SCHEDULED”

Note that Live updates from the PAS would use the same minimum data as the “Sections from the PAS”

5 CPS Event Interoperability

5.1 Event Service Interface

Figure 5.1 Event Service Interface

5.2 Event Service Description

The Event Service Manager provides two logical functions to display schedules, using the iCalendar information Model [RFC5545, 09].

5.2.1 SimpleSchedule

This represents the simplest possible function call. The function is evoked with a single PersonSourcedId (GUID). The expected behavior is the return of the corresponding iCalendar personal timetable for that user.

The timespan covered, and field values returned, should be “sensible defaults”, but are within the remit of the PAS to determine.

5.2.2 AdvancedSchedule

This is a more advanced function and is designed to allow the return of any resource that the PAS is able to schedule. The inputs to the function are:

SourcedID (GUID): the unique identifier of the resource (user, course, room, equipment etc.), for which the schedule is to be returned.
GUIDType (Enumeration): the type of the GUID sent. This value is taken from a vocabulary of values, and specifies the type of the resource for which the he schedule is to be returned
Timespan (Duration): the duration of the schedule (i.e. start date, finish date), that the schedule is expected to cover. The function will return all events that start or finish within the declared date range.
FieldList (List<Field>): the specific optional fields within iCalendar that are requested to be returned for events within the schedules. Implementations must follow the rules on multiplicities for optional fields within the iCalendar data model.

This function returns the iCalendar schedule for the desired resource, for the specified timespan and containing the specified fields.

5.3 iCalendar Data Model

The CPS specification proposes to use the iCalendar data model to describe the calendars for individual people and resources. A subset of the full Calendar is proposed, primarily to eliminate the need for platform specific extensions in the various bindings. See the binding section for more information.

A high level view of the data model for iCalendar is presented in figures 5.2 through 5.4.

Figure 5.2 iCalendar base types

Figure 5.3 iCalendar base types

Figure 5.4 iCalendar base types

6 CPS/LIS Binding

6.1 LIS

The binding for the LIS parts (bulk data and live transfer) are specified in the 1EdTech LIS specification Binding [LIS 13b].

The specific bindings that will need to be used are:

Bulk Data Exchange Management Service WSDL
Bulk Data Exchange File Format XSD
Membership Management Service WSDL
Course Management WSDL (for Course Offerings and Course Sections).

The binding for the extensions will be described in a VDEX based vocabulary file, as per the extension mechanism for 1EdTech LIS [LIS 13b].

6.2 Event Service

The proposed binding for the event service will be to present a simple RESTful binding based on the HTTP GET request.

Requests for calendars will need to be expressed as GET requests, with parameters expressed in the normal way for GET requests:

The protocol will be http or https (as appropriate for the implementation)
There are no special rules for the domain name.
The path will contain the name of the API function being called, “simpleSchedule” or “advancedSchedule”
For “simpleSchedule”:
- This method name corresponds to “simpleSchedule” from the information model.
- The path will terminate with a single parameter which is the sourcedid of the person whose timetable is being requested.
For “advancedSchedule”:
- This method name corresponds to “advancedSchedule” from the information model.
- The path will terminate with a single parameter which is the sourcedid of the person/resource whose timetable is being requested.
- The URL will include the “type” query parameter with a value from the following vocabulary, “person, room, equipment, course”.
- The URL will include the “start” query parameter, which will represent the starting point of the desired timespan, which will be expressed in the “yyyy-MM-dd” format.
- The URL will include the “end” query parameter, which will represent the ending point of the desired timespan, which will be expressed in the “yyyy-MM-dd” format.
- The URL will include one or more instances of the “field” query parameter, which will represent the desired list of optional fields from iCalendar to return in the event descriptions. The precise strings to use are taken from the iCalendar data model [RFC5545, 09]. The multiplicity rules for optional fields
For both methods, the GET request should return a text based iCalendar (“.ics”) file, containing the correct set of events.

The following examples illustrate both sets of calls:

The following example illustrates a suitable response:

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:UniTime Schedule
X-WR-TIMEZONE:America/Indiana/

Indianapolis
PRODID:-//UniTime 3.4.210 (Purdue)/Schedule Calendar//NONSGML v1.0//EN
BEGIN:VEVENT
DTSTART:20140114T140000Z
DTEND:20140114T151500Z
RRULE:FREQ=WEEKLY;BYDAY=TU,TH;WKST=MO;UNTIL=20140313T141500Z
EXDATE:20140128T140000Z
EXDATE:20140130T140000Z
UID:364547461
SEQUENCE:0
SUMMARY:PHIL 24000 Lec 69621-001
DESCRIPTION:Social And Polit Phil
LOCATION:BRNG 1268
URL:https://esa-oas-prod-wl.itap.purdue.edu/prod/bzwsrch.p_schedule_detail?term=201420&crn=69621
ORGANIZER;ROLE=CHAIR;CN="W. Mcbride":MAILTO:wmcbride@purdue.edu
STATUS:CONFIRMED
END:VEVENT
BEGIN:VEVENT
RECURRENCE-ID:20140311T140000Z
DTSTART:20140311T130000Z
DTEND:20140311T141500Z
UID:364547461
SEQUENCE:0
SUMMARY:PHIL 24000 Lec 69621-001
DESCRIPTION:Social And Polit Phil
LOCATION:BRNG 1268
URL:https://esa-oas-prod-wl.itap.purdue.edu/prod/bzwsrch.p_schedule_detail?term=201420&crn=69621
ORGANIZER;ROLE=CHAIR;CN="W. Mcbride":MAILTO:wmcbride@purdue.edu
STATUS:CONFIRMED
END:VEVENT
BEGIN:VEVENT
RECURRENCE-ID:20140313T140000Z
DTSTART:20140313T130000Z
DTEND:20140313T141500Z
UID:364547461
SEQUENCE:0
SUMMARY:PHIL 24000 Lec 69621-001
DESCRIPTION:Social And Polit Phil
LOCATION:BRNG 1268
URL:https://esa-oas-prod-wl.itap.purdue.edu/prod/bzwsrch.p_schedule_detail?term=201420&crn=69621
ORGANIZER;ROLE=CHAIR;CN="W. Mcbride":MAILTO:wmcbride@purdue.edu
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

7 Best Practices and Implementation Guide

7.1 General

The LIS Best Practices [LIS, 13c] presents a range of best practices that should be followed in the majority of circumstances to support interoperability.

7.2 Specifying the Academic Session

Section 4.6.6 of the LIS Best Practices [LIS, 13c] describes how Group Structures should be included to describe the academic session. That advice should be followed in the CPS application profile. In essence, this Group Structure can describe a term or semester, as shown in the LIS Best Practice.

The SIS should include a valid Group structure in the Core Reference Data. The LIS Best Practices guide should be consulted for more information (section 4.6.6). Course Offerings sent across in the Core Reference Data should have the SourcedId of the Group set as the value of the “academic session” element.

When the PAS returns the course sections, it should ensure that the “academic session” element is completed. The value for this element should be the SourcedId of the group received in the initial Core Reference Data load received from the SIS.

7.3 Delivery Rules

The Scheduling rule language is new, and examples are shown in appendix B of this document. The general best practice advice is that the basic configuration rules need to be sent across first (in the course offerings). Course sections declare which of the configuration rule that they are a part of.

Rules should ideally be as simple as possible, and for a given course the element within the rule refers to a type of class or activity. Best practice is to try to keep the rule simple. If a course consists of ten lectures and a lab, and the lectures are taught by one staff member, then there is no need to encode the rule to show ten different course sections each addressing one of the ten lectures. Rather, a single course section should be created, with an appropriate scheduling repetition structure to show when it occurs over the duration of the course.

Cross Listed sections require an additional section association to be sent, showing the equivalent sections. The individual course sections could also be described in delivery rules in other section associations.

7.4 Validation

When a PAS is used in conjunction with a SIS to schedule students to courses, there needs to be a coordination between the rules used for scheduling students into courses between the two systems. Any validations required for whether a student can be placed into a course should be done in the most appropriate system, but not repeated in both the PAS and the SIS. The reasoning for this is that if both systems are checking for the same items and there is a discrepancy in the rules between the systems it may become impossible for a student to enroll into a course they should be allowed to take. It also prevents the need to maintain the same set of rules in multiple locations. The following is a list of items that should be considered and a decision made whether the PAS or the SIS will do the validation for the item:

    •    Pre-requisites
    •    Co-requisites
    •    Consent of Instructor
    •    Consent of Department
    •    Some other form of Consent
    •    Eligibility to Register for Courses
    •    Reservations for Curriculum, Student Level, etc.
    •    Space available in Course

Pre-requisite, Co-requisite and Eligibility to Register are best done by the SIS in most cases as the SIS has the most up to date data available to perform these checks. However, if the PAS that is being used is capable of performing these checks, then a decision needs to be made about whether the SIS does the checks or the PAS does the checks. It is not recommended to have both systems do the same checking. Also, if it is decided to do the Pre-requisite, Co-requisite and Eligibility to Register checking in the PAS, then this data must be kept up to date in the PAS.

Consent of Instructor, Department, or other types of consent can be done in either place. However, one system or the other should be selected as the system to check the consent to prevent problems from arising when one system shows the student having the proper consent and the other system does not. The system that is selected to check the consent should be used to grant the consent as well as check the consent. The system that is not selected to check consent should be set so that the student does not need consent to get any of the courses.

Reservations for curriculum, student level, etc. are best done by the PAS. Information about reservations is used by the PAS when determining which sections of a course offering are available for a specific student. This information is especially important to the PAS during batch scheduling of students which is a time when the PAS is not receiving real time updates from the SIS about a student’s eligibility to be in a specific section.

The PAS needs to be the system that checks the space available in a course. If the PAS is not the system doing this checking it will be unable to perform its job of scheduling students into courses.

7.5 Event Service Best Practice

It is recommended that the VEVENT component of the iCal format be used to represent the meetings for a course section. The following is a list of some of the properties within VEVENT that may be used and the types of data that should be recorded in those properties:

DTSTART:    - The start date and time for a meeting of the section
DTEND:    - The end date and time for a meeting of the section, typically the date is the same as the start date and the time is later than the start time for the meeting.
RRULE:    - The repetition rule defining how often, and on what dates the event reoccurs. This is very useful for defining meetings for sections that occur at regular intervals throughout a term.
EXDATE:    - If a RRULE is defined this is used to list the dates the recurrence does not meet. This parameter can occur multiple times.
UID:        - A unique identifier for the event. This identifier will be the same in any additional “recurrence” VEVENT records for a section.
SUMMARY:    - User readable information that identifies this section, should contain information such as Subject Area, Course Number and Section Identification.
DESCRIPTION:    - Additional information about the section such as the Course Title
LOCATION:    - Where the section will be meeting. This is typically a building and room, but it can be any string describing where the students will meet. If there are multiple locations where a section meets, all locations should be listed with each being separated by an escaped comma (\,).
ORGANIZER        - this can be used to list a single instructor for the section
ATTENDEE    - this can be used to list additional instructors, if needed, for the meeting of the section. This parameter can be repeated multiple times.
RECURRENCE-ID    - If a section is represented in VEVENT using an RRULE, additional meetings can be added to the section by using another VEVENT with a RECURRENCE-ID. This can also be used to shift recurring event meeting times for reasons such a daylight savings time or a one-off meeting. If RECURRENCE-ID is used, the VEVENT needs to use the same UID as the previous event it is updating.

It is possible to represent a section as many single VEVENT occurrences that all have the same section listed in the summary, however, if this data is imported into a calendaring tool by a user, the meetings will not be tied together in any way by the calendaring tool. If a section is represented as a recurring event using RRULE and RECURRENCE-IDs in the VEVENTs, then all meetings of the section will be treated as a single event by most calendaring tools.

Here is an example of a section of a course represented using recurrences. In the example section skips two meetings in January and shifts the time of the meetings for daylight savings time in March.

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:UniTime Schedule
X-WR-TIMEZONE:America/Indiana/

8 Conformance & Compliance

In the LIS specifications, conformance is typically calculated in terms of synchronization agents and reference agents. As CPS allows for both the SIS and PAS to effectively be reference agents and synchronization agents, conformance for CPS is instead based on the type of system claiming conformance.

Further, the CPS application profile denotes a number of ways in which data can be exchanged. Conformance is based upon the simplest of those scenarios, namely:

SIS initiated Core Data Service Choreography (Figure 4.5)
PAS initiated Update Service Choreography (Figure 4.8)

Compliance to CPS for a Student Information System means:

a) Support the Bulk Data Exchange Management Service such that:

Be a service consumer for the “reportBulkDataExchange”, “announceBulkDataExchange” and “HTTPSget” operations.
Be a service provider for the “announceBulkDataExchange”, “reportBulkDataExchange” and HTTPSget operations.
Support the SOAPv1.1 messages for the operations.
Support the set of status codes returned in the response messages.
As a service provider reject the unsupported operations with the status code ‘unsupported’.
Support the fill bulk data models for the operations (either the full data model or a proper subset).
Support the extensions to the data models in their entirety (see section 4.4).
Get and process the set of received bulk data files.
Create the bulk data files and make them available for HTTPS download.
Support the external VDEX vocabularies specific to this service.

b) Support the Membership Management Service such that:

Be a service provider for the “deleteMembership” and “replaceMembership” operations.
Be a service provider for the “readMemebership” operations during the conformance testing activity (this may then be disabled).
Support the SOAP v1.1 messages for the operations.
Support the set of status codes returned in the response messages.
As a service provider reject the unsupported operations with the status code “unsupported”
Support the Membership data model for the operations (either the full data model or a proper subset)
Support the extensions to the Membership data model in their entirety (see section 4.4).
Support the external VDEX vocabularies specific to this service;

c) Support the Course Management Service such that:-

Be a service provider for the “deleteCourseSection”, “deleteSectionAssociation”, “deleteCourseOffering” “replaceCourseSection” and “replaceSectionAssociation”, “replaceCourseOffering” operations.
Be a service provider for the “readCourseSection” and “readSectionAssociation” operations during the conformance testing activity (these may then be disabled).
Support the SOAP v1.1 messages for the operations.
Support the set of status codes returned in the response messages (see Table 7.3)
As a service provider reject the unsupported operations with the status code “unsupported”
Support the CourseSection, CourseOffering and SectionAssociation data models for the operations (either the full data models or a proper subset)
Support the extensions to the CourseSection, CourseOffering and SectionAssociation data models in their entirety (see section 4.4).
Support the external VDEX vocabularies specific to this service;

Compliance to CPS for a Planning and Allocation System means:

a) Support the Bulk Data Exchange Management Service such that:

Be a service consumer for the “reportBulkDataExchange”, “announceBulkDataExchange” and “HTTPSget” operations.
Be a service provider for the “announceBulkDataExchange”, “reportBulkDataExchange” and HTTPSget operations.
Support the SOAPv1.1 messages for the operations.
Support the set of status codes returned in the response messages.
As a service provider reject the unsupported operations with the status code ‘unsupported’.
Support the fill bulk data models for the operations (either the full data model or a proper subset).
Support the extensions to the data models in their entirety (see section 4.4).
Get and process the set of received bulk data files.
Create the bulk data files and make them available for HTTPS download.
Support the external VDEX vocabularies specific to this service.

b) Support the Membership Management Service such that:

Be a service consumer for the “deleteMembership” and “replaceMembership” operations.
Support the SOAP v1.1 messages for the operations.
Support the Membership data model for the operations (either the full data model or a proper subset)
Support the extensions to the Membership data model in their entirety (see section 4.4).
Support the external VDEX vocabularies specific to this service;

c) Support the Course Management Service such that:-

Be a service consumer for the “deleteCourseSection”, “deleteSectionAssociation”, “deleteCourseOffering” “replaceCourseSection”, “replaceCourseOffering” and “replaceSectionAssociation” operations.
Support the SOAP v1.1 messages for the operations.
Support the CourseSection, CourseOffering and SectionAssociation data models for the operations (either the full data models or a proper subset)
Support the extensions to the CourseSection and SectionAssociation data models in their entirety (see section 4.4).
Support the external VDEX vocabularies specific to this service;

d) Support the Event Service such that:

Be a service provider for the “SimpleSchedule” and” AdvancedSchedule” operations
Support the HTTP GET interface for the operations.
Support the iCalendar data model for the operations (either the full data model or a proper subset)

8.1 Bulk Data Exchange Service Statement

Refer to the LIS Profiles document [LIS, 13b] for the basic statements for this service. Changes to the basic statement are show below.

8.1.1 Service Statement: SIS to PAS

The set of operations, supported by SIS and PAS, in the “core data load” of information from the SIS to the PAS, is show in table 7.1.

Operation	SIS	PAS
annouceBulkDataExchange	Calls	Implements
announceBulkDataExchangeFailure
reportBulkDataExchange	Implements	Calls
requestBulkDataExchange
cancelBulkDataExchange
ignoreBulkDataExchange
HTTPS/GET	Implements	Calls

Table 7.1: Core Data Load operations

8.1.2 Payload Data: SIS to PAS

For conformance, the BDEMS must transfer a valid Bulk Data payload file. The LIS Specification details the format of this file. In essence, the file contains xml representations of live service operations. Each of those operations has parameters. Table 7.2 shows the operations that will be checked for conformance. Table 7.3 shows the data elements within those operations that will be further checked.

Service	Operation
Course Management	replaceCourseTemplate
Course Management	deleteCourseTemplate**
Course Management	replaceCourseOffering
Course Management	deleteCourseOffering**
Person Management	replacePerson
Person Management	deletePerson**
Membership Management	replaceMembership
Membership Management	deleteMembership**

Table 7.2: Core Data Load Message Request Set, SIS to PAS

** SISs are not required to send bulk delete messages.

Service	Data Type	Element	Notes
Course Management	CourseTemplateRecord	SourcedId
		Title
		Org
Course Management	CourseOfferingRecord	SourcedId
		Title
		Org
		Configuration.X.Description	Optional
Person Management	PersonRecord	SourcedId
		Name	See LIS Core Profile, Section 3.2.2
		Institution Role	“Learner” or “Instructor”. See LIS Core Profile, Section 3.2.2
Membership Management	MembershipRecord	SourcedId
		collectionSourcedId	Of Course Offering
		personSourcedId
		Role	See LIS Core Profile, Section 3.4.2
		RoleType	“Learner”
		MembershipType	“INTENTION”

Table 7.3 Core Data Load – Payload Data Types

8.1.3 Service Statement: PAS to SIS

The set of operations, supported by SIS and PAS, in the “initial scheduling work” phase, is shown in table 7.2 Information moves from the PAS to the SIS.

Operation	SIS	PAS
annouceBulkDataExchange	Implements	Calls
announceBulkDataExchangeFailure
reportBulkDataExchange	Calls	Implements
requestBulkDataExchange
cancelBulkDataExchange
ignoreBulkDataExchange
HTTPS/GET	Calls	Implements

Table 7.4: Initial Scheduling Work operations

8.1.4 Payload Data: PAS to SIS

For conformance, the BDEMS must transfer a valid Bulk Data payload file. The LIS Specification details the format of this file. In essence, the file contains xml representations of live service operations. Each of those operations has parameters. Table 7.5 shows the operations that will be checked for conformance. Table 7.6 shows the data elements within those operations that will be further checked.

Service	Operation
Course Management	replaceCourseOffering
Course Management	deleteCourseOffering**
Course Management	replaceCourseSection
Course Management	deleteCourseSection**
Course Management	replaceSectionAssociation
Course Management	deleteSectionAssociation**
Membership Management	replaceMembership
Membership Management	deleteMembership**

Table 7.5: Initial Scheduling Work Message Request Set, PAS to SIS

** PASs are not required to send bulk delete messages.

Service	Data Type	Element	Notes
Course Management	CourseOfferingRecord	SourcedId
		Title
		Org
		Configuration.X.Description	Optional
		Configuration.X.ID	1 or more
		Configuration.X.Rule	1 or more
Course Management	CourseSectionRecord	SourcedId
		ParentSourcedId	Of Offering
		Title
		Location
		Max Number of Students
		TimeFrame	Absolute start and end dates for the section
		Meeting	iCalendar description of Dates, Times and Rooms
		Configuration.Id
		SectionType
		Order
Course Management	SectionAssociationRecord*	SourcedId
		courseSectionIdList	List of the (child) course sections
		Status	“Active”
		ParentCourseSection
		AssociationType	“DELIVERY_RULE”
Course Management	SectionAssociationRecord*	SourcedId
		courseSectionIdList	List of the (child) course sections
		Status	“Active”
		MaximumNumbers	“ADDITIVE” or “MAXIMUM”
		Association Type	“CROSS_LIST”
Membership Management	MembershipRecord	SourcedId
		collectionSourcedId	Of Course Offering
		personSourcedId
		Role	See LIS Core Profile, Section 3.4.2
		RoleType	“Learner”
		MembershipType	“SCHEDULED”
Membership Management	MembershipRecord	SourcedId
		collectionSourcedId	Of Course Offering
		personSourcedId
		Role	See LIS Core Profile, Section 3.4.2
		RoleType	“Instructor”
Membership Management	MembershipRecord	SourcedId
		collectionSourcedId	Of Course Section
		personSourcedId
		Role	See LIS Core Profile, Section 3.4.2
		RoleType	“Learner”
		MembershipType	“SCHEDULED”
Membership Management	MembershipRecord	SourcedId
		collectionSourcedId	Of Course Section
		personSourcedId
		Role	See LIS Core Profile, Section 3.4.2
		RoleType	“Instructor”

Table 7.6 Initial Scheduling Work – Payload Data Types

* For conformance, testing will be done on the type of section association present. Systems should be able to produce and consume section associations of both types.

8.2 Membership Management Service Statement

8.2.1 Service Statement

The set of operations, supported by SIS and PAS, to support live updates from the PAS, is shown in table 7.7

Operation	SIS	PAS
createMembership
createByProxyMembership
deleteMembership	Implements	Calls
readMembership*	Implements	Calls
readMembershipIdsForPerson
readMembershipIdsForPersonWithRole
readMembershipIdsForCollection
readAllMembershipIds
readMembershipIdsFromSavePoint
readMemberships
readMembershipsFromSavePoint
updateMembership
replaceMembership	Implements	Calls
discoverMembershipIds
changeMembershipIdentifier

Table 7.7: Live Update: Membership Service

* For conformance testing only

8.2.2 Data Model Statement

For conformance, membership calls made by the PAS will be checked for the presence of at least the following elements:

Service	Data Type	Element	Notes
Membership Management	MembershipRecord	SourcedId
		collectionSourcedId	Of Course Section
		personSourcedId
		Role	See LIS Core Profile, Section 3.4.2
		RoleType	“Learner”
		MembershipType	“SCHEDULED”
Membership Management	MembershipRecord	SourcedId
		collectionSourcedId	Of Course Section
		personSourcedId
		Role	See LIS Core Profile, Section 3.4.2
		RoleType	“Instructor”

Table 7.8: Live Update Membership Data Types

8.3 Course Management Service Statement

8.3.1 Service Statement

The set of operations, supported by SIS and PAS, to support live updates from the PAS, is shown in tables 7.9, 7.10 and 7.11

Operation	SIS	PAS
createCourseOffering
createByProxyCourseOffering
createCourseOfferingFromCourseOffering
deleteCourseOffering	Implements	Calls
readCourseOffering*	Implements	Calls
readAllCourseOfferingIds
readAllActiveCourseOfferingIdsForAcademicSession
readCourseSectionIdsForCourseOffering
readCourseOfferingIdsFromSavePoint
readCourseOfferings
readCourseOfferingsFromSavePoint
replaceCourseOffering	Implements	Calls
updateCourseOffering
updateCourseOfferingStatus
discoverCourseOfferingIds
changeCourseOfferingIdentifier

Table 7.9: Live Update: Course Offering Service

Operation	SIS	PAS
createCourseSection
createByProxyCourseSection
createCourseSectionFromCourseSection
deleteCourseSection	Implements	Calls
readCourseSection*	Implements	Calls
readAllCourseSectionIds
readCourseSectionIdsFromSavePoint
readCourseSections
readCourseSectionsFromSavePoint
replaceCourseSection	Implements	Calls
updateCourseSection
updateCourseSectionStatus
discoverCourseSectionIds
changeCourseSectionIdentifier

Table 7.10: Live Update: Course Section Service

Operation	SIS	PAS
createSectionAssociation
createByProxySectionAssociation
deleteSectionAssociation	Implements	Calls
readSectionAssociation*	Implements	Calls
readAllSectionAssociationIds
readSectionAssociationIdsFromSavePoint
readSectionAssociations
readSectionAssociationsFromSavePoint
addCourseSection
removeCourseSection
replaceSectionAssociation	Implements	Calls
updateSectionAssociation
discoverSectionAssociationIds
changeSectionAssociationIdentifier

Table 7.11 Live Update: Section Association Service

* For conformance testing only

8.3.2 Data Model Statement

For conformance, course management calls made by the PAS will be checked for the presence of at least the following elements:

Service	Data Type	Element	Notes
Course Management	Course Offering	SourcedId
		Title
		Org
		Configuration.X.Description	Optional
		Configuration.X.ID	1 or more
		Configuration.X.Rule	1 or more
Course Management	Course Section	SourcedId
		ParentSourcedId	Of Offering
		Title
		Location
		Max Number of Students
		TimeFrame	Absolute start and end dates for the section
		Meeting	iCalendar description of Dates, Times and Rooms
		Configuration.Id
		SectionType
		Order
Course Management	Section Association*	SourcedId
		courseSectionIdList	List of the (child) course sections
		Status	“Active”
		ParentCourseSection
		AssociationType	“DELIVERY_RULE”
Course Management	Section Association*	SourcedId
		courseSectionIdList	List of the (child) course sections
		Status	“Active”
		MaximumNumbers	“ADDITIVE” or “MAXIMUM”
		Association Type	“CROSS_LIST”

Table 7.12 Live Update Course Management Data Types

* For conformance, testing will be done on the type of section association present. Systems should be able to produce and consume section associations of both types.

8.4 Event Service Statement

8.4.1 Service Statement

Operation	SIS	PAS
simpleSchedule	Calls	Implements
advancedSchedule	Calls	Implements

Table 7.13 Event Service Statement

8.4.2 Data Mode Statement

The Event service must produce data that is compliant to iCalendar. iCalendar is a large specification, so for conformance purposes, the messages must contain the following data fields as a minimum.

Service	Data Type	Element	Notes
Event	Calendar	BEGIN:VCALENDAR
		VERSION	“2.0”
		PRODID
		END:VCALENDAR
	Event	BEGIN:VEVENT	One or more
		UID
		ORGANIZER
		DTSTART
		DTEND
		SUMMARY
		END:VEVENT

Table 7.14: Event Service Data Types

Appendix A – Glossary

Activity	This is the atomic unit that can be scheduled. It could be a class and records the resources that have been allocated to the activity; resources allocated can include faculty, equipment and rooms. An Activity can have a repetition pattern, e.g. Monday-Wednesday-Friday for each week of an academic period. Different resources can be allocated in a particular week and day.
Award	This is the Program of Study, or the Qualification, and as such includes the Degree to be awarded and the corresponding Outcome.
Bulk Data Exchange Management Service (BDEMS)	This service is used for the exchange of bulk LIS data. It is used to establish the initial data synchronization and for period synchronization activities. The data is exchanged in a series of data files.
Course Management Service (CMS)	This is the service in LIS that supports the exchange of course structures. The exchange structure is based upon the first class objects of Course Template, Course Offering, Course Section and Section Association. Each object is manipulated using a dedicated service interface.
Course Offering	A Course Offering is the occurrence of a course in a specific term, semester, etc. A Course Template can have several Course Offerings and each Course Offering can have several Course Sections. If the Course Template instance is English 101 then the Course Offerings could be English 101 (Semester 1) and English 101 (Semester 2). A Course Offering has one or more Activities.
Course Schedule	The set of Activities associated with a Course Offering.
Course Section	A Course Section is a way to represent a group of people associated with a course or class. These groups may include everyone in the class or course, or may be subsets of that whole group. Course Sections may have sub-sections Examples of a Course Section are Lecture, Laboratory, Studio, Seminar, etc. There may be several instances of a type of Course Section e.g. multiple lectures. Several Course Sections can be associated using the Section Association capability in the CMS. A Course Section will have one or more Events associated with it. A Course Section does not have any resources, and is not scheduled.
Course Template	A Course Template is a general course that exists across terms, semesters, etc. It is an abstract course representation. Examples of instances of Course Templates are Biology 101, Mathematics Module 2, etc.
Department	An organizational group
Equipment	A schedulable resource that can be allocated to an Activity.
Event	This is a scheduled Activity that takes place. A Schedule/Timetable is composed of a set of Events.
Faculty	A member of teaching staff. Defined as a Person in LIS. See Staff.
FM System	Facilities Management System
GWS	1EdTech General Web Services v1.0 specification. GWS provides a basic structure for the definition of Web Services. It consists of a set of non-proprietary Web Services specifications, along with clarifications and amendments to those specifications that promote interoperability.
I-BAT	1EdTech Binding Auto-generation Tool-kit. This is the 1EdTech/GLC Tool-kit that is used to transform the UML based Information Model representation into the equivalent 1EdTech General Web Services WSDL and XSD bindings.
1EdTech GLC	1EdTech Consortium Inc.
Learning Information Services (LIS) v2.0	The 1EdTech Learning Information Services (LIS) v2.0 specification is the collection of the Person Management Service, Group Management Service, Membership Management Service, Course Management Service, Outcomes Management Service and Bulk Data Exchange Management Service. The LIS supports a wide range of use-cases, particularly for SIS/LMS interoperability.
Membership Management Service (MMS)	This is the service in the LIS that is responsible for the management of Membership objects. The service supports the manipulation of a single Membership object, defined under the MembershipManager interface.
Outcome	The educational achievement gained by the successful completion of a Course. The Course Template can represent an Outcome for pre-requisite and co-requisite validation purposes.
Pathway	A set of activities that will deliver a set of Courses.
Person Management Service (PMS)	This is the service in the LIS that is responsible for the management of Person objects. The service supports the manipulation of a single Person object, defined under the PersonManager interface.
PIM	Platform Independent Model. 1EdTech/GLC create a PIM representation of the service being specified as part of the Information model documentation. This representation is converted to the 1EdTech PSM equivalent.
Planning & Allocation System (PAS)	This is the dedicated system that undertakes the course planning and scheduling activity. The PAS makes the corresponding course schedules/timetables available to other systems.
PSM	Platform Specific Model. 1EdTech/GLC create the PSM form of the Information Model PIM used a set of transformation rules. The PSM form is then sued as input to the I-BAT to create the WSDL and XSD bindings.
SDN	Specification Development Note. SDNs are produced by 1EdTech GLC to describe how the selected methodologies, techniques, tools and technologies are to be used by 1EdTech/GLC when creating specifications.
Section Association	This is structure within the LIS 2.0 specification, the CMS, which enables a set of Course Sections to be grouped together. The CMS allows Course Sections to be added or removed from an established Section Association.
Staff	A Faculty member. Defined as a Person in LIS. See Faculty.
Student	A Person that enrolls onto one or more Courses. Defined as a Person in LIS.
Timetable	This is the schedule of activities for the associated object. There are many types of schedules/timetables e.g. for a Student, Faculty, a Room, etc.
WSDL	Web Services Description Language. WSDL v1.1 is used as the basis for 1EdTech GLC Web Services-based bindings.

Appendix B – Configuration and Scheduling Rules

Course 101 is a course requiring some specified amount time to be scheduled each week for lecture, discussion, laboratory exercises and a weekly quiz.

There is only one configuration:

Config A {Lec, Dis, Lab, Quiz}

The expected enrolment in the course is 120 students. The Lecture can be taught to a class of 60 students, the discussion and laboratory classes are limited to 20 students each, and quizzes are given to all students at one time. Professor Smith can teach one of the lectures and has three graduate teaching assistants who can each teach one discussion class and one laboratory class. Students should take discussion and laboratory classes with the same instructor. Professor Jones can teach the other lecture and has arranged discussions and laboratories in a similar manner as Professor Smith. The classes that need to be created are as follows:

Class Size Instructor

Lec1 60 Smith

Dis1 20 Smith TA 1

Lab1 20 Smith TA 1

Dis2 20 Smith TA 2

Lab2 20 Smith TA 2

Dis3 20 Smith TA 3

Lab3 20 Smith TA 3

Lec2 60 Jones

Dis4 20 Jones TA 1

Lab4 20 Jones TA 1

Dis5 20 Jones TA 2

Lab5 20 Jones TA 2

Dis6 20 Jones TA 3

Lab6 20 Jones TA 3

Quiz1 120 Schwartzenegger

The delivery rules restricting valid class combinations are therefore:

Lec1 : {Dis1, Dis2, Dis3}

Lec2 : {Dis4, Dis5, Dis6}

Dis1 : {Lab1}

Dis2 : {Lab2}

Dis3 : {Lab3}

Dis4 : {Lab4}

Dis5 : {Lab5}

Dis6 : {Lab6}

The Comma delimiter indicates an “OR” relationship. So a Student on Lecture1 must take one of Discussion1, Discussion2 or Discussion 3.

All students must take the quiz section so no other delivery rule is required beyond the configuration, which states that all students must take one Lecture, one Discussion, one Laboratory, and one Quiz section.

Course 102 is a course requiring students to attend a specified amount of time in lecture and discussion. There is also a laboratory component that can either be satisfied by attending a group lab prep session and two hours in the laboratory, or by attending a three hour laboratory.

The course has two possible configurations:

Config A {Lec, Dis, LabP, Lab}

Config B {Lec, Dis, Lab}

The expected enrolment in the course is 120 students. A single lecture can be taught to all 120 students. The discussion and lab prep classes are limited to 40 students each. Laboratories have 20 spaces. Professor Smith prefers to teach the class with a laboratory prep session and less time in the laboratory. Professor Smith leads all of the discussion classes. A single teaching assistant is responsible for one lab prep section and two associated laboratory classes. Students are required to take lab prep and laboratory classes with the same instructor. The classes that need to be created are as follows:

Class Size Instructor

Lec1 120 Smith

Dis1 40 Smith

Dis2 40 Smith

Dis3 40 Smith

LabP1 40 Smith TA 1

Lab1 20 Smith TA 1

Lab2 20 Smith TA 1

LabP2 40 Smith TA 2

Lab3 20 Smith TA 2

Lab4 20 Smith TA 2

LabP3 40 Smith TA 3

Lab5 20 Smith TA 3

Lab6 20 Smith TA 3

The delivery rules restricting valid class combinations for Config A are therefore:

LabP1 : {Lab1, Lab2}

LabP2 : {Lab3, Lab4}

LabP3 : {Lab5, Lab6}

When professor Jones teaches this class he prefers smaller lectures and more time in the laboratory and no laboratory prep session. Professor Jones also has teaching assistants conduct the discussion classes and two associated laboratory classes. Students are required to take discussion and laboratory classes with the same instructor. The classes that need to be created are as follows:

Class Size Instructor

Lec1 40 Jones

Dis1 40 Jones TA 1

Lab1 20 Jones TA 1

Lab2 20 Jones TA 1

Lec2 40 Jones

Dis2 40 Jones TA 2

Lab3 20 Jones TA 2

Lab4 20 Jones TA 2

Lec3 40 Jones

Dis3 40 Jones TA 3

Lab5 20 Jones TA 3

Lab6 20 Jones TA 3

The delivery rules restricting valid class combinations for Config B are therefore:

Lec1 : {Dis1}

Lec2 : {Dis2}

Lec3 : {Dis3}

Dis1 : {Lab1, Lab2}

Dis2 : {Lab3, Lab4}

Dis3 : {Lab5, Lab6}

The general format of the rules is as follows:

A course may have one or more configurations stating the required subparts: Config X {Subpart A, Subpart B, …}

Rules restricting valid class combinations are of the form: Parent Class : { Child Class 1, Child Class 2, …}

These latter rules are expressed as SectionAssociations in LIS, using the sourcedIds of the various course sections. The parent course section needs to be represented as such via the extension mechanism.

About This Document

Title: 1EdTech Course Planning and Scheduling

Editor: Phil Nicholls (1EdTech)

Co-chairs: Geoffrey Forster (Scientia)

Version: 1.0

Version Date: 31 December 2013

Status: Candidate Final

Summary: The Course Planning and Scheduling (CPS) specification provides interoperability between a Planning & Allocation System and other systems e.g. Student Information Systems. The initial focus of the work is for interoperability about ‘Student-optimized educational offerings’ in which students identify the Courses they wish to take, followed by the creation, by the Planning & Allocation System, of the right number of activities to satisfy the student demand and to create optimized schedules for students, faculty and facilities. Real-time amendment and re-creation of these schedules is also undertaken by the Planning & Allocation System in response to changing demands and resource constraints. Interoperability is based upon a profile of the 1EdTech Learning Information Services (LIS) v2.0 specification combined with the use of the IETF RFC5545 iCalendar.

Revision Information: Original document.

Purpose: This document is made available for review by the 1EdTech community and general public.

Document Location: http://www.imsglobal.org/cps/

List of Contributors

The following individuals contributed to the development of this document:

Geoffrey Forster Scientia Ltd. (UK)

Linda Feng Oracle (USA)

Keith Murray Unitme.org (USA)

Phil Nicholls 1EdTech (UK)

Colin Smythe 1EdTech (UK)

Stephanie Schluttenhofer Unitime.org (USA)

Revision History

Version No.	Release Date	Comments
Candidate Final v1.0	31 December 2013	The first candidate public release of the CPS/LIS application profile.

1EdTech Consortium, Inc. (“1EdTech”) is publishing the information contained in this 1EdTech Learning Tools Interoperability Implementation Guide (“Specification”) for purposes of scientific, experimental, and scholarly collaboration only.

1EdTech makes no warranty or representation regarding the accuracy or completeness of the Specification. This material is provided on an “As Is” and “As Available” basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

1EdTech would appreciate receiving your comments and suggestions.

Please contact 1EdTech through our website at http://www.imsglobal.org

Please refer to Document Name: 1EdTech Course Planning and Scheduling v1.0 Candidate Final
Revision: 31 December 2013

[1] These use-cases were created as part of the Chartering of the CPS work. Originally four core scenarios were identified with a number of variants. The use-cases in this document are for the Scenario 3 in the Charter.

1EdTech Course Planning and Scheduling (CPS/LIS)

Version 1.0 Candidate Final

© 2013 1EdTech Consortium, Inc. All Rights Reserved.

Table of Contents

Table of Figures

1 Introduction

1.1 Course Planning & Scheduling Overview

1.2 Scope and Context

1.3 Structure of this Document

1.4 Nomenclature

1.5 References

2 CPS/LIS Key Use Cases

3 CPS/LIS Architecture

3.1 System Architecture

3.2 Service Orchestration

3.3 Logical Data Model

4 LIS Profile for CPS

4.1 LIS Interface

4.2 Core Service Choreography

4.3 Update Service Choreography

4.4 LIS Data Model and extensions

4.4.1 Modifications to Membership

4.4.2 Modifications to Course Section

Mandatory Extensions:

Optional Extensions to Course Section

4.4.3 Modifications to Course Offering

4.4.4 Modifications to Section Association

4.4.5 Recommended Minimum Data – CORE Reference Data:

4.4.6 Recommended Minimum Data – Student Intentions

4.4.7 Recommended Minimum Data – from PAS

4.4.8 Recommended Minimum Data – Live Updates from SIS

5 CPS Event Interoperability

5.1 Event Service Interface

5.2 Event Service Description

5.2.1 SimpleSchedule

5.2.2 AdvancedSchedule

5.3 iCalendar Data Model

6 CPS/LIS Binding

6.1 LIS

6.2 Event Service

7 Best Practices and Implementation Guide

7.1 General

7.2 Specifying the Academic Session

7.3 Delivery Rules

7.4 Validation

7.5 Event Service Best Practice

8 Conformance & Compliance

8.1 Bulk Data Exchange Service Statement

8.1.1 Service Statement: SIS to PAS

8.1.2 Payload Data: SIS to PAS

8.1.3 Service Statement: PAS to SIS

8.1.4 Payload Data: PAS to SIS

8.2 Membership Management Service Statement

8.2.1 Service Statement

8.2.2 Data Model Statement

8.3 Course Management Service Statement

8.3.1 Service Statement

8.3.2 Data Model Statement

8.4 Event Service Statement

8.4.1 Service Statement

8.4.2 Data Mode Statement

Appendix A – Glossary

Appendix B – Configuration and Scheduling Rules

About This Document

List of Contributors

Revision History

© 2013 1EdTech Consortium, Inc.
All Rights Reserved.