1EdTech Learning Information Services Learning Systems: Profiles Overview
Version 2.0.1
Final Release
Date Issued: 30 September 2013
Latest version: http://www.imsglobal.org/lis/
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: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf .
Copyright © 2013 1EdTech Consortium. All Rights Reserved.
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.
1 Introduction
The Learning Systems: Profiles Overview provides system implementers with the minimum subset of the Learning Information Service (LIS) specification required to ensure interoperability for a set of core use cases that drove the creation of the specification. The LIS base specification is very broad and was designed with a number of forward-looking possible use cases in mind. In contrast, conformance profiles are intended to help developers interested in a very specific subset of use cases to (a) identify the portions of the specification that they need to care about for their purposes, (b) ensure maximum interoperability with integration partners by ensuring that everyone is implementing those critical portions the same way, and (c) provide best practice guidance to further ease implementation and support interoperability.
The Learning Systems: Profiles Overview is focused on use cases involving integration between a Student Information System (SIS) or similar administrative system and a Learning Management System (LMS) or any other learning system that needs information about which students are enrolled in which course sections. In essence, it supports a moderate expansion of the range of use cases that 1EdTech Enterprise Services (the predecessor specification for LIS) was intended to support. This document will refer to changes in relation to Enterprise Services as a convenience for developers who are familiar with it; however, no knowledge of Enterprise Services is required to read this document.
2 The Profiles
The conformance profile is divided into several module that address different use cases. 1EdTech will provide an easy-to-read trademarked label for systems to advertise which portions of the profile they support.
The most critical module of Learning Systems: Profiles is the Core Profile, which is the foundation of the profile and can be considered to be a relatively modest refinement of the Enterprise Services predecessor specification. Core ensures that course section, person, and enrollment information can be sent from the administrative system to the learning system. No application can be said to be conformant to the Core Profiles without demonstrating conformance to Core.
In addition, the profile includes several optional Additional Profiles:
· Final Grade Reporting – this profile ensures that final course grades can be transmitted from an online grade book in the learning system to the administrative system. It is optional for learning systems only. For administrative systems, final grade reporting should be included in Core;
· Combined Sections – this profile provides a mechanism by which the administrative system can provide semantic hints to the learning system about which separate course sections are related and may make sense to combine into one course site or otherwise associate within the learning system. Typical cases include cross-listed courses and multi-section courses e.g., lecture/lab/discussion combinations;
· Full Course Hierarchy – this profile enables administrative systems to provide learning systems with additional information about how particular course sections are related to the broader course catalog. For example, a particular time-bound instance of a Biology 101 section can be tied to a broader category of all Biology 101 sections.
3 The Core Profile
The Core module provides a range of improvements over the Enterprise Services specification:
· A CourseSection record type has been created distinct from the generic Group record type in order to provide more rich and standardized handling of course information;
· The Person record has been harmonized with the Learner Information Package (LIP) specification and provides richer information;
· The services model for provisioning data from the administrative system to the learning system has been refined to include a full batch snapshot, an incremental (by savepoint) snapshot, and event-driven notification via SOAP Web Services.
In addition to these major changes, other more minor changes have been made throughout the information and service models. Implementers who are updating a pre-existing Enterprise Services capability should look carefully at the relevant portions of the specification.
3.1 The Information Model
Both learning systems and administrative systems will need to support the following four record types in order to conform to the Core Profile:
Person – this record includes some changed and expanded fields but is unchanged in basic function from Enterprise Services; namely, to provision information about each person from the administrative system to the learning system;
Course Section – this record type does not exist in Enterprise Services, which used the generic Group record type for course information. Course Section is somewhat similar in function to Group but is specifically designed to provision course section information from the administrative systems to the learning systems;
Group – the Group record type has been preserved with minor modifications from the Enterprise Services specification. Group is a very powerful generic construct that can be used to form a variety of nested/hierarchical structures. The primary uses within this profile, is to use groups to convey course term information as outlined in the Best Practices document for the profile;
Membership – membership records tie Person records to either Course Section or Group records. The grade reporting features have been removed to the Result record as part of the Outcomes data model.
3.1.1 The Service Model
For provisioning of the main four record types described above from the administrative system to the learning system, the Core Profile requires support of both batch and event-driven provisioning. In the Core Profile, the batch provisioning, realized as the Bulk Data Exchange Management Service (BDEMS) is initiated by the administrative system, which makes a SOAP-based announcement for a snapshot (as shown in Figure 1).
Figure 1 – Administration system driven snapshot.
When making the announcement, the administrative system prepares the flat file(s) and with the SOAP message containing the URL(s) of the file(s) containing the batch data. The learning system completes the operation by fetching the file via HTTPS/SSL3.
In the Core Profile the event-driven provisioning is also initiated by the administrative system (as shown in Figure 2). When appropriate events trigger updates, e.g., a student enrolls in a class section, the administrative system sends a SOAP payload with the appropriate create, update, and/or delete information.
Figure 2 – Administration system driven event messaging.
These service models are intended to be complementary. For example, a system administrator may wish to use a full synchronization snapshot at the beginning of the semester to transfer the large number of new course sections. After initialization, the administrator may choose to use regular batch processes that update from the previous synchronization save point (also called an incremental batch). It is also possible to use the event-driven method to update the learning systems in near-real-time and then use an incremental batch periodically to ensure that no event-driven messages were accidentally dropped.
Final Grade reporting has a separate service model, which is described in the next section.
4 The Addition Profiles
4.1 The Final Grade Reporting Module
The full LIS specification provides a robust outcomes reporting mechanisms that can be used to exchange grade information for a wide range of use cases. However, the Learning Systems: Profiles is only concerned with the reporting of final course grades from learning systems to administrative systems, the profile only requires a small subset of the capabilities outlined in the base specification. Many Administrative systems are required to implement Final Grade Reporting as part of their primary requirements. However, not all learning systems (particularly non-LMS learning systems) will have final grade capabilities, and so this is an optional module.
Final Grade Reporting requires the support of the Outcome LineItem and Result objects. An Outcome is tied to both a particular student record and a particular course section record. This means that learning systems implementers that merge several sections into one course site will need to persist LIS course section membership relationships so that the administrative system will know where to assign the final grade.
As shown in Figure 3, this service can initiated either by a read request from the administrative system to the learning system (pull) or by the learning system (push). A read request is scoped at the course section level, possibly triggered manually by a faculty member from the administration system’s grade roster page (although whether and how the request is triggered is an implementation decision and not defined in the profile). The learning system replies by providing the Outcome results for every Person in the Course Section. A replace request is constructed by the learning system that then drives the appropriate copying of the data in the administration system.
Figure 3 – Final grade reporting.
4.2 The Combined Sections Module
Very often, the teachers working in the learning systems want students from several sections (as they are defined in the administrative system) grouped together in some way e.g., sharing one course site. Often, though not always, the administrative system has information that may indicate in advance how the teachers are likely to want to assign these groupings. For example, two separate sections of a cross-listed course may actually share the same teacher in the same room at the same dates and times despite having different course numbers. Because the Enterprise Services specification did not provide a standard method for indicating these relationships, adopting institutions often built custom middleware that combined the section records, destroying the common mapping between the administrative system and the learning system in the process. The Combined Sections module provides a non-destructive method for administrative systems to indicate semantic relationships between sections so that learning systems may provide course site provisioning options to the users.
To accomplish this, LIS provides a new record type called Section Association. A Section Association record simply indicates a semantic relationship between two or more Course Section records. Simpler learning systems that implement the module may choose to simply create course groups that are the union of the memberships of the sections. Alternatively, the learning system may provide options to teachers at course site provisioning time. The types of service operations required for this module are identical to those required for the Core module.
4.3 The Full Course Hierarchy Module
Sometimes it is helpful to be able to provide teachers and students with more information about how similar sections relate to each other, even if they are not candidates for merging into one course site. For example, it may be useful to show all sections of Biology 101 Fall 2009 together, or even to indicate a relationship between Biology 101 sections across semesters. The Full Course Hierarchy Module provides a way to do this.
It does so by providing two additional record types, Course Offering and Course Template. These records are in a hierarchical relationship with Course Section, i.e., a Course Offering is the parent of one or more Course Sections, and a Course Template is the parent of one or more Course Offerings. Course Offerings represents groups of one section type during the same academic term e.g., all Psychology 201 sections in the Fall 2009 semester. A Course Template represents groups of Course Offerings across terms e.g., all Psychology 201 sections from Fall 2009, Spring 2009, Fall 2008, etc. The types of service operations required for this module are identical to those required for the Core module.
5 Conformance
Conformance to the Core Profiles is defined in terms of implementation as either a ‘Ref Agent’ of ‘Sync Agent’. Compliance as an ‘Agent’ means that for each of the services the implementation must:
· Be a service consumer for the appropriate operations;
· Be a service provider for the appropriate operations;
· Support the SOAPv1.1 messages for the operations based upon the 1EdTech General Web Services v1.0;
· Support the set of status codes returned in the response messages;
· As a service provider reject the unsupported operations with the status code ‘unsupportedLISoperation’;
· Support the service data model for the operations (either the full data model or a proper subset);
· Support the set of external VDEX vocabularies specific to this service.
When a system claims compliance to the Profiles then any implementation must support the Core Profile. A system may support some or all of the Addition Profiles. Support of Addition Profiles reduces guaranteed interoperability.
6 Where To Go From Here
While the full specification contains a wealth of documentation (as shown in Figure 4), implementers of the Learning Systems: Profiles will find that they only need to look at the majority of this documentation as reference materials, if at all.
Figure 4 The LIS v2.0 specification documentation set.
The first document to read is the Learning Information Services Specification Best Practices and Implementation Guide. This document provides concrete examples and practical advice for developing real-world implementations. Next, review the Overview documents for both the specification and the conformance profile. Together, these three documents will provide most of what implementers will need in order to begin planning their work. From there, they should review the Learning Information Services v2.0 Profiles document together with the Learning Information Services Specification document as they plan to implement specific services. The various information model documents should mainly be considered reference documents are need not be read in detail before beginning implementation.
About This Document
Editor: Michael Feldstein (Cengage) and Colin Smythe (1EdTech)
Co-chairs: Linda Feng (Oracle) and Bill Lee (Desire2learn)
Version: 2.0.1
Version Date: 30 September 2013
Status: Final Release
Revision Information: The original Final Release.
Document Location: http://www.imsglobal.org/lis
List of Contributors
The following individuals contributed to the development of this document:
Kerry Blinco DEEWR (Australia)
Kirk Bunte SungardHE (USA)
Angus Chan Desire2Learn (Canada)
Adam Cooper JISC/JISC-CETIS (UK)
Michael De Ridder Desire2Learn (Canada)
Michael Feldstein Cengage (USA)
Linda Feng Oracle (USA)
John Fontaine Blackboard (USA)
Chris Hatton Pearson (USA)
Karen Kuffner University of Michigan (USA)
Zack Leavitt Pearson (USA)
Bill Lee Desire2Learn (Canada)
Richard Moon SungardHE (USA)
Phil Nicholls Psydev Ltd (UK)
Mike Parkhill Desire2Learn (Canada)
Colin Smythe 1EdTech (UK)
Reinhold Staudinger Blackboard (USA)
Nick Terrible University of Wisconsin (USA)
Ed Vannatter Desire2Learn (Canada)
Jason Zhong SungardHE (USA)
Revision History
|
Version No. |
Release Date |
Comments |
|
LIS Final Release v2.0 |
31 December 2011 |
The first formal release of the Final Release Document. This document is released for adoption by the community at large. |
|
Final Release v2.0.1 |
30 September 2013 |
Corrections |
1EdTech Consortium, Inc. (“1EdTech”) is publishing the information contained in this document (“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 GLC through our website at http://www.imsglobal.org.
Please refer to Document Name: 1EdTech Learning Information Services Learning Systems: Profiles Overview Final Release v2.0.1
Date: 30 September 2013
