IMS Candidate Final

IMS 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.

IMS 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 IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: sites/default/files/imsipr_policyFinal.pdf.

Copyright © 2013 IMS Global Learning Consortium. All Rights Reserved.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS 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 IMS 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 IMS Global Learning Consortium, Inc.
All Rights Reserved.

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

Table of Contents

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

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

Index

 

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 IMS Global 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 IMS Global and non-IMS Global 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                         IMS Global Abstract Framework

IETF                       Internet Engineering Task Force

IMS Global           IMS Global Learning 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] IMS GLC Abstract Framework: Applications, Services & Components v1.0, Ed. C.Smythe, IMS Global Learning Consortium, July 2003.

[IAF, 03b] IMS Abstract Framework: Glossary v1.0, Ed. C.Smythe, IMS Global Learning Consortium, July 2003.

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

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

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

[LIS, 13c]              IMS Global Learning Information Services v2.0.1 Specification Final Release, L.Feng and P.Nicholls, IMS Global Learning 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 IMS [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

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

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 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)

 

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 IMS 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 IMS 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 IMS 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 IMS 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 IMS 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 IMS 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/

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

 

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

IMS 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

IMS Binding Auto-generation Tool-kit.   This is the IMS/GLC Tool-kit that is used to transform the UML based Information Model representation into the equivalent IMS General Web Services WSDL and XSD bindings.

IMS GLC

IMS Global Learning Consortium Inc.

Learning Information Services (LIS) v2.0

The IMS 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.  IMS/GLC create a PIM representation of the service being specified as part of the Information model documentation.  This representation is converted to the IMS 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.  IMS/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 IMS GLC to describe how the selected methodologies, techniques, tools and technologies are to be used by IMS/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 IMS 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:                                                      IMS Global Course Planning and Scheduling

Editor:                                                  Phil Nicholls (IMS Global)

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 IMS 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 IMS 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                          IMS Global (UK)

Colin Smythe                       IMS Global (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.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

IMS Global 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.

IMS Global would appreciate receiving your comments and suggestions.

Please contact IMS Global through our website at http://www.imsglobal.org

Please refer to Document Name: IMS Global 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.