IMS Logo IMS Enterprise Information Model

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 Information Model v1.01
Revision: 21 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.


Introduction

The IMS Enterprise Information Model describes data structures that are used to provide interoperability of Internet-based Instructional Management systems with other Enterprise systems used to support the operations of an organization.

The objective of the IMS Enterprise Information Model 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. The major classes of Enterprise applications supported by this model are Training Administration, Student Administration, Library Management, and Human Resource systems.

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

 

Overall Data Model

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

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

 

Conceptual Description of the Data Objects

The tables in this section provide a conceptual, informative description of the elements contained in the data objects.

Description of the columns in these tables:

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. For example, in the Person object, Name is a mandatory element of the Person Object, and FN is a mandatory element of Name. Another example, TelNum is a mandatory element of Tel, although Tel is an optional element of the Person Object.C = Conditional Element. Existence is dependent on values of other Elements.O = Optional ElementBlank = single instanceNumber = maximum number of times the element is repeatablen = Multiple occurrences allowed, no limitRepeatability of an element implies that all sub-elements repeat with the elementCoding schemes use numeric codes rather than alphabetic representations (e.g. "1" for male rather than "M") in order to make them language independent.If a set of values is defined in the Domain, then the domain is 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 by defining a new element under the Extension element that is part of each data object definition.ID = element used to uniquely identify an objectCode = element value from a list of codesDescr = descriptive element, human languageFlag = binary flagThe international character set specified by ISO 10646 will be used for all fields.No.NameExplanationReqdMultiDomainTypeNoteExample1.1DataSourceAn identifier for the source systemM  IDString
256-Allows the target system(s) to identify the system that generated the data objects
-- Value must be unique for each source- 1.2TargetAn identifier for a target systemOn IDString
256- If the data objects are intended for one or more specific target systems, this element identifies those systems
-- Must use the same system naming scheme as is used for data source 1.3TypeDescribes the type of event that caused the source system to generate the data objectsO  Code
String 32- A standard set of codes must be agreed upon for any specific implementationExamples:
- Initial Group Creation
- Group maintenance
- Full group membership
- Membership changes
- Final gradesp1.4Datetime Date and time the data objects were generated by the data sourceM  Date time in ISO8601 standard format  1.5Lang Default language of the text information provided in the attached objectsO Language codes defined in ISO 639Code
String 128  1.6ExtensionActs as the high level element for any extensions to the data objectO   All extensions are to be implemented as sub-elements under this element 

 

 

Person Data Object

When a person data object is passed, the target system will update its files with the data in the object. If it is a new person, they will be added to the system. If a person's data has changed, the new data should be used to update the target system. If a person is flagged for deletion, it is up to the target system to determine what action to take with that deletion information.

The target system needs to be capable of storing the source system's "Sourced ID", which is used to uniquely identify a person within the implementation environment. This is required to support future updates of person information from the source system.

 

No. Name Explanation Reqd Multi Domain Type Note Example
2.1 SourcedID The ID of a person as defined by the source system M       In order to be unique, a Person ID must include both an identifier of the system where the Person object was created, and a unique identifier within that system.  
2.1.1 Source Identifier of the organization or system that assigned the ID M     ID
String 32
   
2.1.2 ID Permanently unique identifier for a person, as defined by the system where the person object was created M     ID
String 256
   
2.2 RecStatus Record Status - Indicates that the person has been added, updated, or deleted in the source system O   1 = Add
2 = Update
3 = Delete
Code
Numeric 1
In an event driven interface, this flag can be passed from the source to the target system to indicate that the person has been added, updated, or deleted.  
2.3 UserID Person's user ID to access the Learning Management environment O     Code
String 256
Any implementation of this specification must ensure the security of this, and all, data.  
2.4 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 names.  
2.4.1 FN Formatted name M     Descr
String 256
  - Robert Lawdon Jones III
