IMS Logo IMS Enterprise Information Model
Version 1.1 Final Specification
Copyright © 2002 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Enterprise Information Model
Date: 01 July 2002

 

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 © 2002 IMS Global Learning Consortium. All Rights Reserved.

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

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.


 

Table of Contents


1. Introduction
     1.1 Enterprise Specification Overview
     1.2 Scope & Context
     1.3 Structure of this Document
     1.4 Nomenclature
     1.5 References

2. Specification Use Cases
     2.1 Use Cases
           2.1.1 Personal Profile Data Maintenance
           2.1.2 Group Management
           2.1.3 Enrollment Management
           2.1.4 Final Result Processing
     2.2 Basic Architecture

3. Basic Information Model
     3.1 Core Data Objects
     3.2 Simple Messaging Model

4. Conceptual Description of the Data Objects
     4.1 Underlying Structure of the Enterprise Package
     4.2 Extensions and Extensibility
     4.3 Enterprise Package Tabular Description
           4.3.1 Enterprise Data Objects
           4.3.2 'person' Data Objects
           4.3.3 'group' Data Objects
           4.3.4 'membership' Data Objects
           4.3.5 Common Data Objects
           4.3.6 'extension' Definitions
           4.3.7 Data Types

5. Conformance
     5.1 Valid Data Issues
     5.2 Conformance Summary
     5.3 Interoperability Statement

Appendix A - Class Descriptions
     A1 - Data Types
     A2 - Properties Class
     A3 - Person Class
     A5 - Membership Class

Appendix B - Summary of Changes in this Document

About This Document
     List of Contributors

Revision History

Index


1. Introduction

1.1 Enterprise Specification Overview

The original IMS Enterprise V1.0 Specification was released in September 1999 with the errata V1.01 release following in December 1999 [Ent, 99a], [Ent, 99b], [Ent, 99c]. In August 2001 there was an IMS Enterprise Specification Validation meeting hosted by WebCT and held in Vancouver, Canada. At this meeting a review was held of the many successfully installed interoperable Enterprise systems based upon the IMS Enterprise Specification. The result of this meeting was the development and acceptance of the IMS Enterprise V1.1/V2.0 scoping document [Ent, 01].

The V1.1 IMS Enterprise Specification is fully backwards compatible with the V1.01 Specification1. The core amendments for this version are:

  • Support for a number of the proprietary extensions used to extend interoperability for the v1.01 release. These extensions cover the <person>, <group> and <membership> data objects;
  • Support for multiple <sourcedid> and <userid> structures. Password support has been added to the <userid> structure;
  • Provision of enumerated non-numeric vocabularies. V1.0 uses numeric-based vocabularies. Wherever possible the vocabularies are to be extended to reflect common usage;
  • 'Internationalization' of the core data objects including:
    • Name structure to support non-English conventions
    • Telephony and electronic contact numbers to be extended.

1.2 Scope & Context

This document is the IMS Enterprise Information Model V1.1 Final Specification document. As such it will be used as the basis for the development of the following documents:

  • IMS Enterprise XML Binding v1.1 [Ent, 02a];
  • IMS Enterprise Best Practice & Implementation Guide v1.2 [Ent, 02b].

This requirement has been derived from the agreed IMS Enterprise V1.1/2.0 Scoping document [Ent, 01].

1.3 Structure of this Document

The structure of this document is:

2. Specification Use-cases The definition and scoping of the Enterprise systems and sub-systems that are to be supported by this specification;
3. Basic Information Model The underlying Enterprise information model;
4. Conceptual Description of the Data Objects The detailed description of the Enterprise data objects in terms of their elements, sub-elements and attributes;
5. Conformance The definition of the conformance statement to be used by vendors.
Appendix A - Class Descriptions The class descriptions of the <person>, group> and <membership> core data structures. These are supplied to act as a bridge to the UML based approach to be adopted in V2.0;
Appendix B - Summary of Changes in this Document The details of all of the changes made for the production of this version of the specification document.

1.4 Nomenclature

API Application Programming Interface
CBT Computer Based Training
DTD Document Type Definition
LMS Learning Management System
UML Unified Modelling Language
VLE Virtual Learning Environment
W3C World Wide Web Consortium
XML Extensible Mark-up Language
XSD XML Schema

1.5 References

[Ent, 01] IMS Enterprise V1.1/V2.0 Scoping Document, C.Smythe, G.Collier and C.Etesse, IMS, November 2001.
[Ent, 02a] IMS Enterprise XML Binding V1.1 Final Specification, C.Smythe, G.Collier and C.Etesse, IMS Specification, July 2002.
[Ent, 02b] IMS Enterprise Best Practice & Implementation Guide V1.1 Final Specification, C.Smythe, G.Collier and C.Etesse, IMS Specification, July 2002.
[Ent, 99a] IMS Enterprise Information Model V1.01 Final Specification, G.Collier and W.Veres, IMS Specification, December 1999.
[Ent, 99b] IMS Enterprise XML Binding V1.01 Final Specification, G.Collier and W.Veres, IMS Specification, December 1999.
[Ent, 99c] IMS Enterprise Best Practice & Implementation Guide V1.01 Final Specification, G.Collier and W.Veres, IMS Specification, December 1999.
[IMS, 01a] IMS Persistent Location-independent Resource Identifier Implementation Handbook, V1.0, M.McKell, IMS Specification, May, 2001.

2. Specification Use Cases

2.1 Use Cases

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:

  • Human Resource Systems track skills and competencies and define eligibility for training programs;
  • Student Administration Systems support the functions of course catalog management, class scheduling, academic program registration, class enrollment, attendance tracking, grade book functions, grading, and many other education functions;
  • Training Administration Systems support course administration, course enrollment, and course completion functions for work force training;
  • Library Management Systems track library patrons, manage collections of physical and electronic learning objects, and manage and track access to these materials.

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.

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

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

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

2.1.4 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 LMSs or in the Enterprise system.

2.2 Basic Architecture

The basic architectural model for the Enterprise V1.1 Specification is shown in Figure 2.1.

The basic Enterprise system architectural model

 

Figure 2.1 The basic Enterprise system architectural model.

In this architecture the scope of the IMS Enterprise Specification is shown as the dotted line. The scope of the interoperability is the data model of the objects being exchanged and not the associated behavioral model or the required communications infrastructure.

3. Basic Information Model

3.1 Core Data Objects

A schematic representation of the core data objects exchanged using the IMS Enterprise Specification is given in Figure 3.1.

The principal Enterprise data objects

 

Figure 3.1 The principal Enterprise data objects.

The core objects are:

  • Person - the individuals who are undertaking some form of study and/or group related activity e.g., they are members of a particular course. The personal structure only contains information that is used to identify the individual and that is needed in learning systems. It is not designed to be a data repository for all of the personal information about an individual;
  • Group - a collection of objects related to learning activities or individuals. The group is a generic container used to define any set of related activities e.g., a tutor group, a class, a curriculum, etc. There is no restriction on how the Group and sub-group structures can be used with respect to containing other groups, persons, etc.;
  • Group Membership - the membership structure is used to define the members of a Group. A member can be a Person or another Group. A Group or Person can be a member of any number of groups. The Group and the member are identified using their sourcedids.

