IMS Logo IMS Enterprise Best Practice and Implementation Guide

  Version 1.01 - Final Specification

Copyright © 1999 IMS Global Learning Consortium, Inc. All Rights Reserved.

The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name:
IMS Enterprise Best Practice and Implementation Guide v1.01
Revision: December 1999

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: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright 1999 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.

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.



About This Document

Table of Contents

INTRODUCTION
PURPOSE
SCOPE

Personal Profile Data Maintenance
Group Management
Enrollment Management
Final Result Processing

MARKETS
REQUIREMENTS
SECURITY CONSIDERATIONS
RELATED IMS DOCUMENTS
RELATED INITIATIVES
Related IMS Initiatives
Other Specification Initiatives

SPECIFICATION DEVELOPMENT PROCESS
OVERALL DATA MODEL
IMS ENTERPRISE ELEMENTS AND STRUCTURE
1 Properties

2 Person

3 Group

4 Membership

IMPLEMENTATION NOTES
Tracking Group Identifier Across Systems

Assigning Group Membership Role Type

INTERFACE ARCHITECTURES
THE "SNAPSHOT" INTERFACE
EVENT DRIVEN INTERFACE
USAGE SCENARIOS
GENERAL SCENARIOS
Human Resource Management System

Corporate Training Management System

Student Administration System

Library Management System

ENTERPRISE ELEMENT TO LDAP ATTRIBUTE MAPPING
GUIDANCE FOR VERY SPECIFIC SCENARIOS
Cross-Listed Course Sections
Single File from Multiple Systems
CONFORMANCE
ACKNOWLEDGEMENTS
APPENDICES
ADDITIONAL RESOURCES

ADDENDUM


Introduction

Purpose

Corporations, schools, government agencies, and software vendors have a major investment in their systems for Training Administration, Human Resource Management, Student Administration, Financial Management, Library Management and many other functions. They also have existing infrastructure and systems for managing access to electronic resources. To be effective and efficient, Instructional Management systems need to operate as an integrated part of this Enterprise system environment.

The objective of the IMS Enterprise specification documents is to define a standardized set of structures that can be used to exchange data between different systems. These structures provide the basis for standardized data bindings that allow software developers and implementers to create Instructional Management processes that interoperate across systems developed independently by various software developers.

Scope

The scope of information included in this version of the specification is intended to support interoperability between Learning Management systems (LMS) and the following classes of Enterprise Systems:

The scope of the IMS Enterprise specification is focused on defining interoperability between systems residing within the same enterprise or organization. Data exchange may be possible between separate enterprises, but the documents comprising the IMS Enterprise specification are not targeted at solving the issues of data integrity, communication, overall security, and others inherent when investigating cross-enterprise data exchange.

The IMS Enterprise Information Model is designed to support interoperability of the following four business process components, which typically require interaction between Learning Management systems and these types of Enterprise systems:

Personal Profile Data Maintenance

    Typically, data about people is maintained in the Enterprise systems, and is passed to the Learning Management environment. When this personal profile data changes in the Enterprise system, it needs to be updated in the Learning Management system.

Group Management

    Group management processes can include data from class creation and class scheduling, and the ongoing maintenance of that data. A source system creates and maintains group information, which needs to be shared with other systems that are involved with group management functions. The flow of group management information is not necessarily one way; some data may be updated by a target system and passed back to the source system.

Enrollment Management

    Enrollment management encompasses the initial creation of Group membership and various changes to that data over time. Examples of enrollment management include learner enrollment in courses and instructor assignment to courses.

Final Result Processing

    Final result processing refers to the evaluation and recording of final group membership results (final grade, course completion, etc.). This processing can occur in the Learning Management systems or in the Enterprise system.

Markets

The IMS Enterprise system interoperability standards are intended to serve all organizations involved in the development and delivery of education and training using Internet-based technology. These organizations include:

The specifications are intended to meet the need of these organizations in all parts of the world.

The primary constituents for these specifications are organizations involved in the development of management component of Internet-based Instructional Management systems, or in the development of other systems that need to interoperate with Instructional Management systems.