- Shirley R. Smith Jr.
- Ling Pao
- Basten Holter
2.4.2 Sort Name "parsed" and re-ordered so it will sort appropriately on an alphabetized report or online panel ( This name is never displayed, it is only used to sort.) O     Descr
String 256
"Parsing" schemes will be vendor specific. The examples at right use a scheme that concatenates the first five letters of family name followed by the first five letters of Given name "HOLTEBAS " rather than Basten Holter
"JONESROBER" rather than Robert Jones
"LING PAO" rather than Ling Pao
2.4.3 Nickname Full name formatted in the way that the person prefers to be addressed O     Descr
String 256
  Bob Jones, rather than Robert Lawdon Jones III
2.4.4 N Name with all parts distinguished O          
2.4.4.1 Family Note that this is the Family name, not the Last name (The order of name parts varies by culture.) O     Descr
String 256
  Jones
2.4.4.2 Given Given name, not necessarily first name (The order of name parts varies by culture.) O     Descr
String 256
  Robert
2.4.4.3 Other Other name parts O n   Descr
String 256
  Lawdon
2.4.4.4 Prefix   O     Descr
String 32
  Mr, Mrs, Ms, Mssr, Dr, etc
2.4.4.5 Suffix   O     Descr
String 32
  Jr, III, Sr, etc.
2.5 Demographics Demographic information about the person O       Minimal demographic information is specified. This is useful for the confirmation of identity. Other data elements such as citizenship, ethnicity, and place of birth have been considered for the standard specification, but no specific interoperability need has been found for these elements as yet.  
2.5.1 Gender Gender of the person O   0 = unknown
1 = female
2 = male
Code
String 1
   
2.5.2 BDay Date the person was born O   0001-01-01 to 9999-12-31 Code
String 1
Date in ISO8601 standard format  
2.6 Email Email address used to contact a person O     Descr
String 256
No repeatability? supported in specification, because no specific interoperability need has been identified for more than one occurrence of Email Address.  
2.7 Tel Telephone number used to contact a person O 2        
2.7.1 TelType Indicates what type of phone number is being specified. O   1 = Voice
2 = Fax
Code
String 8
   
2.7.2 TelNum Telephone number M     Code
String 32
International format should be used. An appropriate, widely accepted standard has not been agreed on yet. People implementing the spec will have to decide on their own format. One example of a format is:+ccc (aaa) nnnnn nnnnn.
+c = Country Code.
(a) = Area Code.
n = local numbers
blanks are allowed
2.8 Adr Address used to deliver physical objects to a person O       Only one address is supported in the specification because no specific interoperability need has been identified for more than one Address.  
2.8.1 POBox Post Office Box O     Descr
String 32
   
2.8.2 ExtAdd Extra address data O     Descr
String 128
Any "non street" components of the address, suite number, company name, care of, etc,  
2.8.3 Street Street address O 3   Descr
String 128
Ordered list--should be used in the order presented  
2.8.4 Locality Locality O     Descr
String 64
City is one example of Locality  
2.8.5 Region Region O     Descr
String 64
State and Province are examples of Region  
2.8.6 PCode Postal Code O     Descr
String 32
Format of postal code varies by country  
2.8.7 Country Country O   Codes specified in ISO 3166 Descr
String 64
   
2.9 Photo Reference to an external location containing a photo of the person O          
2.9.1 ExtRef The reference to an external location M     Descr
String 1024
Could be a URL-- Web standards for location references are not finalized. When they are, this specification will incorporate them.  
2.9.2 ImgTyp The type of image referred to O     Descr
String 32
Should contain the IANA registered image type bmp
jpg
gif
2.10 DataSource An identifier of the source system for the person object O     ID
String 256
Used to identify the source system for the data object. Allows more than one source system to provide objects in the same file of data objects.  
2.11 Extension Acts as the high level element for any extensions to the data object O       All extensions are to be implemented as sub-elements under this element.  

 

 

