 |
1EdTech Enterprise Best Practice and Implementation Guide
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 Best Practice and Implementation Guide v1.01
Revision: December 1999
IPR and Distribution Notices
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
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
Purpose
Corporations, schools, government agencies, and software vendors have a major investment in their systems for Training Administration, Human Resource Management, Student Administration, Financial Management, Library Management and many other functions. They also have existing infrastructure and systems for managing access to electronic resources. To be effective and efficient, Instructional Management systems need to operate as an integrated part of this Enterprise system environment.
The objective of the 1EdTech Enterprise specification documents is to define a standardized set of structures that can be used to exchange data between different systems. These structures provide the basis for standardized data bindings that allow software developers and implementers to create Instructional Management processes that interoperate across systems developed independently by various software developers.
Scope
The scope of information included in this version of the specification is intended to support interoperability between Learning Management systems (LMS) and the following classes of Enterprise Systems:
- 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 1EdTech 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 1EdTech 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 1EdTech Enterprise Information Model is designed to support interoperability of the following four business process components, which typically require interaction between Learning Management systems and these types of Enterprise systems:
Personal Profile Data Maintenance
Typically, data about people is maintained in the Enterprise systems, and is passed to the Learning Management environment. When this personal profile data changes in the Enterprise system, it needs to be updated in the Learning Management system.
Group Management
Group management processes can include data from class creation and class scheduling, and the ongoing maintenance of that data. A source system creates and maintains group information, which needs to be shared with other systems that are involved with group management functions. The flow of group management information is not necessarily one way; some data may be updated by a target system and passed back to the source system.
Enrollment Management
Enrollment management encompasses the initial creation of Group membership and various changes to that data over time. Examples of enrollment management include learner enrollment in courses and instructor assignment to courses.
Final Result Processing
Final result processing refers to the evaluation and recording of final group membership results (final grade, course completion, etc.). This processing can occur in the Learning Management systems or in the Enterprise system.
Markets
The 1EdTech Enterprise system interoperability standards are intended to serve all organizations involved in the development and delivery of education and training using Internet-based technology. These organizations include:
- corporate and training departments;
- military and government agency training;
- primary and secondary education;
- universities;
- community, junior, and vocational colleges
.
The specifications are intended to meet the need of these organizations in all parts of the world.
The primary constituents for these specifications are organizations involved in the development of management component of Internet-based Instructional Management systems, or in the development of other systems that need to interoperate with Instructional Management systems.
Requirements
No assumptions regarding Data Ownership and Distribution of Functions
The specifications do not define a unified system architecture. The distribution of functions and data ownership between various systems will vary widely between industries, software vendors, and individual organizations. Class enrollment may occur in a Student Administration system at a particular university, in a training management component of a Human Resources system at a specific company, or in the Internet-based Instructional Management system at another company. These are architectural and systems integration decisions that will be made on a site-by-site and system-by-system basis.
Allow any type of Publish / Subscribe and Query / Response Protocol - Synchronous or Asynchronous
Some system architectures will support a synchronous Query / Response interaction where a consumer system makes a request for data and waits for a synchronous response message from a source system before proceeding to the next step of a process. Other systems will generate a query, and an asynchronous response will be received from the source system at some point in the future.
Some system architectures will be better served by a Publish / Subscribe interaction. This interaction happens when the source system publishes a message every time a particular event occurs. Then, the consumer system chooses which messages they subscribe to, and the timing with which they read the messages. This specification supports any of these messaging architectures.
Define Core Messages with Minimal Required Data
The data structures define a minimal set of data that is required to support basic interoperability. This allows a consistent specification to be widely adopted across various industries, countries, and systems. If the core structures were defined too "richly", they would have to specify data elements and vocabularies that are limited to particular industries or countries.
Support Extensibility
The core information structures define only the most basic data needed to support interoperation. However, there will be a need to extend these basic transactions to fully support the requirements of specific industries and countries. Different vendors will form partnerships to support tighter, richer integration and they must be able to develop extensions to the standard transactions. Also, different industries will develop extended message schemas for specific purposes. Therefore, the 1EdTech Enterprise Information Model provides support for this extensibility recognizing that it is a critical requirement for a meaningful standard.
Scalability
The data structure and binding specification can support any scale of implementation. Groups using these specifications must consider the scalability requirements of their solution, and design it to allow processes to perform effectively and in a timely manner for whatever scale of implementation they are intending to support. This may include partitioning the passing of data objects between systems into smaller "chunks" to avoid passing massive XML objects.
Security Considerations
This specification describes a data format standard for interoperability among systems within an enterprise or within an administrative domain of an enterprise. Some data items are often associated with authentication (e.g. UserID) and/or authorization (e.g.Role). Some data items (e.g. Demographics) may have privacy regulations imposed by government or other organizations external to the Enterprise. As a result, an entire data stream based on this specification may be considered sensitive even within the same enterprise or administrative domain. The sensitivity of the entire data stream is the sensitivity level of the most sensitive data element within the stream.
Enterprise and/or domain data administrators should apply the appropriate security measures in the storage and transfer of information represented according to this specification. Appropriate security measures are determined by the privacy requirements of the information, the threats to the confidentiality of the information, and the liability of the Enterprise should confidentiality be compromised. Appropriate security measures may include cryptographic techniques for confidentiality and integrity, and mutual authentication between parties in a data transfer.
Related 1EdTech Documents
Version 1.0 of the 1EdTech Enterprise Interoperability specification is made up of three documents:
- "1EdTech Enterprise Interoperability Best Practices and Implementation Guide - Version 1.0" (The document you are reading). This document provides an overview and describes how the 1EdTech Enterprise Information Model and XML Binding specifications can be applied to specific types of interoperability scenarios.
- "1EdTech Enterprise Information Model - Version 1.0" This document describes the data structures that are used to provide interoperability of Internet-based Instructional Management systems with other systems that are used to support the operations of an organization.
- "1EdTech Enterprise XML Binding - Version 1.0" This document describes how to encode the Enterprise information objects in XML and provides an XML DTD.
Related Initiatives
The 1EdTech Enterprise Interoperability specification is related to several other 1EdTech specifications, both complete and in progress. This specification is intended to be consistent with these other initiatives wherever possible, in order to reduce redundancy and confusion between specifications.
Related 1EdTech Initiatives
1EdTech Meta-data Specification
The 1EdTech Enterprise specification shares a number of common data object elements with the 1EdTech Meta-data specification. They are consistent where appropriate.
1EdTech Profile Specification
The 1EdTech Enterprise specification shares a common data model with the upcoming 1EdTech Profile Specification. The 1EdTech Enterprise Interoperability data model should be a subset of the larger Profile data model.
Other Specification Initiatives
Mappings between the 1EdTech Enterprise Information Model and these other initiatives will be provided as appropriate in future versions of the 1EdTech Enterprise Best Practice and Implementation Guide.
ANSI X12 - TS 130
This is the Student Educational Record (transcript) as defined by the Speede/Express group. It is a well-developed standard that is intended to support the Electronic Data Interchange (EDI) sharing of full student transcripts between North American institutions.
Gestalt Initiative
Gestalt, building on the work done in the PAPI specification is defining a more extensive Personal Profile model that supports the exchange of data within and across institutions.
IEEE 1484.8 Enterprise Interfaces SG
There is an IEEE 1484 subcommittee tasked with the development of Enterprise Interoperability standards for learning systems. 1EdTech will submit this specification to that group for consideration as the basis for their specification.
IEEE 1484.2 Learning Model WG
There is an IEEE 1484 subcommittee tasked with the development of a Learning Profile standard for learning systems. The PAPI model is being used as the basis for the development of this standard, and 1EdTech will continue to track this initiative looking for opportunities to synchronize standards whenever possible.
Schools Interoperability Framework (K-12)
This initiative is developing standards for the interoperability of administrative systems for North American K-12 schools and districts. The market focus and scope of systems considered is different than the 1EdTech Enterprise Interoperability specification, but 1EdTech will continue to track this initiative looking for opportunities to synchronize standards whenever possible.
California Schools Information System Project
This initiative is developing standards for the interchange of data between California K-12 schools as well as between these schools and the state department of education. The group is currently working on a data exchange and state reporting. The project is also considering standards for the exchange of data between California K-12 and higher education institutions. (www.csis.k12.ca.us)
Directory Services Markup Language (DSML)
DMSL is comprised of a broad consortium of vendors working to develop an XML binding for directory services products. Directory services product track data about people and groups, so they deal with some of the same data addressed by the 1EdTech Enterprise specification. (www.dsml.org)
Specification Development Process
Specifications are the core deliverable of 1EdTech. The publicly released 1EdTech Meta-data specification is the first in an evolving series of specifications to define the Internet architecture for learning. The 1EdTech Enterprise specification is the second publicly released specification from 1EdTech.
Within 1EdTech, the specification development process begins with a scope document that bounds the interoperability functionality supported by the specification. The scope document is recommended by the 1EdTech Technical Board, which includes representatives from developers and users from around the world.
A draft specification is developed within the 1EdTech developer and user community, which currently includes more than 200 organizations from around the world. In a number of cases, one of these organizations represents many other organizations, such as the Australian Government's DETYA organization, which provides access to the 1EdTech community for all institutions of learning in Australia.
Work teams with full-time 1EdTech technical staff and volunteers from the 1EdTech developer and user community meet in face-to-face and virtual meetings to develop draft specifications, which are formulated from white papers, proposals, and other document fragments.
The term "Base document" is used for draft specifications that have reached a relatively high level of stability based on input from the team and the Technical Board. Base documents represent the stage in the specification process of final development and refinement. It is base documents that are presented in their final form to the 1EdTech Technical Board for vote. If approved, the document becomes a final specification and is listed as such on the 1EdTech public web site. If not approved, the team works through whatever adjustments and recommendations the Technical Board provides, and then resubmits the document.
After a final specification is released, the team develops the next scope document for subsequent work. New requirements and features dropped from the previous specification constitute the scope of the next effort.
Overall Data Model
The following diagram provides a conceptual overview of the 1EdTech Enterprise Interoperability data model.
DATA OBJECTS:
This model is supported through the use of three data objects, described briefly below:
Group - This object contains elements describing a group of interest to the Learning Management environment. There are many types of groups that may be shared between systems. The most common is a Course Instance, but they may also include Training Programs, Academic Programs, Course sub-groups, clubs, etc. A group can also have any number of relationships with other groups.
Group Membership - This data object contains elements describing the membership of a person or group within a group. Group members may be instructors, learners, content developers, members, managers, mentors, or administrators.
Person - This data object contains elements describing an individual of interest to the Learning Management environment.
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.
1EdTech Enterprise Elements and Structure
1 Properties
1.1 DataSource 1.2 Target 1.3 Type 1.4 Datetime 1.5 Language 1.6 Extension
2 Person
2.1 SourcedID 2.1.1 Source 2.1.2 ID 2.2 RecStatus 2.3 UserID 2.4 Name 2.4.1 FN 2.4.2 Sort 2.4.3 Nickname 2.4.4 N 2.4.4.1 Family 2.4.4.2 Given 2.4.4.3 Other 2.4.4.4 Prefix 2.4.4.5 Suffix 2.5 Demographics 2.5.1 Gender 2.5.2 BDay 2.6 Email 2.7 Tel 2.7.1 TelType 2.7.2 TelNum 2.8 Adr 2.8.1 POBox 2.8.2 ExtAdd 2.8.3 Street 2.8.4 Locality 2.8.5 Region 2.8.6 PCode 2.8.7 Country 2.9 Photo 2.9.1 ExtRef 2.9.2 ImgTyp 2.10 DataSource 2.11 Extension
3 Group
3.1 SourcedID 3.1.1 Source 3.1.2 ID 3.2 RecStatus 3.3 GroupType 3.3.1 Scheme 3.3.2 TypeValue 3.3.2.1 Level 3.3.2.2 Value 3.4 Description 3.4.1 Short 3.4.2 Long 3.4.3 Full 3.5 Org 3.5.1 OrgName 3.5.2 OrgUnit 3.5.3 Type 3.5.4 ID 3.6 TimeFrame 3.6.1 Begin 3.6.1.1 Date 3.6.1.2 Restrict 3.6.2 End 3.6.2.1 Date 3.6.2.2 Restrict 3.6.3 AdminPeriod 3.7 EnrollControl 3.7.1 EnrollAccept 3.7.2 EnrollAllowed 3.8 EMail 3.9 URL 3.10 Relationship 3.10.1 SourcedID 3.10.1.1 Source 3.10.1.2 ID 3.10.2 Label 3.10.3 Relation 3.11 DataSource 3.12 Extension
4 Membership
4.1 SourcedID 4.1.1 Source 4.1.2 ID 4.2 Member 4.2.1 SourcedID 4.2.1.1 Source 4.2.1.2 ID 4.2.2 IDType 4.2.3 Role 4.2.3.1 RoleType 4.2.3.2 SubRole 4.2.3.3 Status 4.2.3.4 RecStatus 4.2.3.5 UserID 4.2.3.6 Comments 4.2.3.7 Date 4.2.3.8 Timeframe 4.2.3.8.1 Begin 4.2.3.8.1.1 Date 4.2.3.8.1.2 Restrict 4.2.3.8.2 End 4.2.3.8.2.1 Date 4.2.3.8.2.2 Restrict 4.2.3.9 Final result 4.2.3.9.1 Mode 4.2.3.9.2 Values 4.2.3.9.2.1 ValueType 4.2.3.9.2.2 List 4.2.3.9.2.3 Min 4.2.3.9.2.4 Max 4.2.3.9.3 Result 4.2.3.9.4 Comments 4.2.3.10 Email 4.2.3.11 DataSource 4.2.3.12 Extension
Implementation Notes
Tracking Group Identifier Across Systems
Target systems need to be capable of storing the source system's "Group Identifier".
It is possible to have a viable interface without automatically exchanging Group data. This means that one or the other systems involved in an interface must store the other system's Group Identifier in order to support the passing of Group membership data. In this case, the responsibility for storing the Group ID falls on the system that will act as the source for Person and Group Membership data. The implication is that if Group data is not automatically being passed between systems, then it is being created in both systems independently. In this situation the Group ID of one system needs to be entered into the relevant record in the other system, otherwise an interface cannot occur between the two systems. This process may be manual or automated. Discussions to date have indicated that this model may be followed by many organizations.
Assigning Group Membership Role Type
RoleType is a mandatory element in the Group Membership object (element 4.2.2.1) that has a defined set of domain values. This means that only those values defined in the domain can be used for this element. Recognizing that no defined list of roles can ever be absolutely complete; the optional element SubRole can be used to further qualify a person's role in a group.
It is essential to have a defined list of values for the mandatory RoleType element so source systems can generate standard Group Membership data objects that target systems can process without having to first negotiate the meaning of RoleTypes with the source system. To help developers understand what meaning is embedded in each of the RoleType values, the following table shows the Learning Management System functions that each RoleType will typically have access to. This is not intended to be a precise and exclusive list of all functions that these roles will have access to in all Learning Management Systems. Rather, it is provided as an interpretive guide intended to communicate the meaning the developers of the specification had in mind for each role. In addition, access to these functions will be less for some subroles. For example, a supervisor may be a subrole for a manager, and a supervisor will likely not have access to results for the people they supervise.
In any particular implementation or in any specific vendor's product, the Instructor role and the Administrator role will frequently have several subroles.
Interface Architectures
The 1EdTech Enterprise Information Model and XML Binding specification are intended to support either the "Snapshot" or Event Driven interface types discussed below:
The "Snapshot" Interface
The 1EdTech Enterprise team's consensus is that the most robust and easily implementable interface would involve the passing of a complete "snapshot" of the Person, Group, and Group Membership data. The target system would examine this snapshot to determine what changes had occurred. This very basic type of interface allows a receiving system to pick up an interface at any time and synchronize its data with the source system-- regardless of how many interfaces had been passed in the interim. A purely event driven "transactional" interface, on the other hand, cannot tolerate any loss or skipping of interface records.
This basic interface also allows the target system to implement many different strategies for dealing with the interface data. Taking a "snapshot" means that the full set of relevant data from the source system can be moved to the target system environment on any timing needed to support the business processes.
This interface architecture has the advantage of being very tolerant of lost messages or missed data objects because the next transmittal will always get the target system back in synchronization with the source system. However, the major drawback is that the target system can never be sure that the data has not changed in the source system since the last snapshot was received. Also, this interface architecture does not effectively support two-way interfaces. In a two-way interface, data object maintenance occurs in both systems, and the data objects are passed in both directions.
Event Driven Interface
In an event driven interface, the source system publishes data object messages when events occur. This changes the relevant data, and the target system receives and processes the event transactions.
The existence of an event driven interface does not eliminate the usefulness of the "snapshot" interface. Because an event driven interface is not tolerant of missed transactions, the "snapshot" interface can be used at regular intervals to "re-synchronize" the data in the target system with that in the source system. This increases the fault tolerance of the overall interface architecture.
Usage Scenarios
This section describes some scenarios where the 1EdTech Enterprise Information Model and the 1EdTech Enterprise XML Binding Specification can be applied.
This is not intended to be a complete list of scenarios, nor is there any implication that these scenarios describe the best method for designing an interface between systems. It is expected that this section will expand extensively over time as organizations gain experience implementing the specification in various scenarios.
General Scenarios
The following list describes some types of systems for which the 1EdTech Enterprise specification may support Learning Management interoperability. It includes a list of some interfaces that the current specification can support.
Human Resource Management System
Human Resource Management Systems (HRMS) manage personnel records, payroll, benefits, competency management, and other functions for an enterprise. Interoperability that can be supported by this specification include:
From HRMS to LMS:
- Person data maintained in the HRMS and passed to the LMS.
- HR departments passed as groups, and employees of those departments passed as members.
- Special groups of employees (new hires for example) passed to the LMS as training groups.
From LMS to HRMS:
- After the completion of training courses, course information return to the HRMS as groups, and completion of training courses, - could come back as membership in those groups, with result information included.
Corporate Training Management System
Corporate Training Administration systems keep track of employee training plans, schedule training courses (including instructors and resources), enroll people in training, record training completed, and update employee competencies in an HRMS. They are also used to manage training delivered to customers. Interoperability that can be supported by this specification include:
From Training to LMS:
- Person data might be passed to the LMS from the training system .
- Training groups (courses) and memberships could be passed from training to the LMS.
From LMS to Training:
- After the completion of training courses, membership objects could be sent to the Training Administration system from the LMS with result (completion) information included.
Student Administration System
Student Administration systems (SA) keep track of student education plans, schedule courses (including instructors and resources), enroll people in courses, record course results, and update student academic progress. Interoperability that can be supported by this specification include:
From SA to LMS:
- Person data for people enrolled in groups that are managed by the LMS.
- Group data could be passed from SA to the LMS to create the groups.
- Group membership (course enrollment) data may be passed from SA to the LMS.
- Final grade information may be passed to the LMS from the SA in an updated Membership object if final grading occurs in the SA, and the LMS needs the final grade for its records.
From LMS to SA:
- Final grades could be returned to SA from the LMS by passing back Membership records with the Result data provided. This data could then be entered into a formal grade roster process on the SA side.
Library Management System
Library Management systems can be thought of as a particular class of Learning Management system, in that they provide a set of services for managing the interaction of learners with learning objects. Therefore, it is appropriate to use this specification to support interfaces from other enterprise systems to Library Management systems in much the same way that these interfaces are supported with Learning Management Systems.
From SA or HRMS to Library:
- People data.
- Groups (course sections for access to specific material, HR departments for access to services, alumni for access to limited services, etc.)
- Group membership.
Enterprise Element to LDAP Attribute Mapping
Most enterprise systems utilize a directory to store organizational and person information. Many directories use the Lightweight Directory Access Protocol (LDAP) to store this data and make it accessible to other Enterprise applications. It is likely that Learning Management Systems will use some of the data in an LDAP directory to populate equivalent fields in the 1EdTech Enterprise XML binding.
The table below represents a preliminary mapping between LDAP base schema items and 1EdTech Enterprise elements. This is provided only as an example. The reader who wishes to incorporate LDAP data into learning management applications is encouraged to consult authoritative sources regarding LDAP.
Guidance for Very Specific Scenarios
Cross-Listed Course Sections
Cross-Listed course sections are a fairly common scenario in higher education. A Cross-Listed course section refers to a situation where the same course is offered under more than one name. This is typically done because different groups of students will enroll in different sections based on the program they are studying. For example, Statistics 101 section 1 and Psychology 101 section 1 are really the same course section, offered by the same instructor, meeting at the same time and place (physical or virtual), using the same course materials. The only difference is that Math students enroll in Statistics 101, and Psychology students enroll in Psychology 101. A problem arises in this situation when the Enterprise system treats these sections as separate groups. In the Learning Management System, they need to be treated as a single group, or at least the LMS needs to know they are related.
One approach is to resolve this in the source system before passing Groups and Memberships over to the target system. In other words, a single group (perhaps called "Introductory Statistics", without the Math or Psychology designator) would be created in the Learning Management System and membership from both groups in the Enterprise system would be passed to this single group in the LMS.
Another approach is to pass two separate groups to the target system, but relate them to each other through the use of the Relationship element. In this case, the two groups could be tagged as follows in the Relationship element:
Sourced ID - The ID of the cross-listed course section in the source system.
Label - Would contain something like "Cross Listed Section"
Relation - Would contain "3" (also known as)
In general, the best practice would be to resolve the issue in the source system, before passing the group and membership data to the target system, but there may be cases where the second approach is required.
Single File from Multiple Systems
During Integration engagements conducted by Blackboard in the Summer and Fall of 1999, it was determined that some institutions might store certain objects in multiple systems. The current version of the 1EdTech Enterprise Information Model (1.0) handles this situation if the file are sent separately from each system and the system is identified by the DataSource attribute in Properties. However, Blackboard found that some institutions preferred to produce one file and send that to Blackboard CourseInfo Enterprise. In this case a DataSource attribute at the file level is not sufficient.
It is recommended that the 1EdTech Enterprise Information Model change to include a DataSource element for People, Groups and Group Membership. The element would be at the top level for People and Groups, but off Role for Group Membership.
This DataSource element identifies the system from which the record (object) came. While the Source off of SourcedID identifies the system that guarantees the uniqueness of the record.
For example, if we look at a People flat file containing two records:
| Tom, Scott, CSUM, Banner, 403-34-1234 Fred, Simpson, CSUM, People Soft, 502-12-4312 |
CSUM is the Source while Banner and People Soft are the DataSource. If you assume that one application (for example the SnapShot generator) generated the merge of the two systems data, the DataSource in Properties would be the "SnapShot Generator."
An example flow of a Blackboard integrated system:
A real life example of where this occurs is when an institution uses an SIS system to manage academic activities, but has another system to manage organizations.
By adding the additional DataSource as an element, integration vendors and institutions can track down where errors occurred and use DataSource, DataSource (from Properties) and Source to determine from which the data came while doing integration testing.
Conformance
Conformance to the 1EdTech Enterprise Information Model is defined for instances [data, files, documents] and for applications. Additional requirements may be included in binding specifications for this information model.
Instance Conformance
An 1EdTech Enterprise Information Model instance conforms if it satisfies the following seven requirements:
- The instance must contain all mandatory elements identified in the packaging and control data object. The elements must meet the multiplicity, domain, and type requirements.
- If the instance contains person data, the instance must contain all mandatory elements identified in the person data object. The elements must meet the multiplicity, domain, and type requirements.
- If the instance contains group data, the instance must contain all mandatory elements identified in the group data object. The elements must meet the multiplicity, domain, and type requirements.
- If the instance contains group membership data, the instance must contain all mandatory elements identified in the group membership data object. The elements must meet the multiplicity, domain, and type requirements.
- If an optional element is contained in the instance, then the instance must contain all mandatory elements that are a part of that optional element in the packaging and control data object, person data object, group data object, or group membership object.
- The instance may contain conditional elements in the packaging and control data object, person data object, group data object, or group membership object.
- The instance may contain extension elements, if the extensions meet the requirements of this specification.
Source Application Conformance
An application that acts as a source for one or more data objects conforms to the 1EdTech Enterprise Information Model if it satisfies the following requirement:
- A conforming source application must be able to write an instance of the mandatory elements of the packaging and control data object, and one or more of the person data object, group data object, or group membership object.
- The ability to write optional elements is desirable, but is not required.
Target Application Conformance
An application that acts as a target for one or more data objects conforms to the 1EdTech Enterprise Information Model if it satisfies the following requirement:
- A conforming target application must be able to read, process, and store an instance of the mandatory elements of the packaging and control data object, and one or more of the person data object, group data object, or group membership object.
- Optional element reading, processing, storage, and persistence is desirable, but is not required.
- Extension element reading, processing, storage, and persistence is not required.
Acknowledgements
Many people have contributed to the development of the 1EdTech Enterprise specification. 1EdTech wishes to thank Fred Beshears, Bill Young, Marty Gray, and John Barkley for their efforts in writing portions of this document.
Appendices
Additional resources
1EdTech Enterprise Documents
The 1EdTech Enterprise XML Binding Specification can be found at: http://www.imsproject.org/enterprise/enbind03.pdf
The 1EdTech Enterprise Information Model document can be found at: http://www.imsproject.org/enterprise/eninfo03.pdf
vCard Information
A variety of vCard related links can be found at: http://www.imc.org/pdi/
XML Resources
The XML specification and additional links can be found at: http://www.w3.org/XML/
Articles, software and many things related to XML can be found at:
http://www.xml.com/
Addendum
Changes to the v1.0 of the 1EdTech Enterprise Best Practices and Implementation Guide are as follows:
| Type of Problem | Addition |
| Date | December 14, 1999 |
| Problem Description | DataSource is needed in the Person, Group and Membership objects, not just in the Properties object. This allows a single file to contain objects from more than one source system, and allows the target system to track the source of the objects for future reference back.This change is being made in the Information Model, and must also be made in the Best Practice and Implementation Guide. |
| References in Document | Best Practice and Implementation Guide - 1EdTech Enterprise Elements and Structure section |
| Solution Proposed by the Submitter | 1) Make the following additions and changes.
Person Object:
Group Object:
Membership Object:
|
| Type of Problem | Addition | |
|---|---|---|
| Date | December 14, 1999 | |
| Problem Description | DataSource is needed in the Person, Group and Membership objects, not just in the Properties object. This allows a single file to contain objects from more than one source system, and allows the target system to track the source of the objects for future reference back. | |
| References in Document | Best Practice and Implementation Guide - Guidance for Very Specific Scenarios | |
| Solution Proposed by the Submitter | 2) Add a new subsection to this section that describes a scenario on how the DataSource and Source fields should be used when passing objects from multiple systems. This scenario is provided by Blackboard based on real world 1EdTech implementation experience. See text below for contents of new section. | |
| GUIDANCE FOR VERY SPECIFIC SCENARIOS
Single File from Multiple Systems It is recommended that the 1EdTech Enterprise Information Model change to include a DataSource element for People, Groups and Group Membership. The element would be at the top level for People and Groups, but off Role for Group Membership. This DataSource element identifies the system from which the record (object) came. While the Source off of SourcedID identifies the system that guarantees the uniqueness of the record. For example, if we look at a People flat file containing two records:
CSUM is the Source while Banner and People Soft are the DataSource. If you assume that one application (for example the SnapShot generator) generated the merge of the two systems data, the DataSource in Properties would be the "SnapShot Generator." An example flow of a Blackboard integrated system: A real life example of where this occurs is when an institution uses an SIS system to manage academic activities, but has another system to manage organizations. By adding the additional DataSource as an element, integration vendors and institutions can track down where errors occurred and use DataSource, DataSource (from Properties) and Source to determine from which the data came while doing integration testing. |
||
About this Document
| Title | 1EdTech Enterprise Best Practice and Implementation Guide |
| Authors | Geoff Collier, Wayne Veres, Thor Anderson |
| Version | 1.01 |
| Version Date | December 21, 1999 |
| Status | Final |
| Summary | This document provides additional information regarding 1EdTech Enterprise Specification Best Practices and Implementation guidelines. It is meant to complement the 1EdTech Enterprise XML Binding and 1EdTech Enterprise Information Model documents. |
| Revision Information | Last revised December 21, 1999 |
| Document Location | http://www.imsproject.org/enterprise/enbest03.pdf |
1EdTech Consortium, Inc. (“1EdTech”) is publishing the information contained in this 1EdTech Enterprise Best Practice Guide (“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 Best Practice v1.01 Revision: December 1999