Requirements

No assumptions regarding Data Ownership and Distribution of Functions
The specifications do not define a unified system architecture. The distribution of functions and data ownership between various systems will vary widely between industries, software vendors, and individual organizations. Class enrollment may occur in a Student Administration system at a particular university, in a training management component of a Human Resources system at a specific company, or in the Internet-based Instructional Management system at another company. These are architectural and systems integration decisions that will be made on a site-by-site and system-by-system basis.

Allow any type of Publish / Subscribe and Query / Response Protocol - Synchronous or Asynchronous
Some system architectures will support a synchronous Query / Response interaction where a consumer system makes a request for data and waits for a synchronous response message from a source system before proceeding to the next step of a process. Other systems will generate a query, and an asynchronous response will be received from the source system at some point in the future.

Some system architectures will be better served by a Publish / Subscribe interaction. This interaction happens when the source system publishes a message every time a particular event occurs. Then, the consumer system chooses which messages they subscribe to, and the timing with which they read the messages. This specification supports any of these messaging architectures.

Define Core Messages with Minimal Required Data
The data structures define a minimal set of data that is required to support basic interoperability. This allows a consistent specification to be widely adopted across various industries, countries, and systems. If the core structures were defined too "richly", they would have to specify data elements and vocabularies that are limited to particular industries or countries.

Support Extensibility
The core information structures define only the most basic data needed to support interoperation. However, there will be a need to extend these basic transactions to fully support the requirements of specific industries and countries. Different vendors will form partnerships to support tighter, richer integration and they must be able to develop extensions to the standard transactions. Also, different industries will develop extended message schemas for specific purposes. Therefore, the IMS Enterprise Information Model provides support for this extensibility recognizing that it is a critical requirement for a meaningful standard.

Scalability
The data structure and binding specification can support any scale of implementation. Groups using these specifications must consider the scalability requirements of their solution, and design it to allow processes to perform effectively and in a timely manner for whatever scale of implementation they are intending to support. This may include partitioning the passing of data objects between systems into smaller "chunks" to avoid passing massive XML objects.

Security Considerations

This specification describes a data format standard for interoperability among systems within an enterprise or within an administrative domain of an enterprise. Some data items are often associated with authentication (e.g. UserID) and/or authorization (e.g.Role). Some data items (e.g. Demographics) may have privacy regulations imposed by government or other organizations external to the Enterprise. As a result, an entire data stream based on this specification may be considered sensitive even within the same enterprise or administrative domain. The sensitivity of the entire data stream is the sensitivity level of the most sensitive data element within the stream.

Enterprise and/or domain data administrators should apply the appropriate security measures in the storage and transfer of information represented according to this specification. Appropriate security measures are determined by the privacy requirements of the information, the threats to the confidentiality of the information, and the liability of the Enterprise should confidentiality be compromised. Appropriate security measures may include cryptographic techniques for confidentiality and integrity, and mutual authentication between parties in a data transfer.

Related IMS Documents

Version 1.0 of the IMS Enterprise Interoperability specification is made up of three documents:

  1. "IMS Enterprise Interoperability Best Practices and Implementation Guide - Version 1.0" (The document you are reading). This document provides an overview and describes how the IMS Enterprise Information Model and XML Binding specifications can be applied to specific types of interoperability scenarios.
  2. "IMS Enterprise Information Model - Version 1.0" This document describes the data structures that are used to provide interoperability of Internet-based Instructional Management systems with other systems that are used to support the operations of an organization.
  3. "IMS Enterprise XML Binding - Version 1.0" This document describes how to encode the Enterprise information objects in XML and provides an XML DTD.

Related Initiatives

The IMS Enterprise Interoperability specification is related to several other IMS specifications, both complete and in progress. This specification is intended to be consistent with these other initiatives wherever possible, in order to reduce redundancy and confusion between specifications.

Related IMS Initiatives