Group Data Object

When a group data object is passed, the target system will update its files with the data in the object. If it is a new group, it will be added to the system. If a group's data has changed, the new data should be used to update the target system. If a group is flagged for deletion, it is up to the target system to determine what action to take with that deletion information.

The target system needs to be capable of storing the source system's "Sourced ID", which is used to uniquely identify a group within the implementation environment. This is required to support future updates of group information from the source system. It is possible to have a viable interface without automatically exchanging Group data, but this means that one or the other of the systems involved in an interface must first store the other system's Group Identifier in order to support the passing of Group membership data.

A NOTE ON META-DATA LEARNING GROUP DESCRIPTIONS: The IMS Meta-data Specification is designed to allow systems to interchange descriptive information about a learning object, including learning groups such as course instances for which this IMS Enterprise Specification also defines a data interchange object. The difference is that the Enterprise Group Data Object described below is designed to pass data related to the operation and management of a learning group, whereas the Meta -data Object is designed to describe the content of a learning object. Therefore, if there is a need to pass more extensive descriptive information about a learning group between systems than is allowed by this Enterprise Specification, then the Meta-data Specification should be used as the guide for passing the descriptive information.

 

No. Name Explanation Reqd Multi Domain Type Note Example
3.1 SourcedID Unique group identifier M       In order to be unique, a Group ID must include both an identifier of the system where the Group object was created, and a unique identifier within that system  
3.1.1 Source Identifier of the organization or system that created the group object M     ID
String 32
   
3.1.2 ID Permanently unique identifier for a group, as defined by the system where the group object was created M     ID
String 256
  The standard supports any type of ID, from a term id and sequential number typically assigned, to a course instance in a student administration system, to the URL address of a course instance in an Internet Learning Management System
3.2 RecStatus Record Status - Indicates that the group has been added, updated or deleted from in source system O   1 = Add
2 = Update
3 = Delete
Flag
Numeric 1
In an event driven interface, this flag can be passed from the source to the target system to indicate that the group has been added, updated, or deleted.  
3.3 GroupType Defines what type of group this is 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.3.1 Scheme Group Type coding scheme O       Identifies which Group categorization scheme is being used. This could be a proprietary vendor taxonomy, a national subject area taxonomy, etc..  
3.3.2 TypeValue   M n     Repeats to allow more than one level of code to be stored.  
3.3.2.1 Level Group Type code level M     Numeric
String 2
Level 1 is the highest level, level 2 provides a further refinement of the level 1 category, etc.  
3.3.2.2 Value Group Type code value M     Descr
String 256
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 Description Description / Name of the Group M          
3.4.1 Short Intended to be displayed on screen on less than one line M     Descr
String 60
  Usually something brief such as "ENGLISH 101A SECTION 4".
3.4.2 Long Longer descriptive name for the group O     Descr
String 256
  "English 101A - Great Authors of the 19th and 20th Century"
3.4.3 Full A longer description of the group O     Descr
String 20486
  For example, the "catalog" description of a course
3.5 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.5.1 OrgName The name of the organization M     Descr
String 256
  "Cal State San Marcos"
3.5.2 OrgUnit Name of sponsoring or administering unit within the organization O n   Descr
String 256
One or more departments or units can sponsor the group. "0158 - Math Department"
3.5.3 Type Used to distinguish general categories of organization O     Descr
String 32
  "Academic Unit""HR Department"
