The Service-Oriented Campus

photo credit: betsyweber

Part 3 of my series on the new IMS Global Learning Consortium’s Learning Information Services specification:

Sometimes standards are needed when there are lots of people making arbitrary decisions.  But how does one judge when they are needed?  Take for example, whether people should eat their bananas stem side up or stem side down.  Different users can argue which way is better for as long as they want – either way, the banana gets eaten.  No standard really needed for that.  (By the way, it turns out that monkeys prefer to eat their bananas stem side down – that way they can hold onto the stem as a handle of sorts…see here for directions )   On the other hand, driving on the same side of the road – now that most would agree is a place where standards are important.   It doesn’t really matter which side people choose, but it IS important that we all make the same decision.  The same could be said of some of the decisions which went into the LIS specification.  We needed everyone to agree on the same convention for things like naming, data model representation and service methods.  If someone had an existing model which provided a good example and could be considered generic, we tried to include it whenever possible.  Similarly, if we had specified service methods or expanded part of the data model which vendors don’t currently have a need to implement, we intentionally removed it from the LIS profile definitions.

So what is the minimum subset of LIS needed for interoperability?  The consensus of the working group was to cover the core LIS use case, which is allowing an authoritative system to publish data about courses, people and enrollments.   Remember that the target or consumer of this type of data could be a Learning Management System, but it could just as easily be a wiki, blog or collaboration environment such as Google Apps.    Similarly, the source system typically would be a Student Information System, but it could also be a combination of systems such as a central Identity Mgmt system plus a master instance of a Learning Management system.   The goal is to establish a low barrier to adoption, while also formulating ways for vendors to achieve higher forms of interoperability at the same time.  This is accomplished through the Core and Addition Profiles for LIS:

Continue reading →

photo credit: Some rights reserved by dullhunk

It could be that for some, improving student life might mean better methods to obtain pizza – but for others, enabling seamless integration between separate academic systems might be just what many campuses today need.

The IMS Learning Information Services specification is poised to fundamentally improve the cost of integrating systems housing student and academic information for thousands, if not millions of students around the world.

As the co-chair of the LIS project group, I want to share some of my perspectives about the specification and some of the rationale that went into key choices.   Before we go further, however, here are several fundamental principles and concepts behind the LIS specification:

LIS is designed to exist within an ecosystem of loosely coupled systems. Schools today typically run their Student Information System or Learning Management System separately, housed within separate servers and administered by different groups.  Institutions may also have other systems on campus to support different functions supporting their community, i.e., iTunesU, GoogleApps or MyMathLab.  Each individual system may be administered with different schedules for uptime and service level agreements.  This means that core information typically needs to be accessible within a system independent of the availability of another system.

LIS presumes specific systems are designated as the authoritative source for key information. In most cases, for example, the Student Information System would serve as the “source of truth” for information about courses, persons and enrollment.  On the other hand, a downstream Learning Management System may serve as the Outcome source for Final Grades.  This does not preclude multiple sources of student data feeding into one or more learning system – however it is presumed that a given identifier (whether it be for a Person, Course, Enrollment or Outcome) will be associated with one and only one data “source”.

When the LIS project group was chartered back in 2007, the landscape of Enterprise Student System integration was scattered, with widely varying degrees of implementations of the former IMS Enterprise specification.   This included pockets of IMS Enterprise Services implementations throughout the UK, where adoption of the Learner Information Profile (LIP) specification was also slightly more established.   The group felt there was no reason to completely dismantle the existing Person, Group and Membership entities, which had previously been defined by various versions of IMS Enterprise.   Having said that, we knew we need to solve several key problems with the original specification:

• support for the exchange of unambiguously defined hierarchical course structure
• support for loose associations of course sections to allow student systems to maintain grouping constructs separately from downstream learning applications
• support reporting of outcomes information, both assessment item level as well as final grades
• support system bulk exchange/initialization

For services such as Person, we realized there were infinite possibilities to establish a definitive set of attributes, let alone to determine which ones would be considered required or optional.  Therefore, we employed a technique using vocabulary driven “type-value” pairs to define a common framework for Person attributes.  For each attribute “type” (name, address, etc.), a core vocabulary is defined and used to evaluate conformance, however it is recognized that local implementations are free to extend it with region-specific elements, for example.  (This also means that backward compatibility with the previous IMS Enterprise data model is not easily achieved, due to the extensive structural changes made to entities such as Person.)

Based on the primary use cases we set out to solve for Learning Information Services, the following are the resulting 6 services which were defined. As I mentioned, they consist of 3 original (though modified) services, and 3 new services:

• PERSON – refactored from the original IMS Enterprise model; used to represent students, instructors, administrators and other people associated with downstream learning applications.
• GROUP – this was largely retained from the original IMS Enterprise specification.  The GROUP structure is very flexible and can be used to model many different things, from institutions, organizations, academic departments, terms or academic sessions, and non-course groups such as project groups, committees, clubs or other organizations.
• MEMBERSHIP – this was also largely retained from the IMS Enterprise model; used to associate PERSONs with COURSEs or GROUPS.  In addition, a set of roles and subroles can be assigned for a given MEMBERSHIP.
• COURSE – this new structure allows a 3 level hierarchy to be represented for Courses.  At the highest level is the Course Template, which is designed to model a Course typically included in an Institutional Course Catalog.  The Course Template does not have an association with a Term or Academic Session, rather it contains attributes about a Course that hold true for all terms.  The next level down is the Course Offering.  This is where the Academic Session relationship can be established.  It is important to note that the Academic Session object is not itself an LIS entity – rather it is an LIS Best Practice to populate the Academic Session element with a Group SourcedId (where the Group entity is used to house the Academic Session details for that particular term).
• OUTCOME – the new Outcomes service can represent individual assessment items as well as interim or final results.  Specific flags are used within the Outcomes data model to indicate the “type” of Outcome which is represented.  The Outcome model is actually made up of 3 separate entities: Line Item, Result and Result Value.  The Line Item represents the definition of the Assessment – typically, this can be thought of as a column in a Gradebook.  Results for a given LineItem are the actual scores assigned to the Person (Student).  Finally, the Result Value represents the grading scheme used for the Line Item or Result, and can be associated with either or both entities.
• BULK DATA EXCHANGE – this new service is designed to support the bulk exchange of data between 2 or more systems.

Each of these services operates on the entity as described by the information model.   More detail about the definition of the individual LIS service operations will be discussed in upcoming posts.