IMS Meta-data Specification
The IMS Enterprise specification shares a number of common data object elements with the IMS Meta-data specification. They are consistent where appropriate.

IMS Profile Specification
The IMS Enterprise specification shares a common data model with the upcoming IMS Profile Specification. The IMS Enterprise Interoperability data model should be a subset of the larger Profile data model.

Other Specification Initiatives

Mappings between the IMS Enterprise Information Model and these other initiatives will be provided as appropriate in future versions of the IMS Enterprise Best Practice and Implementation Guide.

ANSI X12 - TS 130
This is the Student Educational Record (transcript) as defined by the Speede/Express group. It is a well-developed standard that is intended to support the Electronic Data Interchange (EDI) sharing of full student transcripts between North American institutions.

Gestalt Initiative
Gestalt, building on the work done in the PAPI specification is defining a more extensive Personal Profile model that supports the exchange of data within and across institutions.

IEEE 1484.8 Enterprise Interfaces SG
There is an IEEE 1484 subcommittee tasked with the development of Enterprise Interoperability standards for learning systems. IMS will submit this specification to that group for consideration as the basis for their specification.

IEEE 1484.2 Learning Model WG
There is an IEEE 1484 subcommittee tasked with the development of a Learning Profile standard for learning systems. The PAPI model is being used as the basis for the development of this standard, and IMS will continue to track this initiative looking for opportunities to synchronize standards whenever possible.

Schools Interoperability Framework (K-12)
This initiative is developing standards for the interoperability of administrative systems for North American K-12 schools and districts. The market focus and scope of systems considered is different than the IMS Enterprise Interoperability specification, but IMS will continue to track this initiative looking for opportunities to synchronize standards whenever possible.

California Schools Information System Project
This initiative is developing standards for the interchange of data between California K-12 schools as well as between these schools and the state department of education. The group is currently working on a data exchange and state reporting. The project is also considering standards for the exchange of data between California K-12 and higher education institutions. (www.csis.k12.ca.us)

Directory Services Markup Language (DSML)
DMSL is comprised of a broad consortium of vendors working to develop an XML binding for directory services products. Directory services product track data about people and groups, so they deal with some of the same data addressed by the IMS Enterprise specification. (www.dsml.org)

Specification Development Process

Specifications are the core deliverable of IMS. The publicly released IMS Meta-data specification is the first in an evolving series of specifications to define the Internet architecture for learning. The IMS Enterprise specification is the second publicly released specification from IMS.

Within IMS, the specification development process begins with a scope document that bounds the interoperability functionality supported by the specification. The scope document is recommended by the IMS Technical Board, which includes representatives from developers and users from around the world.

A draft specification is developed within the IMS developer and user community, which currently includes more than 200 organizations from around the world. In a number of cases, one of these organizations represents many other organizations, such as the Australian Government's DETYA organization, which provides access to the IMS community for all institutions of learning in Australia.

Work teams with full-time IMS technical staff and volunteers from the IMS developer and user community meet in face-to-face and virtual meetings to develop draft specifications, which are formulated from white papers, proposals, and other document fragments.

The term "Base document" is used for draft specifications that have reached a relatively high level of stability based on input from the team and the Technical Board. Base documents represent the stage in the specification process of final development and refinement. It is base documents that are presented in their final form to the IMS Technical Board for vote. If approved, the document becomes a final specification and is listed as such on the IMS public web site. If not approved, the team works through whatever adjustments and recommendations the Technical Board provides, and then resubmits the document.

After a final specification is released, the team develops the next scope document for subsequent work. New requirements and features dropped from the previous specification constitute the scope of the next effort.

Overall Data Model

The following diagram provides a conceptual overview of the IMS Enterprise Interoperability data model.

A Conceptual Overview of the IMS Enterprise data model.

DATA OBJECTS:

This model is supported through the use of three data objects, described briefly below:

    Person - This data object contains elements describing an individual of interest to the Learning Management environment.

    Group - This object contains elements describing a group of interest to the Learning Management environment. There are many types of groups that may be shared between systems. The most common is a Course Instance, but they may also include Training Programs, Academic Programs, Course sub-groups, clubs, etc. A group can also have any number of relationships with other groups.

    Group Membership - This data object contains elements describing the membership of a person or group within a group. Group members may be instructors, learners, content developers, members, managers, mentors, or administrators.

A NOTE ON REFERENTIAL INTEGRITY:
In the information model shown above, there is an implied referential integrity between data objects. For example, defining a Group Membership instance first requires the existence of the Group, and of the Person or Group that is a member of the Group.

IMS Enterprise Elements and Structure

1 Properties

1.1	DataSource				
1.2 Target
1.3 Type
1.4 Datetime
1.5 Language
1.6 Extension
2 Person
2.1           SourcedID
2.1.1 Source
2.1.2 ID
2.2 RecStatus
2.3 UserID
2.4 Name
2.4.1 FN
2.4.2 Sort
2.4.3 Nickname
2.4.4 N
2.4.4.1 Family
2.4.4.2 Given
2.4.4.3 Other
2.4.4.4 Prefix
2.4.4.5 Suffix
2.5 Demographics
2.5.1 Gender
2.5.2 BDay
2.6 Email
2.7 Tel
2.7.1 TelType
2.7.2 TelNum
2.8 Adr
2.8.1 POBox
2.8.2 ExtAdd
2.8.3 Street
2.8.4 Locality
2.8.5 Region
2.8.6 PCode
2.8.7 Country
2.9 Photo
2.9.1 ExtRef
2.9.2 ImgTyp
2.10 DataSource
2.11 Extension
3 Group
3.1                 SourcedID
3.1.1 Source
3.1.2 ID
3.2 RecStatus
3.3 GroupType
3.3.1 Scheme
3.3.2 TypeValue
3.3.2.1 Level
3.3.2.2 Value
3.4 Description
3.4.1 Short
3.4.2 Long
3.4.3 Full
3.5 Org
3.5.1 OrgName
3.5.2 OrgUnit
3.5.3 Type
3.5.4 ID
3.6 TimeFrame
3.6.1 Begin
3.6.1.1 Date
3.6.1.2 Restrict
3.6.2 End
3.6.2.1 Date
3.6.2.2 Restrict
3.6.3 AdminPeriod
3.7 EnrollControl
3.7.1 EnrollAccept
3.7.2 EnrollAllowed
3.8 EMail
3.9 URL
3.10 Relationship
3.10.1 SourcedID
3.10.1.1 Source
3.10.1.2 ID
3.10.2 Label
3.10.3 Relation
3.11 DataSource
3.12 Extension
4 Membership
4.1                 SourcedID
4.1.1 Source
4.1.2 ID
4.2 Member
4.2.1 SourcedID
4.2.1.1 Source
4.2.1.2 ID
4.2.2 IDType
4.2.3 Role
4.2.3.1 RoleType
4.2.3.2 SubRole
4.2.3.3 Status
4.2.3.4 RecStatus
4.2.3.5 UserID
4.2.3.6 Comments
4.2.3.7 Date
4.2.3.8 Timeframe
4.2.3.8.1 Begin
4.2.3.8.1.1 Date
4.2.3.8.1.2 Restrict
4.2.3.8.2 End
4.2.3.8.2.1 Date
4.2.3.8.2.2 Restrict
4.2.3.9 Final result
4.2.3.9.1 Mode
4.2.3.9.2 Values
4.2.3.9.2.1 ValueType
4.2.3.9.2.2 List
4.2.3.9.2.3 Min
4.2.3.9.2.4 Max
4.2.3.9.3 Result
4.2.3.9.4 Comments
4.2.3.10 Email
4.2.3.11 DataSource
4.2.3.12 Extension

Implementation Notes

Tracking Group Identifier Across Systems

Target systems need to be capable of storing the source system's "Group Identifier".