An Enterprise XML instance is designed to contain any number of Person, Group and Membership structures but the order in which these can occur are limited to all of the Person objects, followed by all of the Group objects followed by all of the Membership objects.

3.2 Simple Messaging Model

The IMS Enterprise Specification contains a very simple messaging model that is assumed to underlie the exchange of the data between the communicating Enterprise systems. The basic data exchange mechanism is shown in Figure 3.2 in which the 'source' and 'target' Enterprise systems exchange an IMS Enterprise XML instance file. The XML instance consists of a message/bundle header (called <properties>) and the message/bundle data body (this contains the appropriate mixture of <person>, <group> and <membership> structures).

It is important to remember that the structure of the XML instance and the actual usage of XML has no bearing on how the same information is contained within the 'source' and 'target' Enterprise systems. It is simply an exchange interoperability representation of the data (the information that crosses the dotted line in Figure 3.2).

The simple data exchange mechanism

 

Figure 3.2 The simple data exchange mechanism.

An underlying assumption in a message-based system is that the sequence of messages will, in general, refer to the same objects at different moments in time e.g., the 'creation' of a Person, the 'updating' of a person and eventually the 'deletion' of the Person record. This means that the objects must have a unique identifier and that this address/label is unique between the communicating systems (an object may have more that one identifier even between the same two systems). The IMS Enterprise Specification calls these identifiers the 'sourcedid' of the object and it consists of a 'source' (globally unique across all the Enterprise systems) and an 'id' (unique within the source Enterprise system).

The simple object addressing scheme

 

Figure 3.3 The simple object addressing scheme.

The usage of the 'sourcedid' for labelling the objects being exchanged gives rise to the scenario shown in Figure 3.3. The consequence of this approach is that any object will have multiple identifiers depending on which part of the system is being considered i.e.

  • The 'sourcedid' is the exchange identifier and will be unique to a particular source system;
  • The local identifier within the source system. This could be a database record number, etc. The source system must maintain the local identifier mapping table between the local identifier and the 'sourcedid';
  • The local identifier within the target systems. In general the local identifier in each target system will be different. It is the responsibility of the target systems to maintain the local mapping table between the 'sourcedid' and their local identifier.

4. Conceptual Description of the Data Objects

4.1 Underlying Structure of the Enterprise Package

The primary elements of the learner information are shown in Figure 4.1:

The primary elements of the Enterprise data structures

 

Figure 4.1 The primary elements of the Enterprise data structures.

4.2 Extensions and Extensibility

A key requirement for the specification is its support, where appropriate, for extensions. These extensions take the form:

  • Functional extensions - extensions that are included to ensure that users of the specification can add functionality that is otherwise excluded from the specification (in the following tabular descriptions these are denoted by the 'extension' data structure). Further versions of the specification make full commitment to ensure backwards compatibility with these features. Within the XML binding each of these extensions will be given a unique element name.

4.3 Enterprise Package Tabular Description

The tables in this Section provide a conceptual, informative description of the elements in the data objects. The columns in these tables refer to:

No: The number of the data element. An element may be composed of sub-elements. The numbering scheme reflects these relationships.
Name: The descriptive name of the element.
Explanation: A brief functional description of the element.
Required: Indicates if the element is required:
M = Mandatory Element that must be included in the data object, if the element at the higher level is included;
C = Conditional Element. Existence is dependent on values of other Elements;
O = Optional Element.
Mult: Multiplicity of the element:
Blank = single instance;
Number = maximum number of times the element is repeatable;
n = multiple occurrences allowed, no limit;
Repeatability of an element implies that all sub-elements repeat with the same element.
Type: A description of formatting rules for the data element - the set of data types are listed in Table 4.7. Type includes the maximum length of the element:
ID = element used to uniquely identify an object;
Code = element value from a list of codes;
Description = descriptive element, human language
Flag = binary flag
Enumerated = list of predefined non-numeric options i.e. the definitive list of objects
The international character set specified by ISO 10646 will be used for all fields.

 
The type will also include a description of the set of valid values for the sub-element:

 
Coding schemes using numerical values;

 
The set of values as defined in the Domain i.e. making it closed. The list of values cannot be extended to include values not defined in the specification. If there is a need for values not included in the domain set of values then the extension should be done defining a new element under the Extension element that is a part of each data object definition.
Note: Additional descriptive information about the element.

In the following tables the data objects are organized as:

  • Table 4.1 - the 'enterprise' data structure i.e. the structure that constitutes the enterprise package itself;
  • Table 4.2 - the 'person' data structure;
  • Table 4.3 - the 'group' data structure;
  • Table 4.4 - the 'membership' data structure;
  • Table 4.5 - the common data structures (these are used within more than one of the above data structures);
  • Table 4.6 - the functional extensions, <extension>, that are supported;
  • Table 4.7 - the set of data types used within the tabular descriptions.

4.3.1 Enterprise Data Objects

Table 4.1 describes the data objects that are used in the construction of the IMS Enterprise package itself.

 

Table 4.1 Enterprise data objects detailed description.

 
No
Name
Explanation
Reqd
Mult
Type
Note
1.1 comments A container for comments about the full data structure. O
 
See structure 5.1.
1.2 properties The container of the basic packaging information that is used to manage the exchange of the data between the source and target systems. M
 

 

 
1.2.1 lang Default language of the text information provided in the attached objects. O
 
See structure 5.2.
1.2.2 comments A container for comments about the properties data structure. O
 
See structure 5.1.
1.2.3 datasource An identifier for the source system. M
 
See structure 5.3.
1.2.4 target An identifier for the target system. O n string256 If the data objects are intended for one or more specific target systems, this element identifies those systems.
Uses the same system naming scheme as is used for the data source.
1.2.5 type Describes the type of event that caused the source system to generate the data objects. O
 
string32 A standard set of codes must be agreed upon for specific implementations. Examples are:
- Initial group creation
- Group maintenance
- Full group membership
- Membership changes
- Final grades
1.2.6 datetime Date and time the data objects were generated by the data source. M
 
See structure 5.4.
1.2.7 extension The proprietary extension facility for the <proprietary> data object. O
 
See structure 6.1.
1.3 person The container for all of the data about a particular individual. O n See Table 4.2.
1.4 group The container for all of the information about a group and its relationships to other groups. O n See Table 4.3.
1.5 membership The container for all of the information about the members (as defined in a Person structure) in a particular Group. O n See Table 4.4.

4.3.2 'person' Data Objects

Table 4.2 describes the data objects that are used in the construction of the summary results information.

 

Table 4.2 'person' data object detailed description.

 
No
Name
Explanation
Reqd
Mult
Type
Note
2.1 recstatus Defines the type of operation that is required i.e. indicates that a Person has been added, updated or deleted. O
 