3.5.4 ID ID of the organization O     Descr
String 256
If there is a code for the organization, it can be specified separately in this field.  
3.6 TimeFrame Time frame when the group is active O          
3.6.1 Begin Defines when a group is intended to be available for participation O          
3.6.1.1 Date Date of availability M   0001-01-01to 9999-12-31 Date in ISO8601 standard format    
3.6.1.2 Restrict Do not allow learner participation until the begin date C   0 = no
1 = yes
Flag
Numeric 1
fixed
This field can only exist if the begin date is provided.  
3.6.2 End Defines when group participation is intended to end O          
3.6.2.1 Date Date participation is intended to end M   0001-01-01to 9999-12-31 Date in ISO8601 standard format    
3.6.2.2 Restrict Do not allow learner participation after the end date C   0 = no
1 = yes
Flag
Numeric 1
fixed
This field can only exist if the end date is provided.  
3.6.3 AdminPeriod Short descriptive name in human readable form for the administrative or academic period within which the group exists O     Code
String 32
  - 1999
- Fall 1999
- Summer 1999
Session 2
3.7 EnrollControl   O          
3.7.1 EnrollAccept Indicates if the Group is accepting enrollments O   0 = no
1 = yes
Flag
Numeric 1
fixed
  There can be different reasons for a group being closed. It may be full; it may be cancelled.
3.7.2 EnrollAllowed Determines if target system can enroll people O   0 = no
1 = yes
Flag
Numeric 1
fixed
If No, then only the source system can enroll people.  
3.8 Email Email address used to contact all members of a group O     ID
String 256
Email distribution address for the group  
3.9 URL URL for a group O     Descr
String 256
For a course, this would be the course home page.  
3.10 Relationship If the group is related to another group, then this Element can be used to describe that relationship O n     The relationship described is the relationship of the group to the Group defined in the Group object. For example, if the Label element says "Subgroup" and the Relation element is "2" (child), then the group in this element is a subgroup, and a child of the group defined in the group object.Note that this relationship segment should not be used to store "membership" in other groups. The Group membership construct is used for that type of role- based membership.  
3.10.1 SourcedID Unique group identifier M       ID of the other group, with which we are establishing a relationship.  
3.10.1.1 Source Identifier of the organization or system that created the group object M     ID
String 32
   
3.10.1.2 ID Permanently unique identifier for a group, as defined by the system where the group object was created M     ID
String 256
   
3.10.2 Label Describes the nature of the relationship between this group and the related group. M     Code
String 32
  "Course Subgroup"
"Cross Listed Course Section"
3.10.3 Relation Defines the "hierarchical" nature of the relationship, if there is such a hierarchy O   1=parent
2=child
3 =also known as
Code
String 8
Relation should be read as "Group is Relation of the Relationship group". That is, if the group object is "Marketing Division", the relationship group is "Northwest Region", and the relation is "1", then the logical relationship is "Marketing Division is the parent of Northwest Region".

Code "3" (also known as) is used to indicate that two groups are really the same group. An example of this might be cross listed course sections

 
3.11 DataSource An identifier of the source system for the group object O     ID
String 256
Used to identify the source system for the data object. Allows more than one source system to provide objects in the same file of data objects.  
3.12 Extension Acts as the high level element for any extensions to the data object O     Code
String 8
All extensions are to be implemented as sub-elements under this element.  

 

 

Membership Data Object

This object is primarily intended to pass group membership information from systems that manage various types of group enrollment processes to the systems that provide Learning Management services to those group members. The enrollment processes referred to here include a wide range of specific functionality, including but not limited to, examples such as:

 