It is possible to have a viable interface without automatically exchanging Group data. This means that one or the other systems involved in an interface must store the other system's Group Identifier in order to support the passing of Group membership data. In this case, the responsibility for storing the Group ID falls on the system that will act as the source for Person and Group Membership data. The implication is that if Group data is not automatically being passed between systems, then it is being created in both systems independently. In this situation the Group ID of one system needs to be entered into the relevant record in the other system, otherwise an interface cannot occur between the two systems. This process may be manual or automated. Discussions to date have indicated that this model may be followed by many organizations.

Assigning Group Membership Role Type

RoleType is a mandatory element in the Group Membership object (element 4.2.2.1) that has a defined set of domain values. This means that only those values defined in the domain can be used for this element. Recognizing that no defined list of roles can ever be absolutely complete; the optional element SubRole can be used to further qualify a person's role in a group.

It is essential to have a defined list of values for the mandatory RoleType element so source systems can generate standard Group Membership data objects that target systems can process without having to first negotiate the meaning of RoleTypes with the source system. To help developers understand what meaning is embedded in each of the RoleType values, the following table shows the Learning Management System functions that each RoleType will typically have access to. This is not intended to be a precise and exclusive list of all functions that these roles will have access to in all Learning Management Systems. Rather, it is provided as an interpretive guide intended to communicate the meaning the developers of the specification had in mind for each role. In addition, access to these functions will be less for some subroles. For example, a supervisor may be a subrole for a manager, and a supervisor will likely not have access to results for the people they supervise.

This table shows various roles.

In any particular implementation or in any specific vendor's product, the Instructor role and the Administrator role will frequently have several subroles.

Interface Architectures

The IMS Enterprise Information Model and XML Binding specification are intended to support either the "Snapshot" or Event Driven interface types discussed below:

The "Snapshot" Interface

The IMS Enterprise team's consensus is that the most robust and easily implementable interface would involve the passing of a complete "snapshot" of the Person, Group, and Group Membership data. The target system would examine this snapshot to determine what changes had occurred. This very basic type of interface allows a receiving system to pick up an interface at any time and synchronize its data with the source system-- regardless of how many interfaces had been passed in the interim. A purely event driven "transactional" interface, on the other hand, cannot tolerate any loss or skipping of interface records.

This basic interface also allows the target system to implement many different strategies for dealing with the interface data. Taking a "snapshot" means that the full set of relevant data from the source system can be moved to the target system environment on any timing needed to support the business processes.

This interface architecture has the advantage of being very tolerant of lost messages or missed data objects because the next transmittal will always get the target system back in synchronization with the source system. However, the major drawback is that the target system can never be sure that the data has not changed in the source system since the last snapshot was received. Also, this interface architecture does not effectively support two-way interfaces. In a two-way interface, data object maintenance occurs in both systems, and the data objects are passed in both directions.

Event Driven Interface

In an event driven interface, the source system publishes data object messages when events occur. This changes the relevant data, and the target system receives and processes the event transactions.

The existence of an event driven interface does not eliminate the usefulness of the "snapshot" interface. Because an event driven interface is not tolerant of missed transactions, the "snapshot" interface can be used at regular intervals to "re-synchronize" the data in the target system with that in the source system. This increases the fault tolerance of the overall interface architecture.

Usage Scenarios

This section describes some scenarios where the IMS Enterprise Information Model and the IMS Enterprise XML Binding Specification can be applied.

This is not intended to be a complete list of scenarios, nor is there any implication that these scenarios describe the best method for designing an interface between systems. It is expected that this section will expand extensively over time as organizations gain experience implementing the specification in various scenarios.

General Scenarios

The following list describes some types of systems for which the IMS Enterprise specification may support Learning Management interoperability. It includes a list of some interfaces that the current specification can support.

Human Resource Management System

Human Resource Management Systems (HRMS) manage personnel records, payroll, benefits, competency management, and other functions for an enterprise. Interoperability that can be supported by this specification include:

From HRMS to LMS:

  1. Person data maintained in the HRMS and passed to the LMS.
  2. HR departments passed as groups, and employees of those departments passed as members.
  3. Special groups of employees (new hires for example) passed to the LMS as training groups.