See structure 5.5
2.2 comments A container for comments about the full Person structure. O
 
See structure 5.1.
2.3 sourcedid The ID of the Person as defined by the source system. M n See structure 5.6.
2.4 userid The person's user ID to access the learning management environment. O n See structure 5.9.
2.5 name The name of the Person. M
 

 
Note that the name parts specified below are to support interoperability, not to maintain a full record of a person's name.
2.5.1 fn Formatted name. M
 
string256 Examples include:
Robert Jones
Shirley R.Smith Jr.
Ling Pao
Basten Holter
2.5.2 sort Name "parsed" and re-ordered to sort appropriately on an alphabetized report or outline panel (this name is not displayed: only used for sorting). O
 
string256 Parsing schemes will be vendor specific.
2.5.3 nickname Full name formatted in the way that the Person prefers to be addressed. O
 
string256
 
2.5.4 n Name with all parts distinguished. O
 

 

 
2.5.4.1 family This is the family name and not the last name. O
 
string256 Jones
2.5.4.2 given The given name and not necessarily the first name. O
 
string256 Robert
2.5.4.3 other Other name parts. O n string256 This field is being deprecated in favour of the <partname> field.
2.5.4.4 prefix Name prefix. O
 
string32 Mr, Mrs, Ms, Dr, etc.
2.5.4.5 suffix Name suffix. O
 
string32 Jr, Snr, III, etc.
2.5.4.6 partname The name supplied in its typed component parts. O n string256
 
2.5.4.6.1 lang Default language of the part name component. O
 
See structure 5.2.
2.5.4.6.2 partnametype The type component of the name. M
 
string64 Examples of this open vocabulary include: 'Last', First', 'Middle', 'Maternal', 'Paternal', 'Initials', etc.
2.6 demographics Demographic information about the person. O
 

 
Minimal demographic information is specified.
2.6.1 gender Gender of the Person. O
 
string1
Enumerated as:
0=Unknown
1=Female
2=Male

 
2.6.2 bday Date the person was born. O
 
datetime
 
2.6.3 disability An indication of the disability category of the individual. O n string32 This information is NOT used to define the computer-based preferences of the Person.
2.7 email E-mail address used to contact a Person. O
 
See structure 5.7.
2.8 url The Web address of the Person. O
 
See structure 5.8.
2.9 tel The telephone number used to contact the Person. O n string32 International format should be used. An appropriate standard has not yet been agreed.
2.9.1 teltype Indicates what type of phone number is being specified. O
 
string8
Enumerated as:
1=Voice
2=Fax
3=Mobile
4=Pager
Voice
Fax
Mobile
Pager

 
2.10 adr Address used to deliver physical objects to a person. O
 

 
Only one address is supported.
2.10.1 pobox Post Office Box. O
 
string32
 
2.10.2 extadd Extra address space. O
 
string128 Any non-street components of the address e.g., suite number, company name, etc.
2.10.3 street Street address. O 3 string128
 
2.10.4 locality Locality. O
 
string64 City is one example of locality.
2.10.5 region Region. O
 
string64 State and Province are examples of region.
2.10.6 pcode Postal code. O
 
string32 This format varies from country to country.
2.10.7 country Country. O
 
string64 Codes specified in ISO3166.
2.11 photo Reference to an external location containing a photo of the person. O
 

 

 
2.11.1 imgtype The type of image referenced. O
 
string32 Should contain the MIME type e.g., image/bmp, image/jpg, etc.
2.11.2 extref The reference to an external location. M
 
string1024 Could be a URL.
2.12 systemrole The role of the Person within the software environment. O
 

 

 
2.12.1 systemroletype The type of role that the Person is permitted within the software environment. M
 
string32
Enumerated as:
SysAdmin
SysSupport
Creator
AccountAdmin
User
Administrator
None

 
2.13 institutionrole The role of the Person within the institution. O n
 

 
2.13.1 primaryrole Identifies if the associated role is the primary one for the Person in the institution. M
 
string4
Enumerated as:
Yes
No

 
2.13.2 institutionroletype The type of role that the Person has within the institution supporting the learning activity. M
 
string32
Enumerated as:
Student
Faculty
Member
Learner
Instructor
Mentor
Staff
Alumni
ProspectiveStudent
Guest
Other
Administrator
Observer

 
2.14 datasource An identifier of the source system of the Person object. O
 
See structure 5.3.
2.15 extension The proprietary extension facility for the Person object. O
 
See structure 6.2.

4.3.3 'group' Data Objects

Table 4.3 describes the data objects that are used in the construction of the detailed assessment results.

 

Table 4.3 'group' data object detailed description.

 
No
Name
Explanation
Reqd
Mult
Type
Note
3.1 recstatus Defines the type of operation that is required i.e. indicates that a Group has been added, updated or deleted. O
 
See structure 5.5
3.2 comments A container for comments about the full Group structure. O
 
See structure 5.1.
3.3 sourcedid The ID of the Group as defined by the source system. M n See structure 5.6.
3.4 grouptype Defines the type of Group. O n
 
This element provides a structure that allows a Group to be categorized into one or more coding schemes, with any number of levels supported within each scheme.
3.4.1 scheme Group type coding scheme. O
 
string256 Identifies which Group categorization scheme is being used. This could be a proprietary vendor taxonomy, a national subject are taxonomy, etc.
3.4.2 typevalue Group type code value. M n string256 Repeats to allow more than one level of code to be stored.
The value at this level. An example of the Level/value interaction might be:
Lvl 1 - Instruction
Lvl 2 - Discussion Group
Lvl 3 - Web enabled
3.4.2.1 level Group type code level. M
 
string2 Level 1 is the highest level, level 2 provides a further refinement of the level 1 category, etc.
3.5 description Description/name of the Group. M
 

 

 
3.5.1 short Intended to be displayed on screen on less than one line. M
 
string60 Usually something brief such as "ENGLISH 101A SECTION 4".
3.5.2 long Longer descriptive name for the Group. O
 
string256 "English 101A - Great Authors of the 19th and 20th Century".
3.5.3 full A longer description of the Group. O
 
string2048 For example the "catalog" description of a course.
3.6 org The organization administering or 'sponsoring' the Group. O
 

 
For example Cal State San Marcos would be the administrator of a course section offered on their campus.
3.6.1 orgname The name of the organization. O
 
string256 'Cal State San Marcos'.
3.6.2 orgunit Name of the sponsoring or administering unit within the organization. O n string256 One or more departments or units can sponsor the Group e.g., '0-158 - Math Department'.
3.6.3 type Used to distinguish general categories of the organization. O
 
string32 'Academic Unit'
'HR Department'.
3.6.4 id Identifier of the organization. O
 
string256 If there is a code for the organization, it can be specified separately in this field.
3.7 timeframe Time frame when the Group is active. O
 
See structure 5.10.
3.8 enrollcontrol The container for the enrolment control data. O
 

 

 
3.8.1 enrollaccept Indicates if the Group is accepting enrolments. O
 