< >enrollment in a course,employment in a particular company division, ormembership in a club.No.NameExplanationReqdMultiDomainTypeNoteExample4.1SourcedIDUnique group identifierM     4.1.1SourceIdentifier of the organization or system that created the group objectM  ID
String 32  4.1.2IDPermanently unique identifier for a group, as defined by the system where the group object was createdM  ID
String 256  4.2MemberGroup MemberMn    4.2.1SourcedIDThe ID of a person or group as defined by the source systemM   In order to be unique, a Person ID must include both an identifier of the system where the Person object was created, and a unique identifier within that system. 4.2.1.1SourceIdentifier of the organization or system that assigned the IDM  ID
String 32  4.2.1.2IDPermanently unique identifier for a person or group, as defined by the system where the person or group object was createdM  ID
String 256  4.2.2IDTypeIndicates if the member is a person, or another group.M 1 = Person
2 = GroupFlag
Numeric 1 A member can either be a person or another group.4.2.3Role Mn  - A member can have multiple roles in a group (for example Learner and Instructor). These would be reflected in separate occurrences of the Role element. 4.2.3.1RoleTypeThe member's function within a groupM 01=Learner
02=Instructor
03=Content Developer
04=Member
05=Manager
06=Mentor
07=AdministratorCode
String 32  4.2.3.2SubRoleFurther qualifies a member's role in the groupO  Code
String 32 For an Instructor RoleType, examples are:Primary Instructor
Teaching Assistant
Tutor4.2.3.3StatusIndicates if a member is active or inactive in the groupM 0 = Inactive
1 = ActiveFlag
Numeric
1 fixed- 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 "snapshot" 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.2.3.4RecStatusRecord Status - Indicates that the group membership has been added, updated, or deleted from in source systemO 0 = Add
2 = Update
3 = DeleteFlag
Numeric
1In an event driven interface, this flag can be passed from the source to the target system to indicate that the group membership has been added, updated, or deleted 4.2.3.5UserIDPerson's user ID to access the group for this roleO  Code
String 256Any implementation of this specification must ensure the security of this, and all, data. 4.2.3.6CommentsDescription of the current statusO  Descr
String 2048May be used to describe why a member's status changed, or simply to record more detail about a member's status in the group 4.2.3.7DateDate the current membership status was establishedO 0001-01-01 to 9999-12-31Date in ISO8601 standard format  4.2.3.8TimeframeTime frame of membership in a groupO     4.2.3.8.1BeginDefines when a group is intended to be available for participation for this member.O     4.2.3.8.1.1DateDate of availabilityM 0001-01-01 to 9999-12-31Date in ISO8601 standard format  4.2.3.8.1.2RestrictDo not allow member participation until the begin dateC 0 = no
1 = yesFlag
Numeric
1 fixedThis field can only exist if the begin date is provided. 4.2.3.8.22EndDefines when group participation is intended to end for this memberO     4.2.3.8.2.1DateDate participation is intended to endM 0001-01-01 to 9999-12-31Date in ISO8601 standard format  4.2.3.8.2.2RestrictDo not allow member participation after the end dateC 0 = no
1 = yesFlag
Numeric
1 fixedThis field can only exist if the end date is provided. 4.2.3.9Final ResultFinal result codes and valueO   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 (e.g. - one learner could be on a graded basis, another pass/fail, and another auditing, with no valid result codes).The specification also allows for the passing of a group member's final result, both a result code and result description.. 4.2.3.9.1ModeShort descriptive name for final result grading modeO  Code
String 32 "Letter Grade"
"Pass/Fail"
"Percentage""Attendance"4.2.3.9.2ValuesValid result values.O  Code
String 2048Used to tell the target system what final result values are valid to assign to a learner 4.2.3.9.2.1ValueTypeIndicates if the values are a list of specific codes, or a numeric rangeM 0 = List
1 = RangeFlag
Numeric
1 FixedTells the system to use either the list or the Min / Max values. 4.2.3.9.2.2ListA specific result valueCn Code
String 32The list contains the valid grades if Value Type = 0 4.2.3.9.2.3MinMinimum numeric value allowed for a resultC  Code
Numeric
8 to 4 decimalsUsed if Value type = 1 4.2.3.9.2.4MaxMaximum numeric value allowed for a resultC  Code
Numeric
8 to 4 decimalsUsed if Value type = 1 4.2.3.9.3ResultValue of final result assigned to the member for participation in the group.O  Code
String 32Ideally, this would be one of the values from the Result values list.- A+
- 85%
- Completed
- Attended4.2.3.9.4CommentsComments about final resultO  Descr
String 2048Can be used for a descriptive evaluation of a learner's participation in a group 4.2.3.10EmailEmail address used to contact a member for information related to a specific group membershipO  Descr
String 256Used if the member has a different Email address for a specific group. 4.2.3.11DataSourceAn identifier of the source system for the membership objectO0 ID
String 256Used to identify the source system for the data object. Allows more than one source system to provide objects in the same file of data objects. Note that this is specified at the role level.For example, Student roles could come from one source system, and Learner roles could come from another source system, and both be transmitted in the same file of data objects.4.2.3.12ExtensionActs as the high level element for any extensions to the data objectO   All extensions are to be implemented as sub-elements under this element. 

 