From LMS to HRMS:

  1. After the completion of training courses, course information return to the HRMS as groups, and completion of training courses, - could come back as membership in those groups, with result information included.

Corporate Training Management System

Corporate Training Administration systems keep track of employee training plans, schedule training courses (including instructors and resources), enroll people in training, record training completed, and update employee competencies in an HRMS. They are also used to manage training delivered to customers. Interoperability that can be supported by this specification include:

From Training to LMS:

  1. Person data might be passed to the LMS from the training system .
  2. Training groups (courses) and memberships could be passed from training to the LMS.

From LMS to Training:

  1. After the completion of training courses, membership objects could be sent to the Training Administration system from the LMS with result (completion) information included.

Student Administration System

Student Administration systems (SA) keep track of student education plans, schedule courses (including instructors and resources), enroll people in courses, record course results, and update student academic progress. Interoperability that can be supported by this specification include:

From SA to LMS:

  1. Person data for people enrolled in groups that are managed by the LMS.
  2. Group data could be passed from SA to the LMS to create the groups.
  3. Group membership (course enrollment) data may be passed from SA to the LMS.
  4. Final grade information may be passed to the LMS from the SA in an updated Membership object if final grading occurs in the SA, and the LMS needs the final grade for its records.

From LMS to SA:

  1. Final grades could be returned to SA from the LMS by passing back Membership records with the Result data provided. This data could then be entered into a formal grade roster process on the SA side.

Library Management System

Library Management systems can be thought of as a particular class of Learning Management system, in that they provide a set of services for managing the interaction of learners with learning objects. Therefore, it is appropriate to use this specification to support interfaces from other enterprise systems to Library Management systems in much the same way that these interfaces are supported with Learning Management Systems.

From SA or HRMS to Library:

  1. People data.
  2. Groups (course sections for access to specific material, HR departments for access to services, alumni for access to limited services, etc.)
  3. Group membership.

Enterprise Element to LDAP Attribute Mapping

Most enterprise systems utilize a directory to store organizational and person information. Many directories use the Lightweight Directory Access Protocol (LDAP) to store this data and make it accessible to other Enterprise applications. It is likely that Learning Management Systems will use some of the data in an LDAP directory to populate equivalent fields in the IMS Enterprise XML binding.

The table below represents a preliminary mapping between LDAP base schema items and IMS Enterprise elements. This is provided only as an example. The reader who wishes to incorporate LDAP data into learning management applications is encouraged to consult authoritative sources regarding LDAP.

This table represents a preliminary mapping between LDAP base schema items and IMS Enterprise elements.

Guidance for Very Specific Scenarios

Cross-Listed Course Sections

Cross-Listed course sections are a fairly common scenario in higher education. A Cross-Listed course section refers to a situation where the same course is offered under more than one name. This is typically done because different groups of students will enroll in different sections based on the program they are studying. For example, Statistics 101 section 1 and Psychology 101 section 1 are really the same course section, offered by the same instructor, meeting at the same time and place (physical or virtual), using the same course materials. The only difference is that Math students enroll in Statistics 101, and Psychology students enroll in Psychology 101. A problem arises in this situation when the Enterprise system treats these sections as separate groups. In the Learning Management System, they need to be treated as a single group, or at least the LMS needs to know they are related.

One approach is to resolve this in the source system before passing Groups and Memberships over to the target system. In other words, a single group (perhaps called "Introductory Statistics", without the Math or Psychology designator) would be created in the Learning Management System and membership from both groups in the Enterprise system would be passed to this single group in the LMS.

Another approach is to pass two separate groups to the target system, but relate them to each other through the use of the Relationship element. In this case, the two groups could be tagged as follows in the Relationship element:

    Sourced ID - The ID of the cross-listed course section in the source system.
    Label - Would contain something like "Cross Listed Section"
    Relation - Would contain "3" (also known as)

In general, the best practice would be to resolve the issue in the source system, before passing the group and membership data to the target system, but there may be cases where the second approach is required.