integer1
Enumerated as:
0=No
1=Yes
There can be different reasons for a Group being closed. It may be full; it may be cancelled.
3.8.2 enrollallowed Determines if the target system can enrol people. O
 
integer1
Enumerated as:
0=No
1=Yes
If No, then only the source system can enrol people.
3.9 email E-mail address for contacting all members of a Group. O
 
See structure 5.7.
3.10 url URL for a Group. O
 
See structure 5.8.
3.11 relationship If the Group is related to another Group then this element can be used to describe that relationship. O n
 
This element should not be used to store "membership' in other Groups. The Group membership construct is used for that type of role-based membership.
3.11.1 relation Defines the nature of the relationship. O
 
string8
Enumerated as:
1=Parent
2=Child
3=Also known as
Parent
Child
KnownAs
This field is used to define the relationship of this group (defined using the identifier in field 3.11.2, known as 'A') to the object Group (defined using the identifier 3.3, known as 'B'). The relationship is "A is the <relation> of B".
Code '3' or 'KnownAs' is used to indicate that two Groups are really the same.
3.11.2 sourcedid The unique identifier of the other Group with which the relationship is being established. M
 
See structure 5.6.
3.11.3 label Describes the nature of the relationship between this Group and the related Group. M
 
string32 Examples are:
'Course sub-group'
'Cross-listed Course Section'.
3.12 datasource An identifier of the source system of the Group object. O
 
See structure 5.3.
3.13 extension The proprietary extension facility for the Group object. O
 
See structure 6.3.

4.3.4 'membership' Data Objects

Table 4.4 describes the data objects that are used in the construction of the detailed section results.

 

Table 4.4 'membership' data object detailed description.

 
No
Name
Explanation
Reqd
Mult
Type
Note
4.1 comments A container for comments about the full Membership structure. O
 
See structure 5.1.
4.2 sourcedid The ID of the Group as defined by the source system. The memberships are defined with respect to this Group. M
 
See structure 5.6.
4.3 member Group member. M n
 

 
4.3.1 comments A container for comments about the full Member structure. O
 
See structure 5.1.
4.3.2 sourcedid The ID of a Person or a Group as defined by the source system. M
 
See structure 5.6.
4.3.3 idtype Indicates if the member is a Person or another Group. M
 
integer1
Enumerated as:
1=Person
2=Group

 
4.3.4 role The role of the member in the Group. M n
 
A member can have multiple roles in a Group e.g., Learner and Instructor. These would be reflected in separate occurrences of the <role> element.
4.3.4.1 recstatus Defines the type of operation that is required i.e. indicates that a Group Membership has been added, updated or deleted. O
 
See structure 5.5
4.3.4.2 roletype The member's function within a Group. O
 
string32
Enumerated as:
01=Learner
02=Instructor
03=Content Developer
04=Member
05=Manager
06=Mentor
07=Administrator
08=TeachingAssistant
Learner
Instructor
Content Developer
Member
Manager
Mentor
Administrator
TeachingAssistant

 
4.3.4.3 subrole Further qualifies a member's role in the Group. O
 
string32 For an Instructor role type some examples are:
Primary Instructor
Tutor.
4.3.4.4 status Indicates if a member is active or inactive in the Group. M
 
integer1
Enumerated as:
0=Inactive
1=Active
This allows the source system to specifically tell the target system that a member is now active or inactive. Another view is that the absence of a membership record when membership data is passed implies inactivity and the existence of a record implies active membership. This will logically work for a 'snap-shot' interface where all members are passed every time objects are passed from one system to another but it will not support an interface where individual membership records are passed.
4.3.4.5 userid Person's user ID to access the Group for this role. O
 
See structure 5.9
4.3.4.6 comments Description of the current status. O
 
See structure 5.1.
4.3.4.7 datetime Date the current membership status was established. O
 
See structure 5.10.1.1
4.3.4.8 timeframe Time frame of membership in the Group. O
 
See structure 5.10.
4.3.4.9 interimresult Interim result codes and value. O n
 
The specification allows for the passing of a group member's interim result mode and all valid interim result values from the source system to the target system. It is provided at the Group member level because it can vary for different members of a Group.
The specification also allows for the passing of a Group member's interim result, both a result code and result description.
This structure is to be deprecated in V2.0.
_1 resulttype The type of the interim result. O
 
string32 Examples are:
'Mid-term'
'Part I'
etc.
_2 mode Short descriptive name for interim result grading mode. O
 
string32 Examples are:
'Letter Grade'
'Pass/Fail'
'Percentage'
etc.
_3 values Valid interim result values. O
 

 
Used to tell the target system what interim result values are valid to assign to a learner.
_3.1 valuetype Indicates if the values are a list of specific codes or a numeric range. M
 
integer1
Enumerated as:
0=List
1=Range
Tells the system to use either the list or the Min/Max values.
_3.2 list A specific interim result value. C n string32 The list contains the valid grades if valuetype=0.
_3.3 min Minimum numeric value allowed for an interim result. C
 
decimal8p4 Used if valuetype=1.
_3.4 max Maximum numeric value allowed for an interim result. C
 
decimal8p4 Used if valuetype=1.
_4 result Value of interim result assigned to the member for participation in the Group. O
 
string32 Ideally this would be one of the values from the results values list e.g., A+, 85%, Completed, etc.
_5 comments Comments about the interim result. O
 
See structure 5.1.
4.3.4.10 finalresult Final result codes and value. O n
 
The specification allows for the passing of a group member's final result mode and all valid result values from the source system to the target system. It is provided at the Group member level because it can vary for different members of a Group.
The specification also allows for the passing of a Group member's final result, both a result code and result description.
This structure is to be deprecated in V2.0.
_1 mode Short descriptive name for final result grading mode. O
 
string32 Examples are:
'Letter Grade'
'Pass/Fail'
'Percentage'
etc.
_2 values Valid result values. O
 

 
Used to tell the target system what final result values are valid to assign to a learner.
_2.1 valuetype Indicates if the values are a list of specific codes or a numeric range. M
 
integer1
Enumerated as:
0=List
1=Range
Tells the system to use either the list or the Min/Max values.
_2.2 list A specific result value. C n string32 The list contains the valid grades if valuetype=0.
_2.3 min Minimum numeric value allowed for a result. C
 
decimal8p4 Used if valuetype=1.
_2.4 max Maximum numeric value allowed for a result. C
 
decimal8p4 Used if valuetype=1.
_3 result Value of final result assigned to the member for participation in the Group. O
 
string32 Ideally this would be one of the values from the results values list e.g., A+, 85%, Completed, etc.
_4 comments Comments about the final result. O
 
See structure 5.1.
4.3.4.11 email E-mail address used to contact a member for information related to a specific Group membership. O
 
See structure 5.7.
4.3.4.12 datasource An identifier of the source system of the Member. O
 
See structure 5.3.
4.3.4.13 extension The proprietary extension facility for the Role object. O
 