Addendum

Changes to the v1.0 of the IMS Enterprise Systems Information Model are as follows:

 

Type of Problem Technical Error
Date December 14, 1999
Problem Description Inconsistency between the Information Model and the XML Binding Specification
References in Document Enterprise Information Model p. 6 - Language element
Solution Proposed by the Submitter 1) Element called Language should be renamed to Lang to be consistent with Enterprise and Metadata DTDs.

 

 

Type of Problem Clarification
Date December 14, 1999
Problem Description Group relation description does not make it completely clear how the relation ties the two groups together.
References in Document Enterprise Information Model p. 20 - Relation description
Solution Proposed by the Submitter 2) Insert the following paragraph in front of the existing comment.Relation should be read as "Group is Relation of the Relationship group". That is, if the group object is "Marketing Division", the relationship group is "Northwest Region", and the relation is "1", then the logical relationship is "Marketing Division is the parent of Northwest Region".

 

 

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 Enterprise Information Model - p. 13, 20, 28
Solution Proposed by the Submitter 3) Make the following additions and changes.

Page 13,
Person Object:

  • Renumber the "Extension" element as 2.11
  • Insert the "DataSource" element before Extension, as follows: - No - "2.10"-
    Name - "DataSource"-
    Explanation - "An identifier of the source system for the person object"-
    Reqd - "O"-
    Mult - blank-
    Domain - blank-
    Type - "ID String 256"-
    Note - "Used to identify the source system for the data object. Allows more than one source system to provide objects in the same file of data objects."-
    Example - blank

    Page 20,
    Group Object:

  • Renumber the "Extension" element as 3.12
  • Insert the "DataSource" element before Extension, as follows:- No - "3.11" -
    Name - "DataSource"-
    Explanation - "An identifier of the source system for the group object"-
    Reqd - "O"-
    Mult - blank-
    Domain - blank-
    Type - "ID String 256"-
    Note - "Used to identify the source system for the data object. Allows more than one source system to provide objects in the same file of data objects."-
    Example - blank

    Page 28, Group Membership Object:

  • Renumber the "Extension" element as 4.2.3.12
  • Insert the "DataSource" element before Extension, as follows:- No - "4.2.3.11" -
    Name - "DataSource"-
    Explanation - "An identifier of the source system for the membership object."-
    Reqd - "O"-
    Mult - blank-
    Domain - blank-
    Type - "ID String 256"-
    Note - "Used to identify the source system for the data object. Allows more than one source system to provide objects in the same file of data objects. Note that this is specified at the role level."-
    Example - "For example, Student roles could come from one source system, and Learner roles could come from another source system, and both be transmitted in the same file of data objects."

About this Document

Title IMS Enterprise Information Model
Authors Geoff Collier, Wayne Veres
Version 1.01
Version Date December 21, 1999
Status Final
Summary This document describes the IMS Enterprise Information Model which is used to support process interoperability between Learning Management Systems and Enterprise systems such as corporate human resources management, student administration, and library management systems..
Revision Information Last revised December 21, 1999
Document Location http://www.imsproject.org/enterprise/eninfo03.pdf

 

 

 

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.imsproject.org

Please refer to Document Name:
IMS Enterprise Information Model v1.01 Revision: December 1999