Single File from Multiple Systems

During Integration engagements conducted by Blackboard in the Summer and Fall of 1999, it was determined that some institutions might store certain objects in multiple systems. The current version of the IMS Enterprise Information Model (1.0) handles this situation if the file are sent separately from each system and the system is identified by the DataSource attribute in Properties. However, Blackboard found that some institutions preferred to produce one file and send that to Blackboard CourseInfo Enterprise. In this case a DataSource attribute at the file level is not sufficient.

It is recommended that the IMS Enterprise Information Model change to include a DataSource element for People, Groups and Group Membership. The element would be at the top level for People and Groups, but off Role for Group Membership.

This DataSource element identifies the system from which the record (object) came. While the Source off of SourcedID identifies the system that guarantees the uniqueness of the record.

For example, if we look at a People flat file containing two records:

Tom, Scott, CSUM, Banner, 403-34-1234
Fred, Simpson, CSUM, People Soft, 502-12-4312

CSUM is the Source while Banner and People Soft are the DataSource. If you assume that one application (for example the SnapShot generator) generated the merge of the two systems data, the DataSource in Properties would be the "SnapShot Generator."

An example flow of a Blackboard integrated system:

Example of an integrated system.

A real life example of where this occurs is when an institution uses an SIS system to manage academic activities, but has another system to manage organizations.

By adding the additional DataSource as an element, integration vendors and institutions can track down where errors occurred and use DataSource, DataSource (from Properties) and Source to determine from which the data came while doing integration testing.

Conformance

Conformance to the IMS Enterprise Information Model is defined for instances [data, files, documents] and for applications. Additional requirements may be included in binding specifications for this information model.

Instance Conformance

An IMS Enterprise Information Model instance conforms if it satisfies the following seven requirements:

  1. The instance must contain all mandatory elements identified in the packaging and control data object. The elements must meet the multiplicity, domain, and type requirements.
  2. If the instance contains person data, the instance must contain all mandatory elements identified in the person data object. The elements must meet the multiplicity, domain, and type requirements.
  3. If the instance contains group data, the instance must contain all mandatory elements identified in the group data object. The elements must meet the multiplicity, domain, and type requirements.
  4. If the instance contains group membership data, the instance must contain all mandatory elements identified in the group membership data object. The elements must meet the multiplicity, domain, and type requirements.
  5. If an optional element is contained in the instance, then the instance must contain all mandatory elements that are a part of that optional element in the packaging and control data object, person data object, group data object, or group membership object.
  6. The instance may contain conditional elements in the packaging and control data object, person data object, group data object, or group membership object.
  7. The instance may contain extension elements, if the extensions meet the requirements of this specification.

Source Application Conformance

An application that acts as a source for one or more data objects conforms to the IMS Enterprise Information Model if it satisfies the following requirement:

  1. A conforming source application must be able to write an instance of the mandatory elements of the packaging and control data object, and one or more of the person data object, group data object, or group membership object.
  2. The ability to write optional elements is desirable, but is not required.

Target Application Conformance

An application that acts as a target for one or more data objects conforms to the IMS Enterprise Information Model if it satisfies the following requirement:

  1. A conforming target application must be able to read, process, and store an instance of the mandatory elements of the packaging and control data object, and one or more of the person data object, group data object, or group membership object.
  2. Optional element reading, processing, storage, and persistence is desirable, but is not required.
  3. Extension element reading, processing, storage, and persistence is not required.

Acknowledgements

Many people have contributed to the development of the IMS Enterprise specification. IMS wishes to thank Fred Beshears, Bill Young, Marty Gray, and John Barkley for their efforts in writing portions of this document.

Appendices

Additional resources

IMS Enterprise Documents
The IMS Enterprise XML Binding Specification can be found at: http://www.imsproject.org/enterprise/enbind03.pdf

The IMS Enterprise Information Model document can be found at: http://www.imsproject.org/enterprise/eninfo03.pdf

vCard Information

A variety of vCard related links can be found at: http://www.imc.org/pdi/