See structure 6.4.

4.3.5 Common Data Objects

Table 4.5 describes the common data objects that are used to support the other data objects.

 

Table 4.5 Common data objects detailed description.

 
No
Name
Explanation
Reqd
Mult
Type
Note
5.1 comments Comments about the containing data structure. - - string2048
 
5.1.1 lang The written language for the comment. O
 
As per structure 5.2.
5.2 lang The written language for the string. - - string128 The vocabulary is taken from ISO639.
5.3 datasource An identifier for the original source of the information. - - string256 Allows the target system(s) to identify the system that generated the data objects.
The value must be unique for each source.
5.4 datetime Date and time the data objects were generated. - - datetime Based upon ISO8601.
5.5 recstatus The Record status i.e. the type of transaction being instigated. - - integer1
Enumerated as:
1=Add
2=Update
3=Delete
In an event driven interface this flag can be passed from the source to the target system to indicate that the object has been added, updated or deleted.
If this field is not present the target should interpret the behavior as 'Add' or 'Update'.
5.6 sourcedid The ID of the data object defined by the source. - -
 

 
5.6.1 sourcedidtype The type of sourcedid. O
 
string16
Enumerated as:
New
Old
Duplicate
This is used to enable objects to have their sourcedid altered.
The combination of 'New' and 'Old' is used to change a <sourcedid>.
The 'Duplicate' value is used to imply the redundant object.
5.6.2 source Identifier of the organization or system that assigned the ID. M
 
string32
 
5.6.3 id Permanently unique identifier of the object as defined by the system where the object was created. M
 
string256
 
5.7 email E-mail address used to contact a Person or Group. - - string256
 
5.8 url The Web address of the Person or Group. O
 
url This should be the Absolute URL i.e. include the 'http://'.
5.9 userid The person's user ID to access the learning management environment. _ _ string256 This must not be used to contain password information.
Any implementation of this specification must ensure the security of this, and all, data.
5.9.1 useridtype The type of user identification. O
 
string32 Some example values are 'NationalId' or 'InstitutionId'.
5.9.2 password The password that is assigned to the user for accessing a system. O
 
string1024
 
5.9.3 pwencryptiontype The type of encryption that has been applied to the password. O
 
string32 Example values include 'PKC' and 'MD5'.
5.9.4 authenticationtype The type of authentication that is to be applied to the system access. O
 
string32 Example values include 'Kerberos', etc.
5.10 timeframe Time frame when the Group is active. - -
 

 
5.10.1 begin Defines when the core object is intended to be available for participation. Date of availability. O
 
date Based upon the date structure of ISO8601.
5.10.1.1 restrict Defines if learner participation is permitted before the start date. M
 
integer1
Enumerated as:
0=No
1=Yes

 
5.10.2 end Defines when the core object availability is intended to end. Date of availability. O
 
date Based upon the date structure of ISO8601.
5.10.2.1 restrict Defines if learner participation is permitted after the end date. M
 
integer1
Enumerated as:
0=No
1=Yes

 
5.10.3 adminperiod Short descriptive name in human readable form for the administrative or academic period within which the group exists. O
 
string32 For example:
'- 1999'
'-Fall 1999'
etc.

4.3.6 'extension' Definitions

Table 4.6 list the set of extension names that are used within the XML binding. These names are mapped to the 'extension' element used within Tables 4.1 to 4.5 of the Information Model.

 

Table 4.6 Common data objects detailed description.

 
No
Name
Explanation
Reqd
Mult
Type
Note
6.1 extension The proprietary extension facility for the <properties> structure. - - ANY
 
6.2 extension The proprietary extension facility for the <person> structure. - - ANY
 
6.3 extension The proprietary extension facility for the <group> structure. - - ANY
 
6.4 extension The proprietary extension facility for the <role> structure. - - ANY
 

4.3.7 Data Types

Table 4.7 present the definitions of the data-type used within the tabular description of the information data model.

 

Table 4.7 Data-type definitions.

 
Data-type
Description
string1 String of characters of length [1]
string2 String of characters of length [1-2]
String4 String of characters of length [1-4]
string8 String of characters of length [1-8]
string32 String of characters of length [1-32]
string60 String of characters of length [1-60]
string64 String of characters of length [1-64]
string128 String of characters of length [1-128]
string256 String of characters of length [1-256]
string1024 String of characters of length [1-1024]
string2048 String of characters of length [1-2048]
integer1 Integer in the range [0-9] supplied as a single character.
decimal8p4 Real number in the range [0-9999.9999] supplied as a string of characters [1-9]
datetime String of characters [1-20] in ISO8601 format i.e. YYYY-MM-DDTHH:MM:SS
date String of characters [1-10] in ISO8601 format i.e. YYYY-MM-DD
url String of characters [1-1024] in Absolute URL format

5. Conformance

The purpose of this statement is to provide a mechanism for customers to fairly compare vendors of Enterprise systems and sub-systems. It is not mandatory for a vendor to support every feature of the Enterprise specification, but a vendor must detail their level of support with a "Conformance Statement". Compliance is represented by:

  • Conformance summary - this is a summary that shows, in colloquial terms, the capabilities of a particular implementation with respect to the IMS Enterprise Specification;
  • Interoperability statement - this is a detailed technical checklist that identifies all of the feature capabilities of the implementation in terms of the IMS Enterprise Specification functions.

5.1 Valid Data Issues

Vendors claiming conformance shall be able to read and write valid instances of the Enterprise data as defined by the XML Schema including proprietary extensions where applicable. For the handling of an IMS Enterprise instance the conformance statement shall:

  • Indicate that all of the mandatory information model elements are correctly formed and located within the instance;
  • Indicate that all of the optional information model elements are correctly formed and located when relevant to the instance;
  • Indicate where the extension facilities made available within the Enterprise specification have been used and/or required.

5.2 Conformance Summary

Vendors claiming conformance must provide a "Conformance Summary", detailing their level of conformance, substantially similar to the information shown below, upon a reasonable request from a member of the IMS, or a prospective customer(s). It is expected that this table, a template of which is shown in Table 5.1, is a summary of the information given in the 'Interoperability statement'. The intention is for the 'Conformance Summary' to be informative in nature.

 

Table 5.1 Enterprise conformance summary.

 

