 |
1EdTech Enterprise Information Model
Version 1.01 - Final Specification |
Copyright © 1999 1EdTech Consortium, Inc. All Rights Reserved.
The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name: 1EdTech 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.
1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © 1999 1EdTech Consortium. All Rights Reserved.
Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
Introduction
The 1EdTech 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 1EdTech 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 1EdTech Enterprise specification is focused on defining interoperability between systems residing within the same enterprise or organization. The documents comprising the 1EdTech 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 1EdTech Enterprise Interoperability 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 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 1EdTech 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 1EdTech 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 |
||
| 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 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 1EdTech 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,
|
About this Document
| Title | 1EdTech Enterprise Information Model |
| Authors | Geoff Collier, Wayne Veres |
| Version | 1.01 |
| Version Date | December 21, 1999 |
| Status | Final |
| Summary | This document describes the 1EdTech 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 |
1EdTech Consortium, Inc. (“1EdTech”) is publishing the information contained in this 1EdTech Enterprise Information Model (“Specification”) for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an “As Is” and “As Available” basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
1EdTech would appreciate receiving your comments and suggestions.
Please contact 1EdTech through our website at http://www.imsproject.org
Please refer to Document Name: 1EdTech Enterprise Information Model v1.01 Revision: December 1999