XML Resources
The XML specification and additional links can be found at: http://www.w3.org/XML/

Articles, software and many things related to XML can be found at:
http://www.xml.com/

Addendum

Changes to the v1.0 of the IMS Enterprise Best Practices and Implementation Guide are as follows:

Type of Problem Addition
Date December 14, 1999
Problem Description DataSource is needed in the Person, Group and Membership objects, not just in the Properties object. This allows a single file to contain objects from more than one source system, and allows the target system to track the source of the objects for future reference back.This change is being made in the Information Model, and must also be made in the Best Practice and Implementation Guide.
References in Document Best Practice and Implementation Guide - IMS Enterprise Elements and Structure section
Solution Proposed by the Submitter 1) Make the following additions and changes.

Person Object:

  • Renumber the "Extension" element as 2.11
  • Insert "2.10 DataSource" element before Extension, indented at the same level as Extension

Group Object:

  • Renumber the "Extension" element as 3.12
  • Insert "3.11 DataSource" element before Extension, indented at the same level as Extension Group

Membership Object:

  • Renumber the "Extension" element as 4.2.3.12
  • Insert "4.2.3.11 DataSource" element before Extension, indented at the same level as Extension

Type of Problem Addition
Date December 14, 1999
Problem Description DataSource is needed in the Person, Group and Membership objects, not just in the Properties object. This allows a single file to contain objects from more than one source system, and allows the target system to track the source of the objects for future reference back.
References in Document Best Practice and Implementation Guide - Guidance for Very Specific Scenarios
Solution Proposed by the Submitter 2) Add a new subsection to this section that describes a scenario on how the DataSource and Source fields should be used when passing objects from multiple systems. This scenario is provided by Blackboard based on real world IMS implementation experience. See text below for contents of new section.
GUIDANCE FOR VERY SPECIFIC SCENARIOS

Single File from Multiple Systems
During Integration engagements conducted by Blackboard in the Summer and Fall of 1999, it was determined that some institutions might store certain objects in multiple systems. The current version of the IMS Enterprise Information Model (1.0) handles this situation if the file are sent separately from each system and the system is identified by the DataSource attribute in Properties. However, Blackboard found that some institutions preferred to produce one file and send that to Blackboard CourseInfo Enterprise. In this case a DataSource attribute at the file level is not sufficient.

It is recommended that the IMS Enterprise Information Model change to include a DataSource element for People, Groups and Group Membership. The element would be at the top level for People and Groups, but off Role for Group Membership.

This DataSource element identifies the system from which the record (object) came. While the Source off of SourcedID identifies the system that guarantees the uniqueness of the record.

For example, if we look at a People flat file containing two records:

Tom, Scott, CSUM, Banner, 403-34-1234
Fred, Simpson, CSUM, People Soft, 502-12-4312

CSUM is the Source while Banner and People Soft are the DataSource. If you assume that one application (for example the SnapShot generator) generated the merge of the two systems data, the DataSource in Properties would be the "SnapShot Generator."

An example flow of a Blackboard integrated system:
Integrated System

A real life example of where this occurs is when an institution uses an SIS system to manage academic activities, but has another system to manage organizations.

By adding the additional DataSource as an element, integration vendors and institutions can track down where errors occurred and use DataSource, DataSource (from Properties) and Source to determine from which the data came while doing integration testing.


About this Document

Title IMS Enterprise Best Practice and Implementation Guide
Authors Geoff Collier, Wayne Veres, Thor Anderson
Version 1.01
Version Date December 21, 1999
Status Final
Summary This document provides additional information regarding IMS Enterprise Specification Best Practices and Implementation guidelines. It is meant to complement the IMS Enterprise XML Binding and IMS Enterprise Information Model documents.
Revision Information Last revised December 21, 1999
Document Location http://www.imsproject.org/enterprise/enbest03.pdf

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

IMS 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 would appreciate receiving your comments and suggestions.

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

Please refer to Document Name:
IMS Enterprise Best Practice v1.01 Revision: December 1999