Enterprise Conformance Summary (Version 1.1)

 
Publish
Accept
properties
Y or N
Y or N
person
Y or N
Y or N
recstatus
Y or N
Y or N
sourcedid
Y or N
Y or N
userid
Y or N
Y or N
name
Y or N
Y or N
demographics
Y or N
Y or N
email
Y or N
Y or N
url
Y or N
Y or N
tel
Y or N
Y or N
adr
Y or N
Y or N
photo
Y or N
Y or N
systemrole
Y or N
Y or N
institutionrole
Y or N
Y or N
datasource
Y or N
Y or N
group
Y or N
Y or N
recstatus
Y or N
Y or N
sourcedid
Y or N
Y or N
grouptype
Y or N
Y or N
description
Y or N
Y or N
org
Y or N
Y or N
timeframe
Y or N
Y or N
enrollcontrol
Y or N
Y or N
email
Y or N
Y or N
url
Y or N
Y or N
relationship
Y or N
Y or N
datasource
Y or N
Y or N
membership
Y or N
Y or N
sourcedid
Y or N
Y or N
member
Y or N
Y or N
sourcedid
Y or N
Y or N
role
Y or N
Y or N
recstatus
Y or N
Y or N
subrole
Y or N
Y or N
status
Y or N
Y or N
userid
Y or N
Y or N
datetime
Y or N
Y or N
timeframe
Y or N
Y or N
interimresult
Y or N
Y or N
finalresult
Y or N
Y or N
email
Y or N
Y or N
datasource
Y or N
Y or N

Completion of the two columns is intended to reflect:

  • Publish - this implies that the XML instance contains the identified elements. If such an element is not ticked then it will not occur within the exported Enterprise instance(s);
  • Accept - it is assumed that the ability to accept the contents of an element is accompanied by the ability to use, and if appropriate, display that content.

5.3 Interoperability Statement

An example of the detailed 'Interoperability Statement' is shown in Tables 5.2a, 5.2b, 5.2c and 5.2d (one for each of the core structures). Compliance to Enterprise means that at least one of the columns must be completed.

 

Table 5.2a Interoperability statement (properties).

 
properties Version 1.1

Mandatory: This structure is mandatory i.e. it MUST be used in any IMS Enterprise XML instance.

q datasource
q datetime
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.

 
Publish
Accept
Notes
comments
q
q

 
target
q
q

 
type
q
q

 
lang
q
q

 
Extension Fields: These features allow the data model to be extended.

 
Publish
Accept
Notes

 
None
None
 

 

Table 5.2b Interoperability statement (person).

 
person Version 1.1
Mandatory:
q sourcedid
q name
q fn
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.

 
Publish
Accept
Notes
recstatus
q
q
 
comments
q
q
 
userid
q
q
 
name
-
-
 
sort
q
q
 
nickname
q
q
 
n
q
q
 
family
q
q
 
given
q
q
 
other
q
q
 
prefix
q
q
 
partname
q
q
 
demographics
q
q
 
gender
q
q
 
bday
q
q
 
disability
q
q
 
email
q
q
 
url
q
q
 
tel
q
q
 
adr
q
q
 
pobox
q
q
 
extadd
q
q
 
street
q
q
 
locality
q
q
 
region
q
q
 
pcode
q
q
 
country
q
q
 
photo
q
q
 
extref
-
-
 
imgtype
q
q
 
systemrole
q
q
 
institutionrole
q
q
 
datasource
q
q
 
Extension Fields: These features allow the data model to be extended.

 
Publish
Accept
Notes
extension
q
q
 

 

Table 5.2c Interoperability statement (group).

 
Group Version 1.1
Mandatory:
q sourcedid
q description
q short
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.

 
Publish
Accept
Notes
recstatus
q
q
 
comments
q
q
 
grouptype
q
q
 
scheme
q
q
 
typevalue
-
-
 
level
-
-
 
value
-
-
 
description
-
-
 
short
-
-
 
long
q
q
 
full
q
q
 
org
q
q
 
orgname
-
-
 
orgunit
q
q
 
type
q
q
 
id
q
q
 
timeframe
q
q
 
begin
q
q
 
date
q
q
 
restrict
q
q
 
end
q
q
 
date
q
q
 
restrict
q
q
 
adminperiod
q
q
 
enrollcontrol
q
q
 
enrollaccept
q
q
 
enrollallowed
q
q
 
email
q
q
 
url
q
q
 
relationship
q
q
 
relation
q
q
 
sourcedid
-
-
 
label
-
-
 
datasource
q
q
 
Extension Fields: These features allow the data model to be extended.

 
Publish
Accept
Notes
extension
q
q
 

 

Table 5.2d Interoperability statement (membership).

 
membership Version 1.1
Mandatory:
q sourcedid
q member
Optional Fields: Optional fields are informative. Checking an optional field implies that all of the associated mandatory elements are supported.

 
Publish
Accept
Notes
comments
q
q
 
member
-
-
 
comments
q
q
 
sourcedid
-
-
 
idtype
-
-
 
role
-
-
 
recstatus
q
q
 
roletype
-
-
 
subrole
q
q
 
status
-
-
 
userid
q
q

 
comments
q
q

 
datetime
q
q

 
timeframe
q
q

 
begin
q
q

 
date
q
q

 
restrict
q
q

 
end
q
q

 
date
q
q

 
restrict
q
q

 
adminperiod
q
q

 
interimresult
q
q

 
resulttype
q
q

 
mode
q
q

 
values
q
q

 
valuetype
-
-

 
list
q
q

 
min
q
q

 
max
q
q

 
result
q
q

 
comments
q
q

 
finalresult
q
q

 
mode
q
q

 
values
q
q

 
valuetype
-
-

 
list
q
q

 
min
q
q

 
max
q
q

 
result
q
q

 
comments
q
q

 
email
q
q

 
datasource
q
q

 
Extension Fields: These features allow the data model to be extended.
 
Publish
Accept
Notes
extension
q
q
 

Note that the 'Interoperability Statement' addresses support for the various elements within the binding. The set of attributes are not considered. Inclusion of conformance with respect to attributes will be considered in later versions of the specification.

It is important that the 'Interoperability Statement' is clear in showing what is and, perhaps more importantly, what is not supported. The usage of descriptive conformance approach has been adopted to encourage vendors to be as clear as possible when describing the capabilities of their Enterprise-compliant systems.

Appendix A - Class Descriptions

These class descriptions have been added to act as bridging information between the v1.1 and v2.0 information models. These are the core classes and no form of aggregation has been undertaken. The class descriptions are contained in tables A1, A2, A3, and A4. The form of the class descriptions includes:

  • attribute - the name of the data component;
  • type - the data type of the attribute;
  • mult - the multiplicity of the occurrence of the attribute (O=optional, M=mandatory, O*=optional but many occurrences, M*=mandatory but many occurrences);
  • constraint - any constraints that are to be applied to the possible values for the attributes.

A1 - Data Types

The data types used in the class descriptions are:

string1 String of characters [1]
string2 String of characters [2]
string4 String of characters [1-4]
string8 String of characters [1-8]
string32 String of characters [1-32]
string60 String of characters [1-32]
string64 String of characters [1-64]
string128 String of characters [1-128]
string256 String of characters [1-256]
string1024 String of characters [1-1024]
string2048 String of characters [1-2048]
integer1 Integer in the range [0-9]
decimal8p4 Real number in the range [0-9999.9999]
datetime String of characters [1-20] in ISO8601 format
url String of characters [1-1024] in URL format

A2 - Properties Class

The properties class is shown in Table A1.

 

Table A.1 The <properties> class.

 
properties
attribute
type
mult
constraint

-comments

string2048

O


 

-datasource:

string256

M


 

-target:

string256

O*


 

-type:

string32

O


 

-datetime:

datetime

M


 

-lang:

string128

O

Vocabulary - ISO639

A3 - Person Class

The properties class is shown in Table A2. All of the changes introduced in V1.1 are shaded.

 

Table A.2 The <person> class.

 
person
attribute
type
mult
constraint
-recstatus integer1 O {1=Add, 2=Update, 3=Delete}
-comments string2048 O
 
-lang string128 O Vocabulary - ISO639
-sourcedid
 
M*
 
-sourcedidtype string16 O {New, Old, Duplicate}
-source string32 M
 
-id string256 M
 
-userid string256 O*
 
-useridtype string32 O
 
-password string1024 O
 
-pwencryptiontype string32 O
 
-authenticationtype string32 O
 
-name
 
M
 
-fn string256 M
 
-sort string256 O
 
-nickname string256 O
 
-n
 
O
 
-family string256 O
 
-given string256 O
 
-other string256 O*
 
-prefix string32 O
 
-suffix string32 O
 
-partname string256 O*
 
-lang string128 O Vocabulary - ISO639
-partnametype
 
M
 
-demographics
 
O
 
-gender string1 O {0=Unknown, 1=Female, 2=Male}
-bday datetime O
 
-disability string64 O
 
-email string256 O
 
-url url O
 
-tel string32 O4
 
-teltype string8 O {1=Voice, 2=Fax, 3=Mobile, 4=Pager, Voice, Fax, Mobile, Pager}
-adr
 

 

 
-pobox string32 O
 
-extadd string128 O
 
-street string128 O3
 
-locality string64 O
 
-region string64 O
 
-pcode string32 O
 
-country string64 O Vocabulary - ISO3166
-photo
 

 

 
-extref string1024 M
 
-imgtype string32 O
 
-systemrole
 
O
 
-systemroletype string32 M {SysAdmin, SysSupport, Creator, AccountAdmin, User, Administrator, None}
-institutionrole
 
O*
 
-primaryrole string4 M {Yes, No}
-institutionroletype string32 M {Student, Faculty, Member, Learner, Instructor, Mentor, Staff, Alumni, ProspectiveStudent, Guest, Other, Administrator, Observer}
-datasource string256 O
 

A4 - Group Class

The properties class is shown in Table A3.

 

Table A.3 The <group> class.

 
group
attribute
type
mult
constraint
-recstatus integer1 O {1=Add, 2=Update, 3=Delete}
-comments string2048 O
 
-lang string128 O Vocabulary - ISO639
-sourcedid
 
M*
 
-sourcedidtype string16 O {New, Old, Duplicate}
-source string32 M
 
-id string256 M
 
-grouptype
 
O*
 
-scheme string256 O
 
-typevalue string256 M*
 
-level string2 M
 
-description
 
M
 
-short string60 M
 
-long string256 O
 
-full string2048 O
 
-org
 

 

 
-orgname string256 M
 
-orgunit string256 O*
 
-type string32 O
 
-id string256 O
 
-timeframe
 
O
 
-begin datetime O
 
-restrict integer1 M {0=No, 1=Yes}
-end datetime O
 
-restrict integer1 M {0=No, 1=Yes}
-adminperiod string32 O
 
-enrollcontrol
 
O
 
-enrollaccept integer1 O {0=No, 1=Yes}
-enrollallowed integer1 O {0=No, 1=Yes}
-email string256 O
 
-url url O
 
-relationship
 
O
 
-relation string8 O {1=Parent, 2=Child, 3=KnownAs, Parent, Child, KnownAs}
-sourcedid
 
M
 
-sourcedidtype string16 O {New, Old, Duplicate}
-source string32 M
 
-id string256 M
 
-label string32 M
 
-datasource string256 O
 

A5 - Membership Class

The membership class is shown in Table A4.

 

Table A.4 The <membership> class.

 
membership
attribute
type
mult
constraint
-comments string2048 O
 
-lang string128 O Vocabulary - ISO639
-sourcedid
 
M
 
-sourcedidtype string16 O {New, Old, Duplicate}
-source string32 M
 
-id string256 M
 
-member
 
M*
 
-comments string2048 O
 
-lang String128 O Vocabulary - ISO639
-sourcedid
 
M
 
-sourcedidtype string16 O {New, Old, Duplicate}
-source string32 M
 
-id string256 M
 
-idtype integer1 M
 
-role
 
M*
 
-recstatus integer1 O {1=Add, 2=Update, 3=Delete}
-roletype string32 M {01=Learner, 02=Instructor, 03=Content Developer, 04=Member, 05=Manager, 06=Mentor, 07=Administrator, 08=TeachingAssistant, Learner, Instructor, Content Developer, Member, Manager, Mentor, Administrator, TeachingAssistant}
-lang string128 O Vocabulary - ISO639
-subrole string32 O
 
-status integer1 M {0=Inactive, 1=Active}
-userid string256 O*
 
-useridtype string32 O
 
-password string1024 O
 
-pwencryptiontype string32 O
 
-authenticationtype string32 O
 
-comments string2048 O
 
-lang string128 O Vocabulary - ISO639
-datetime datetime O
 
-timeframe
 
O
 
-begin datetime O
 
-restrict integer1 M {0=No, 1=Yes}
-end datetime O
 
-restrict integer1 M {0=No, 1=Yes}
-adminperiod string32 O
 
-interimresult
 
O*
 
-resulttype string32 O
 
-mode string32 O
 
-values
 
O
 
-valuetype integer1 M {0=List, 1=Range}
-list string32 O*
 
-min decimal8p4 O
 
-max decimal8p4 O
 
-result string32 O
 
-comments string2048 O
 
-lang string128 O Vocabulary - ISO639
-finalresult
 
O*
 
-mode string32 O
 
-values
 
O
 
-valuetype integer1 M {0=List, 1=Range}
-list string32 O*
 
-min decimal8p4 O
 
-max decimal8p4 O
 
-result string32 O
 
-comments string2048 O
 
-lang string128 O Vocabulary - ISO639
-email string256 O
 
-datasource string256 O
 

Appendix B - Summary of Changes in this Document

The detailed list of changes are summarized below:

 
Reference in V1.01 Document Reference in this Document Description
Title Page Title Page New title for the document.
Introduction Introduction A complete rewrite of the introduction.

 
Specification Use Cases A new Section focused on describing the core use-cases that the Enterprise V1.1 Specification is designed to support.
Overall Data Model Basic Information Model A reworking of the basic information model to include the underlying simple messaging model employed.
Conceptual Description of the Data Objects Conceptual Description of the Data Objects A reworking of the tabular description of the Enterprise Information Model. The core changes are:
- Addition of Table 4.1
- Changes in Table 4.2 of the entries 2.2, 2.3, 2.4, 2.5.4.6.1, 2.6.1, 2.6.3, 2.8, 2.9, 2.12 and 2.13
- Changes in Table 4.3 of the entries 3.2, 3.3 and 3.11.1
- Changes in Table 4.4 of 4.1, 4.2, 4.3.1, 4.3.4.2, 4.3.4.9, and 4.3.4.10
- Changes in Table 4.5 of the entries 5.1.1, 5.2, 5.6.1, 5.9.1, 5.9.2, 5.9.3 and 5.9.4
- The addition of Tables 4.6 and 4.7.

 
Conformance A new Section that describes the Conformance Summary and Interoperability statements that should be used to describe an IMS Enterprise V1.1 implementation.

 
Appendix A The inclusion of a new Appendix that provides the details of the class descriptions of the Enterprise data structures.

 
Appendix B The provision of a detailed list of changes made between the V1.01 and the V1.1 document releases.

 
About This Document New details describing the document.

 
Revision History Addition of the details of the release of the final version of the document.

 
Index Provision of an Index to the document.

About This Document

 
Title: IMS Enterprise Information Model
Authors: Colin Smythe, Geoff Collier, Chris Etesse, and Wayne Veres
Version: 1.1
Version Date: 01 July 2002
Status: Final Specification
Summary: This document presents the IMS Enterprise Information Model. This specification describes the data model for the exchange between Enterprise systems and sub-systems.
Revision Information: 10 June 2002
Purpose: This is the third formal release of the IMS Enterprise Specification
Document Location: http://www.imsglobal.org/enterprise/entv1p1/imsent_infov1p1.html

List of Contributors

The following individuals contributed to the development of this document:

Fred Beshears UC Berkeley, USA
Kerry Blinco IMS Australia
Glen Clingroth Eduprise Inc.
Geoff Collier Eduworks, Inc.
John Eyre JISC/CETIS, UK
Chris Etesse Blackboard Inc.
Ron Kleinman SUN Microsystems Inc.
Kerty Levy DigitalThink Inc.
Tim Magnor SIIA, USA
Colin Smythe Dunelm Services Ltd.
Wayne Veres California State University, USA
Kimberley Voltero WebCT Inc.

Revision History

 
Version No.
Release Date
Comments
Final Version 1.0 21 November 1999 The first formal release of the IMS Enterprise Information Model;
Final Version 1.01 21 December 1999 The second formal release of the IMS Enterprise Information Model. The amendments consist of a series of bug fixes;
Final Version 1.1 01 July 2002 The amendments made in this final release of the IMS Enterprise V1.1 Specification are:
- New functions based upon commonly used extensions have been added;
- A limited amount of new functionality has been added;
- A Section that describes the use-cases has been added;
- The tabular descriptions have be reworked to include data typing and the new elements and attributes;
- A new 'Conformance statement' has been added;
- Appendix A has been added to contain the class descriptions;
- Appendix B has been added to provide the details of all the changes made in this document.

Index

A
Architecture 1
Attributes
     authenticationtype 1
     imgtype 1, 2
     institutionroletype 1
     lang 1, 2, 3, 4
     level 1, 2, 3, 4, 5, 6
     partnametype 1
     password 1, 2
     primaryrole 1
     pwencryptiontype 1
     recstatus 1, 2, 3, 4, 5, 6, 7, 8, 9
     relation 1, 2
     restrict 1, 2, 3, 4
     resulttype 1, 2
     roletype 1, 2
     sourcedidtype 1
     systemroletype 1
     teltype 1
     useridtype 1
     valuetype 1, 2, 3
 

C
Conformance 1, 2, 3, 4
Core data objects
     Group 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
     Membership 1, 2, 3, 4
     Person 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
 

E
Elements
     adminperiod 1, 2, 3
     adr 1, 2, 3
     bday 1, 2
     begin 1, 2, 3
     comments 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
     country 1, 2
     datasource 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     datetime 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
     demographics 1, 2, 3
     description 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
     disability 1, 2
     email 1, 2, 3, 4, 5, 6, 7, 8, 9
     end 1, 2, 3
     enrollaccept 1, 2
     enrollallowed 1, 2
     enrollcontrol 1, 2, 3
     enterprise 1, 2, 3
     extadd 1, 2
     extension 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
     extref 1, 2
     family 1, 2
     finalresult 1, 2, 3
     fn 1, 2
     full 1, 2, 3, 4, 5, 6, 7
     gender 1, 2
     given 1, 2, 3, 4, 5
     group 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
     grouptype 1, 2, 3
     id 1, 2, 3, 4
     idtype 1, 2
     institutionrole 1, 2, 3
     interimresult 1, 2, 3
     label 1, 2, 3
     list 1, 2, 3, 4, 5, 6
     locality 1, 2
     long 1, 2
     max 1, 2
     member 1, 2, 3, 4, 5, 6, 7
     membership 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
     min 1, 2, 3
     mode 1, 2, 3
     n 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     name 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
     nickname 1, 2
     org 1, 2, 3
     orgname 1, 2
     orgunit 1, 2
     other 1, 2, 3, 4, 5, 6, 7, 8, 9
     partname 1, 2
     pcode 1, 2
     person 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
     photo 1, 2, 3
     prefix 1, 2
     properties 1, 2, 3, 4, 5, 6, 7, 8
     region 1, 2
     relationship 1, 2, 3
     result 1, 2, 3, 4, 5
     role 1, 2, 3, 4, 5, 6, 7
     scheme 1, 2, 3, 4, 5
     short 1, 2
     sort 1, 2
     source 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
     sourcedid 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
     status 1, 2, 3, 4
     street 1, 2
     subrole 1, 2, 3
     suffix 1
     systemrole 1, 2, 3
     target 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     tel 1, 2, 3
     timeframe 1, 2, 3, 4, 5, 6
     type 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17
     typevalue 1, 2
     url 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
     userid 1, 2, 3, 4, 5, 6, 7, 8
     values 1, 2, 3, 4, 5, 6, 7, 8
 

G
Group 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12

M
Membership 1, 2, 3, 4

P
Person 1, 2, 3, 4, 5, 6, 7, 8, 9, 10

U
Use-case
     Enrollment management 1
     Final result processing 1
     Group management 1
Use-cases 1, 2, 3
 

V
Version 1.1 Additions
     Attributes
 

authenticationtype 1

institutionroletype 1

partnametype 1

primaryrole 1

pwencryptiontype 1

resulttype 1, 2

sourcedidtype 1

systemroletype 1

useridtype 1      Elements
 

disability 1, 2

institutionrole 1, 2, 3

interimresult 1, 2, 3

partname 1, 2

systemrole 1, 2, 3

X
XML
     DTD 1, 2
     XSD 1
 

1
For consistency with the other IMS specifications the V1.1 Enterprise DTD uses a lower-case naming convention for elements and attributes. The V1.0 and V1.01 DTDs used an upper-case naming convention.

 

 

 

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Enterprise Information Model ("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.imsglobal.org

Please refer to Document Name:
IMS Enterprise Information Model Date: 01 July 2002