IMS Logo IMS Learner Information Packaging Information Model Specification

Final Specification
Version 1.0

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

The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name:
IMS Learner Information Packaging Information Model Specification v1.0
Revision: 9 March 2001

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

If you wish to copy or distribute this document, you must complete a valid Registered User license registration with IMS and receive an email from IMS granting the license to distribute the specification. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.

This document may be copied and furnished to others by Registered Users who have registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS project group.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.



Table of Contents


ABOUT THIS DOCUMENT
LIST OF CONTRIBUTORS
REVISION HISTORY
1. INTRODUCTION
1.1 IMS LEARNER INFORMATION SPECIFICATIONS OVERVIEW
1.1.1 Requirements
1.1.2 Learner Information Data and Meta-data
1.1.3 Learner Data Structure
1.1.4 Learner Information Meta-data
1.2 SCOPE & CONTEXT
1.3 STRUCTURE OF THIS DOCUMENT
1.4 LIST OF ABBREVIATIONS
1.5 REFERENCED DOCUMENTS
2. LEARNER INFORMATION SYSTEMS
2.1 A SYSTEM
2.2 LEARNER INFORMATION
2.3 CATEGORIES OF LEARNER INFORMATION
3. USE-CASES
3.1 INDIVIDUAL PERSPECTIVE
3.2 VENDOR PERSPECTIVE
3.2.1 Perspective of a Vendor of a Human Resource Management System (HRMS)
3.2.2 Perspective of a Vendor of a Student Administration System
3.3 UK HIGHER EDUCATION (INTER-ORGANISATIONAL)
3.3.1 Stakeholders and Potential Benefits
3.3.2 A Life-cycle Scenario
3.4 CAREER MANAGEMENT
3.4.1 Portfolio Data
3.4.2 Actors
3.5 TRAINING GROUP MANAGEMENT
4. BASIC INFORMATION MODEL
4.1 LEARNER INFORMATION PACKAGE
4.2 LEARNER INFORMATION EXCHANGE
4.3 LEARNER INFORMATION QUERY
5. PACKAGING LEARNER INFORMATION
5.1 CORE DATA STRUCTURES
5.2 DISTRIBUTED SYSTEMS
5.3 SCALABILITY
5.4 PRIVACY & DATA PROTECTION
5.4.1 Privacy and Data Protection Meta-structure
5.4.2 Learner Security Keys
6. CONCEPTUAL DESCRIPTION OF THE DATA OBJECTS
6.1 UNDERLYING STRUCTURE OF THE LEARNER INFORMATION
6.2 EXTENSIONS & EXTENSIBILITY
6.3 LEARNER INFORMATION PACKAGING TABULAR DESCRIPTION
6.3.1 Learner Information Packaging Data Objects
6.3.2 'identification' Data Structure
6.3.3 'accessibility' Data Structure
6.3.4 'goal' Data Structure
6.3.5 'qcl' Data Structure
6.3.6 'activity' Data Structure
6.3.7 'competency' Data Structure
6.3.8 'interest' Data Structure
6.3.9 'affiliation' Data Structure
6.3.10 'transcript' Data Structure
6.3.11 'securitykey' Data Structure
6.3.12 'relationship' Data Structure
6.3.13 Common Data Objects
6.3.14 'extension' Definitions
7. IMS SUPPORTED LIP VOCABULARIES & TAXONOMIES
8. META-DATA DESCRIPTIONS
8.1 IMS META-DATA INCLUSION
9. CONFORMANCE
9.1 VALID DATA ISSUES
9.2 CONFORMANCE STATEMENT
9.2.1 Learnerinformation Conformance Statement Table
9.2.2 Accessibility Conformance Statement Table
9.2.3 Activity Conformance Statement Table
9.2.4 Affiliation Conformance Statement Table
9.2.5 Competency Conformance Statement Table
9.2.6 Goal Conformance Statement Table
9.2.7 Identification Conformance Statement Table
9.2.8 Interest Conformance Statement Table
9.2.9 Qcl Conformance Statement Table
9.2.10 Relationship Conformance Statement Table
9.2.11 Securitykey Conformance Statement Table
9.2.12 Transcript Conformance Statement Table
APPENDIX A - OBJECT MODEL REPRESENTATION

List of Figures

Figure 1.1 The IMS Learner Information Packaging (LIP) core data structures.
Figure 2.1 Learner information system component representation.
Figure 4.1 The principle LIP data structure.
Figure 5.1 The schematic representation for learner profile information.
Figure 5.2 Distributed learner information referencing.
Figure 6.1 The primary elements of the LIP data structures.
Figure A1 Object oriented representation of the LIP specification.

List of Tables

Table 2.1 Learner information general categories.
Table 6.1 Learner information package data objects detailed description.
Table 6.2 'identification' learner information data structure detailed description.
Table 6.3 'accessibility' learner information data structure detailed description.
Table 6.4 'goal' learner information data structure detailed description.
Table 6.5 'qcl' learner information data structure detailed description.
Table 6.6 'activity' learner information data structure detailed description.
Table 6.7 'competency' learner information data structure detailed description.
Table 6.8 'interest' learner information data structure detailed description.
Table 6.9 'affiliation' learner information data structure detailed description.
Table 6.10 'transcript' learner information data structure detailed description.
Table 6.11 'securitykey' learner information data structure detailed description.
Table 6.12 'relationship' learner information data structure detailed description.
Table 6.13 Common data objects detailed description.
Table 6.14 List of extensions.
Table 7 'typename' list of vocabularies.
Table 9.1 Learnerinformation conformance statement table.
Table 9.2 Accessibility conformance statement table.
Table 9.3 Activity conformance statement table.
Table 9.4 Affiliation conformance statement table.
Table 9.5 Competency conformance statement table.
Table 9.6 Goal conformance statement table.
Table 9.7 Identification conformance statement table.
Table 9.8 Interest conformance statement table.
Table 9.9 Qcl conformance statement table.
Table 9.10 Relationship conformance statement table.
Table 9.11 Securitykey conformance statement table.
Table 9.12 Transcript conformance statement table.

1.     Introduction

1.1     IMS Learner Information Specifications Overview

IMS Learner Information Package is based on a data model that describes those characteristics of a learner needed for the general purposes of:

The specification supports the exchange of learner information among learning management systems, human resource systems, student information systems, enterprise e-learning systems, knowledge management systems, resume repositories, and other systems used in the learning process. In this document such systems will be called learner information systems regardless of any other functionality they possess or roles they fulfil.  The IMS Learner Information Package specification does not address requests for learner information or the exchange transaction mechanism.

1.1.1       Requirements

IMS Learner Information specifications are designed to meet the following requirements:

Privacy and Data Protection

The IMS project recognizes the need to:

IMS Learner Information Package enables the inclusion of mechanisms for maintaining privacy and protecting the integrity of data with all data that comprises learner information.  The specification cannot, however, specify the form, format, or type of these mechanisms or policies for their use. These must be determined by specific implementations in accordance with their requirements.

1.1.2       Learner Information Data and Meta-data

IMS Learner Information Package is a structured information model. An XML binding is included but is not meant to exclude other bindings.  The information model contains both data and meta-data about that data. The model defines fields into which the data can be placed and the type of data that may be put into these fields. Typical data might be the name of a learner, a course or training completed, a learning objective, a preference for a particular type of technology, and so on. Meta-data about each field can include:

This meta-data is available for each and every field in the information model, either directly or via inheritance.

1.1.3       Learner Data Structure

The learner information model can be viewed in three different ways:

All three ways are explained in the specification.  The Learner information is separated into eleven main categories (as shown in Figure 1.1).  These structures have been identified as the primary data structures that are required to support learner information.  This composite approach means that only the required information needs to be packaged and stored.

The IMS Learner Information Package core data structures.

Figure 1.1  The IMS Learner Information Package (LIP) core data structures.

These categories were chosen to meet the requirements of a large variety of use cases and to facilitate mapping among IMS and other relevant specifications.  Within each category several data elements and structures are defined.  Some of these are specified explicitly as data types (language strings, for the most part) and others are defined as recursive hierarchical structures.  In addition, data may be defined by referencing mechanisms. The referencing mechanisms supported are internal references, references to an external learner information system, and references via a URI.

1.1.4       Learner Information Meta-data

The learning information meta-data (contained within the ‘contentype’ structure shown in Figure 1.1) is broken into four categories:

All learning information data elements have meta-data sub-elements with the exception of atomic elements that can always inherit their meta-data. For example, in the Identification category, meta-data is associated with the Name element but not with its constituent elements since it is felt that the meta-data for the constituent elements cannot change independently of the meta-data for the Name element itself.

1.2     Scope & Context

This document is the IMS Learner Information Package (LIP) Information Model Final Specification.  As such it will be used as the basis for the production of the following documents:

This requirement has been derived from the agreed IMS Learner Information Packaging Requirement Specification [LIP, 00a].  As will be seen from this information model there is overlap with the IMS Enterprise specifications [Enterprise, 99a], [Enterprise, 99b], [Enterprise, 99c].  However, it is the intention that these two sets of specifications are complementary and as such the LIP specifications do not supersede or replace the Enterprise specifications.  The issue of harmonisation is addressed within the IMS LIP Best Practice & Implementation Guide.

At some point in the future a Version 2.0 of the Information Model will be developed.  That version will extend the functions and capabilities of version 1.0 but will be backwards compatible except for those areas identified for further study.

1.3     Structure of this Document

The structure of the rest of this document is:

2.     Learner Information System:

The definition and scoping of learner information and a learner information system with respect to this IMS specification;

3.     Use-cases:

The underlying usage, processing control and data structures comprising the learner information packaging system;

4.     Basic Information Model:

The underlying learner information package information model;

5.     Packaging Learner Information

The mechanism used to package learner information data to be exchanged between two or more learner information entities;

6.     Conceptual Description of the Data Objects:

The detailed description of the learner information package data objects in terms of their elements, sub-elements and attributes;

7.     IMS Supported LIP Vocabularies & Taxonomies

The definition and description of the vocabularies and taxonomies that are supported as default by IMS;

8.     Meta-data Descriptions:

The learner information meta-data descriptions;

9.     Conformance Statement:

The definition of Conformance to be used by vendors;

Appendix A - Object Model Representation

The object model for the learner information packaging information model.

1.4     List of Abbreviations

 
ANSI American National Standards Institute
CMA Career Account Management
CV Curriculum Vitae
DTD Document Type Definition
EDI Electronic Data Interchange
FE Further Education
GUI Generic User Interface
GUID Global User Identifier
HE Higher Education
HRMS Human Resource Management System
IEEE Institute of Electronic & Electrical Engineers
JPEG Joint Photographic Expert Group
LIP Learner Information Packaging
LIQ Learner Information Querying
LIX Learner Information Exchange
LLL Life-long Learning
LOM Learning Object Meta-data
LTSC Learning Technology Standards Committee
NVC National Validation Center
PAPI Public & Private Information
QTI Question & Test Interoperability
SIF Schools Interoperability Framework
UCAS University Council for Admissions Services
UML Unified Modelling Language
URI  Universal Resource Identifier
XML Extensible Mark-up Language

1.5     Referenced Documents

[ANSI, 98] Student Educational Record (Transcript), ANSI ASC X.12-TS130, ANSI, April 1998.

[CP, 00a]IMS Content Packaging Information Model, T.Anderson, W.Young, C.Moffatt, Version 1.0, IMS, May 2000.

[CP, 00b]IMS Content Packaging XML Binding, T.Anderson, W.Young, C.Moffatt, Version 1.0, IMS, May 2000.

[CP, 00c]IMS Content Packaging Best Practice and Implementation Guide, T.Anderson, W.Young, C.Moffatt, Version 1.0, IMS, May 2000.

[Enterprise, 99a]IMS Enterprise Information Model, G.Collier, W.Veres and T.Anderson, Version 1.01, IMS, December 1999.

[Enterprise, 99b]IMS Enterprise XML Binding, G.Collier, W.Veres and T.Anderson, Version 1.01, IMS, December 1999.

[Enterprise,99c]IMS Enterprise Best Practice and Implementation Guide, G.Collier, W.Veres and T.Anderson, Version 1.01, IMS, December 1999.

[Gestalt, 00]Gestalt: WP4 - Integrating IMS Enterprise, PAPI and Gestalt UOM Data Models, version 3.0, P.Foster, Gestalt Doc No: FC:/MAN/REPORTS/022GESTALT/D401/GestaltEnterprisePAPI_3, March 2000.

[Gestalt, 99]Gestalt: WP5 - Object (Interfaces) Specification, V.Wade, K.Riley, B.Banks, P.Foster, N.Evans-Mudie, Y.Nicol, P.Doherty, Gestalt Doc No: A367/TCD/WP05/DS/L/008/b1, October 1999.

[HR, 00a]Resume DTD, HR-XML Consortium, June 2000, http://www.hr-xml.org/.

[HR, 00b]Candidate DTD, HR-XML Consortium, June 2000, http://www.hr-xml.org/.

[LIP, 00a]Profiles Interchange Requirement Specification, G.Collier, T.Probart and C.Smythe, Version 1.0, IMS, March 2000.

[LIP, 00b]IMS Learner Information Package XML Binding Final Specification, R.Robson, C.Smythe and F.Tansey, Version 1.0, IMS, March 2001.

[LIP, 00c]IMS Learner Information Package Best Practices & Implementation Guide Public Draft Specification, R.Robson, C.Smythe and F.Tansey, Version 1.0, IMS, March 2001.

[MD, 99a]IMS Meta-data Information Model, T.Wason, Version 1.0, IMS, September 1999.

[MD, 99b]IMS Meta-data XML Binding, T.Wason, Version 1.0, IMS, September 1999.

[MD, 99c]IMS Meta-data Best Practice and Implementation Guide, T.Wason, Version 1.0, IMS, September 1999.

[Messaging,99]Proposal for the Inclusion of a Run Time Messaging Service in the IMS 1.0 Specifications, Ken Schweller, IMS, May 1999.

[PAPI, 98]IEEE PAPI Specification - Learning Technology: Public and Private Information, Version 6.0, IEEE LTSC P1484, June 2000.

[QTI, 01]IMS Question & Test Interoperability Information Model, C.Smythe and E.Shepherd, Version 1.1, IMS, March, 2001.

[Saba, 00]Profile Format: Design Specification, Daniel Lipkin, Saba Inc, May 2000. 

[SIF, 99]Schools Interoperability Framework Preliminary Implementation Specifications, Version 1.0, SIF, November 1999.

[vCard, 98]The vCard v3.0 XML DTD, F.Dawson, IETF Draft, June 1998.

2.     Learner Information Systems

2.1     A System

The Learner Information Packaging Requirement Specification [LIP, 00a] introduced the base learner information system architecture.  The underlying process components (circles) and data structures (thin rectangles) and the actors (stick-people) are shown in Figure 2.1.

Learner Information System Component Representation

Figure 2.1  Learner information system component representation.

The key components of the learner information system are:

Version 1.0 of the IMS Learner Information Package Information Model is concerned with the definition of the interface between the Local/Local and Local/Remote Learner Information Server as shown in the Figure 2.1.

2.2     Learner Information 

Learner Information is a collection of information about a Learner (individual or group learners) or a Producer of learning content (creators, providers or vendors).  The IMS LIP specification addresses the interoperability of internet-based Learner Information systems with other systems that support the Internet learning environment.  The intent of the specification is to define a set of packages that can be used to import data into and extract data from an IMS compliant Learner Information server.  A Learner Information server may exchange data with Learner Delivery systems or with other Learner Information servers.  It is the responsibility of the Learner Information server to allow the owner of the learner information to define what part of the learner information can be shared with other systems.

It is not the intent of this specification to define the internal operating architecture or functional requirements for a Learner Information server.  That is the domain of the private and public organisations that are developing these types of systems for their own purposes.

The IMS LIP is focussed on learner information i.e. other information such as administrative activities are only of concern in the manner in which they interact with learning activities.  The typical sorts of learner information to be supported are:

2.3     Categories of Learner Information

Table 2.1 provides an overview of the general categories of Learner Information data.  Each of the categories provides examples of the data that might be included.

Attributes are characteristics about the consumer or producer that affect learning in some way.  Some attributes are relatively fixed, while others are more variable.

Portfolio refers to learning activities completed or in process.  These activities can be at any level of detail, from a 4-year degree certification to data related to a particular learning activity within a course module.  Portfolio data can be self reported or certified by an independent 3rd party.  Certified 3rd party data cannot be modified by the portfolio owner.

Learners are usually individual learners, but they can also be learning groups.

Producers may be organisations or individuals, and include three general categories:

Table 2.1  Learner information general categories.[1]

Learners

Producer

  • Individual Learners (you and me)
  • Group Learners
  • Creators
  • Providers
  • Vendors

Attributes – Fixed

Identification and location (ID, Name, address, phone, email, web-address)

Physical, technical and cognitive characteristics (birth-date, disabilities)

Identification and location (ID, Name, address, phone)

Organisation type (public, private, school, business)

Attributes – Variable

Goals, learning plans

Temporary conditions

Learning preferences

Product lines

Portfolio – Self reported

Work products

References

Experience and education claims

Sample work

Expertise claimed by producer

Portfolio – 3rd party reported

Transcripts

Certifications

Professional qualifications

Testimonials

3.     Use-cases

A range of use-cases are possible but only a limited number are presented as examples of this current version of the specification:

3.1     Individual Perspective

A job applicant is using an on-line job search agency. He would like to support his resume with a complete educational history by using the official, online National Validation Center for Education and Training Records (“NVC”) created by the U.S. Department of Labor.  Using the NVC’s online process, the applicant requests that his official college transcripts be forwarded to the NVC for online posting on its secure site. In addition, the Applicant requests that his employer, which has provided and tracked substantial on-the-job training and skills enhancement over the years, send information to the NVC for posting to the site.

Using the common formats detailed in the IMS LIP specification, the colleges and the employer electronically forward their data to the NVC.  In the future, participating institutions and corporations may make their databases available and accessible via a shared protocol in which the NVC would be able to send out a “databot” that would find and display the data for a given individual through its web-site without the need for an actual physical electronic exchange of the data.

Because of the standard formats, the NVC is able to cost-effectively consolidate a lifetime of training and education into a single, easy-to-read document, which can be readily compared to other applicants providing information via the same formats. When the Applicant’s supporting documentation has been collected, the Applicant provides permissions to various potential employers to view and/or retrieve the data collected by the NVC.

3.2     Vendor Perspective

3.2.1       Perspective of a Vendor of a Human Resource Management System (HRMS)

A HRMS would be one of the major contributors to, and recipients of, learner information.  Therefore, a HRMS is a primary, de facto “learner information server”.  Some of the learner information will be employee-provided (personal information, learning preferences) while the bulk will be the result of manager-acknowledged “events”, such as qualifications received, training completed, competencies achieved, prior employment, etc.  Several key Human Resource/Personnel functions touch directly on the learner information; the sequence of processing is primarily building and maintaining the profile for the employee, either through direct input to the system or through receipt of messages from other sources, such as schools, other employers or associations.  Sample functions/uses include:

Employers do not typically share anything but the most basic information about a prior employee with a new employer; consider the very strict rules (in the US, anyway) about what can be revealed about an employee’s status in an employment verification function.  For example, the current employer or prospective employer does not ask the prior employer for information about the skills, competencies, certifications, etc. of an applicant or an employee; they ask the employee and then do the necessary verifications.  Therefore, the distribution of profile information between HRMSs, while certainly technically feasible, is an area worthy of discussion and exploration from an implementation viewpoint.  Centralized career management centres or repositories, which are under the employee’s control, may be a way to get around this normal reluctance of employers to pass along any employee data to the next employer.

3.2.2       Perspective of a Vendor of a Student Administration System

As the accepted mode of post-secondary education moves more toward distance learning, and as learners engage in educational activities in more than one institution, it becomes imperative to have a way to pass relevant learner profile information between the administration and academic systems that support the educational effort.  In fact, this type of exchange of what we are calling learner information data has been occurring for years, in various automated and manual forms.  

Just as we think of the learner information “repository” containing data typically found in a resume, we can extend that metaphor to include the educational transcript.  The administrative systems have the summary information about courses taken, grades received, awards earned and degrees achieved, while academic systems (i.e. learning management systems) may have more detailed information about learner preferences and status within a particular learning experience.  Both types of information exchange are supported by the IMS LIP data structures.  Implementation efforts will help us see how we might supplement (replace?) the traditional exchange of transcript information with the exchange of learner information data: 

3.3     UK Higher Education (Inter-organisational)

UK Higher Education is a varied collection of organisations.  There are organisations that have grown over a very long period from mediaeval times to the present, others that have been born as the result of twentieth century political initiatives and still others that have grown into universities from small independent educational beginnings in the twentieth century.  The result is a collection of organisations that are all very different.  Though there are systemic commonalities, two learners studying a course with the same title in different universities may be taking a course that is very different in structure, content and approach. Departmental and administrative structures have been similarly varied and to date many universities have relied on diverse heterogeneous incompatible information systems for internal information exchange.

3.3.1       Stakeholders and Potential Benefits

There are a large number of potential ways that the LIP specification can benefit stakeholders in Higher Education (HE) processes in the UK. Some of these operate on an intra-organisation level and some with inter-organisation information exchange. There are potential benefits for consumers (students), for provider organisations (universities and others) and for administrative agencies such as The University Council for Admissions Services (UCAS).  The potential benefits include:

3.3.2       A Life-cycle Scenario

In what follows many of the processes are currently undertaken by hand or not carried out with the efficiency or rigour that LIP enables.

Prior to admission of a learner to a university there is a selection process involving the learner, university admissions tutors at up to 6 universities and an intermediary body, UCAS, with which learners deal directly.  As a result of the process, admission to a course is agreed and learner data with validated qualification information is created and lodged with the university profile server.  Other organisations e.g. UK A-level examination boards, are involved in the validation.

At the point of enrolment the learner adds to information stored with personal information and preferences.  As a learner progresses through a course the learner profile server is given data on marks achieved and the course context. If a course is shared with another provider then that other provider can interoperate with the profile server across the Internet to store marks achieved in the context of that provision.

During a course a learner may wish to move from one provider to another, for example studying the first year at one university and the second and subsequent years at a university with a nearly equivalent course or with an approximately common first year content. Admissions tutors/processes at the second university will rule on whether the transfer can take place.  This involves looking at the course content and prerequisites and learner achievement for each course or module to determine whether the prerequisites for the course at the second university have been met. This in turn requires examining the detail of context and marks at different granularities in different areas of the course.  As learners may take time out of courses between years, detail needs to be relevant to the instance of the course that was actually followed and that will be followed.  This information could be made available via a LIP transfer.

Often learners wish to take substantial time (such as a year) out from a course and return to it later.  The LIP can facilitate this with a precise record of achievements and course context.  In the case where a course has changed its content or structure in the interim, analysis of LIP data can allow construction of an appropriate path for the learner to return to the course, possibly involving extra study to satisfy new prerequisites.  The facility to examine different granularities of course and achievement data is essential.

For a learner studying a course with an industrial placement component it is desirable that detail of the learner's abilities in particular areas, can be provided to potential placement providers (employers) to assist them with selecting appropriate candidates. Some of this detail may not be directly relevant to what has been taught on the course. For example, it may be that for a particular computing placement, an A-level Mathematics qualification (sub-degree) is essential but is not a prerequisite for entry to the present course.  The granularity with which the information needs to be presented is very different in different circumstances and could be under the control of the enquirer (employer).

At the end of a course information about a learner’s achievements, both on the course and in other areas can be provided, under the learner’s control, to prospective employers.  When the learner applies to take courses at other institutions in the future, a record can be made available of qualifications and abilities at a fine granularity can be made available.

3.4     Career Management

As part of America’s Career Kit, an initiative to provide assistance to all citizens in career creation and management and facilitate life long learning, the USDoL is developing a Career Management Account System. This prototype will provide a centralized repository wherein all relevant career information such as transcripts, performance reviews, sample work product, and other information besides the usual biographical material may be securely stored.  The Career Management Account System (CMA) has been designed in two parts, the CMA that provides access control and security and acts as a “wrapper” for a collection of Portfolios.

3.4.1       Portfolio Data

The Portfolio is the central data construct in the CMA System. Each Life-long Learner creates, manages, and owns their individual Portfolio and the data it contains. This data is categorized as follows:

All access to the CMA and to all facilities and Portfolio’s is under a strong public key infrastructure and requires full digital certification. Key fields in each record in the Portfolio are separately encrypted to prevent direct identification of individuals from non-specific information. For example, access to a single transcript will not yield and individual information and therefore cannot be linked back to an individual.

3.4.2       Actors

3.5     Training Group Management

In many organisations staff are encouraged to undergo a range of training to help develop their competencies and knowledge thereby improving the usefulness to their employer and their own career prospects.  These companies run internal training courses and so a ‘cohort’ of individuals may train as a group.  This creates three distinct but related perspectives i.e. that of the trainer, the individual learner and the associated group. From the point of view of the trainer the key actions that must be supported are:

From the point of view of the individual learner the key actions to be supported are:

From the point of view of the group the key actions to be supported are:

4.     Basic Information Model

The full Learner Information Information Model has three closely related components:

This specification is concerned with the Learner Information Package ONLY.

4.1     Learner Information Package

The underlying logical data structures for the learner information package are shown in Figure 4.1.  This representation shows the relationship between the learnerinformation elements.

The principle LIP data structure.

Figure 4.1  The principle LIP data structure.

Figure 4.1b shows the eleven core information types that are considered fundamental to the learner information data structures and the content information used to store information describing the content.  The breakdown into the eight structures is used to support variable granularity to facilitate efficient and flexible information exchange.  The content information, contentype, as shown in Figure 4.1a, consists of:

Figure 4.1 also shows the recursive nature of the eleven core data structures (identification … relationship).  These core structures may have a recursive sub-structure.  The ‘atomic’ sub-structure is the lowest level for which there is a unique reference identifier i.e. the lowest level for which contentype exists.  Each of the eleven core structures may occur many times within the learner information structure e.g. there will be a separate entry for each qualification, certificate and licence.

It is important to state that:

4.2     Learner Information Exchange

The exchange of LIP instances requires the following processing capabilities:

Note:      At present the Learner Information Exchange (LIX) is outside the scope of this specification.

4.3     Learner Information Query

The storage of distributed learner information requires a mechanism by which the storage medium can be queried for the contents.  Querying allows the system to provide information of a particular nature on request.  Support for querying requires:

Note:      At present the Learner Information Query (LIQ) is outside the scope of this specification.

5.     Packaging Learner Information

5.1     Core Data Structures

The core learner information data structures are defined using the representation shown in Figure 5.1.

The schematic representation for learner profile information.

Figure 5.1  The schematic representation for learner profile information.

The structures[2] shown in Figure 5.1 are:

<…data…>            The actual learner information itself.  This consists of either: identification, interest, qcl, goal, transcript, accessibility, activity, competency, affiliation, relationship and securitykey structures;

R-Referential. The information structure that can be used to contain the data that uniquely identifies the data itself;

T-Temporal. The information structure that can be used to contain time-based data about the data itself e.g. the data of creation of the data;

P-Privacy.  The information structure that can be used to contain privacy data (such as access control rights) and to ensure the integrity of the data e.g. a checksums.

Extension -The extension capability that can be used to support implementation specific features.

The eleven core data structures are:

 

identification

identification

The identification learner information contains all of the data for a specific individual or organisation.  This includes data such as: name, address, contact information, agent and demographics. 

 

accessibility

accessibility

The accessibility learner information consists of the cognitive, technical and physical preferences for the learner, disability, eligibility and language capabilities.  These describe the learner’s capabilities to interact with the learning environment.

 

qcl

qcl

The qcl learner information consists of the qualifications, certifications and licenses awarded to the learner i.e. the formally recognised products of their learning and work history.  This includes information on the awarding body and may also include electronic copies of the actual documents.  A different ‘qcl’ structure will be used for each qualification, etc.

 

activity

activity

The activity learner information consists of the education/training, work and service (military, community, voluntary, etc.) record and products (excluding formal awards).  This information may include the descriptions of the courses undertaken and the records of the corresponding assessment.  A separate ‘activity’ structure will be used for each entry.

 

goal

goal

The goal learner information consists of the description of the personal objectives and aspirations.  These descriptions may also include information for monitoring the progress in achieving the goals.  A goal can be defined in terms of sub-goals.  A different ‘goal’ structure will be used for each entry.

 

competency

competency

The competency learner information consists of the descriptions of the skills the learner has acquired.  These skills may be associated with some formal or informal training or work history (described in the ‘activity’) and formal awards (described in the ‘qcl’).  A different ‘competency’ structure will be used for each competency through an external reference mechanism.  The adopted competency definition follows the work of the IMS Competency Definition working-group.

 

interest

interest

The interest learner information consists of descriptions of hobbies and other recreational activities.  These interests may have formal awards (as described in the associated ‘qcl’).  Electronic versions of the products of these interests may also be contained.  Each interest will be described within its own ‘interest’ structure.

 

transcript

transcript

The transcript learner information is used to store the summary records of the academic performance at an institution.  This information may contain an arbitrary level of detail and so there is no proscribed structure for a transcript.

 

affiliation

affiliation

The affiliation learner information is used to store the descriptions of the organisation affiliations associated with the learner.  These affiliations may include education groups e.g. classes, cohorts, etc. but it is expected that these will be exchanged using the IMS Enterprise specification technique.

 

securitykey

securitykey

The securitykey learner information is used to store the passwords and security codes that are to be used when communicating with the learner.  A different ‘securitykey’ structure will be used for each key and class of key.

 

relationship

relationship

The relationship learner information is used to store the description of the relations between the other core data structures.  All of the relationship information has been removed from the other structures to enable these to be collected at a single place.  This structure may also be used to describe mapping relationships to be used by the communicating systems.

5.2     Distributed Systems

The LIP is capable of supporting the exchange of data between distributed learner information systems.  This is achieved by using a flexible referencing system that can be used to identify the learner information record and data structures within that record.  The two separate referencing mechanisms are:

Disributed learner information referencing

Figure 5.2  Distributed learner information referencing.

An example of the LIP’s support for distributed learner information is shown in Figure 5.2.  In this system there are three learner information servers (LIS1, LIS2 and LIS3).  The learner information consists of four structures (indexid_1 to indexid_4) and the source, LIS1, has assigned it a sourcedid of ‘sourcedid_1’.  LIS1 has now exchanged this learner information with the two other servers LIS2 and LIS3.  LS1 has given different learner information to the other two servers however all three structures have the same sourcedid - this is the data used to uniquely identify that learner information record between the three LI servers.

Further learner information transfers between the three servers can now reference the specific data structures by using the appropriate indexid.  This approach can also be used to promote the privacy of the data as the three servers do not contain the same learner information.  In fact LIS2 and LIS3 may only be able to exchange the ‘indexid_1’ information as that is the only common knowledge they have of the ‘sourcedid_1’ record.

It is possible that the information concerning a single learner (individual or organisation) could be contained on different LISs and could also have different sourcedids.  This multiplicity of sourcedids for a single learner could be consequence of distributed learner information systems.  The reconciliation of these into a single structure or the prevention of conflict with respect to the consistency of the information is beyond the scope of this specification.

5.3     Scalability

Within a learner information system the data may be exchanged as:

In both cases the information exchanged may be for a single learner or may be for thousands of users e.g. applications to study at a particular college.  The learner information may include products of the education, training or work history of the individual and these products may be graphics (high-resolution art-work), video (to show training for the film industry), etc.  In such cases the products themselves may be many megabytes/gigabytes of storage.  Each of these issues must be addressed to ensure that the IMS LIP is scalable in terms of efficient storage and accessibility for millions of records.  The mechanisms for scalability supported by the LIP are:

5.4     Privacy & Data Protection

The privacy and integrity of the data being exchanged is essential.  While the details of the security architecture being employed to support the learner information system is outside the scope of this specification it is important to provide mechanisms that can be used to support the implementation of any suitable architecture.  The LIP has two such mechanisms:

5.4.1       Privacy and Data Protection Meta-structure

Within the learner information tree structure each node and leaf has an associated set of privacy information (the usage of these fields is optional).  The granularity of information that can be exchanged is defined by the smallest set of data at which there is no further independent privacy data.  The nature of the privacy data is beyond the scope of the specification as all that is defined within the LIP is the place at which such information is associated with the learner information data structure.

5.4.2       Learner Security Keys

The security keys for the learner include their public keys for public key encryption, passwords for access to the information (electronic and verbal) and digital signatures to be used to ensure data authenticity.  The detailed structure for the keys will not be defined but this data will be supported in the  ‘securitykey’ core data structure.

6.     Conceptual Description of the Data Objects

6.1     Underlying Structure of the Learner Information

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

The primary elements of the Lip data structures

Figure 6.1  The primary elements of the LIP data structures.

6.2     Extensions & Extensibility

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

The process by which the points at which the three forms of extensions fit within the taxonomy are clearly denoted in the IMS LIP XML Binding [LIP, 01b].

6.3     Learner Information Package Tabular Description

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

No: The number of the data element.  An element may be composed of sub-elements.  The numbering scheme reflects these relationships.

Name: The descriptive name of the element.

Explanation: A brief functional description of the element.

Required: Indicates if the element is required:

Multi:                     Multiplicity of the element:

Type: A description of formatting rules for the data element.  Type includes the maximum length of the element:

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

Note: Additional descriptive information about the element.

In the following tables the data objects are organised as:

6.3.1       Learner Information Package Data Objects

Table 6.1 describes the data objects that are used in the construction of the learner information package itself.

Table 6.1  Learner information package data objects detailed description.

No

Name

Explanation

Reqd

Mult

Type

Note

1.1

langtype

The default language used for the information.

As per structure 13.1 (Table 6.13).

1.2

comment

As per structure 13.2 (Table 6.13).

1.3

contentype

As per structure 13.3 (Table 6.13).

1.4

identification

Personal information such as name, address contact info, agent and demographics.

O

n

As per Table 6.2.  Multiple entries for each different component.

1.5

accessibility

Learner accessibility issues for language, disability, preferences and eligibility.

O

n

As per Table 6.3.  One entry is used for each form of accessibility.

1.6

goal

Learning, career and other objectives and aspirations.

O

n

As per Table 6.4.  One entry is used per goal.

1.7

qcl

Received qualifications, certifications and licences (for activities that have been completed).

O

n

As per Table 6.5.  One entry is used per qualification, certificate and license.

1.8

activity

Activities for which learner information are relevant.

O

n

As per Table 6.6.  One entry is used per education/training, work or service entry.

1.9

competency

Acquired learning competencies.

O

n

As per Table 6.7.  One entry is used per competency.

1.10

interest

Learner information describing hobbies and recreational activities.

O

n

As per Table 6.8.  One entry is used per interest.

1.11

affiliation

Membership of learned, professional, civic and recreational organisations.

O

n

As per Table 6.9.  One entry is used per affiliation.

1.12

transcript

Summary records of academic performance.

O

n

As per Table 6.10.  One entry is used per transcript.

1.13

securitykey

The security keys to be used when interacting with the learner.

O

n

As per Table 6.11.  One entry is used per secure key.

1.14

relationship

The relationships to be established between the other core data structures.

O

n

As per Table 6.12.  One entry is used per relationship.

1.15

extension

The extension facility for the top-level ‘learnerinformation’.

O

n

As per structure 13.16 (Table 6.13)


6.3.2       ‘identification’ Data Structure

Table 6.2 describes the identification learner information data structures.

Table 6.2  ‘identification’ learner information data structure detailed description.

No

Name

Explanation

Reqd

Mult

Type

Note

2.1

comment

As per structure 13.2 (Table 6.13).

2.2

contentype

As per structure 13.3 (Table 6.13).

2.3

formname

The detailed formatted name of the individual or organisation - as per vCard.

O

n

A separate entry is used per name.

2.3.1

typename

The type of formatted name.

O

As per structure 13.4 (Table 6.13).  The domain type will be defined from an appropriate vocabulary.

2.3.2

comment

As per structure 13.2 (Table 6.13).

2.3.3

contentype

As per structure 13.3 (Table 6.13).

2.3.4

text

The name itself.

M

As per structure 13.13 (Table 6.13).

2.4

name

The detailed name of the individual or organisation.

O

n

A separate entry is used per name.

2.4.1

typename

The type of name.

O

As per structure 13.3 (Table 6.13).  The domain type will be defined from an appropriate vocabulary.

2.4.2

comment

As per structure 13.2 (Table 6.13).

2.4.3

contentype

As per structure 13.3 (Table 6.13).

2.4.4

partname

The part of the name being defined e.g. ‘first’, ‘last’, etc.

M

n

A separate entry is used per part of the name.

2.4.4.1

typename

The type of the name part.

O

As per structure 13.4 (Table 6.13).  The domain type will be defined from an appropriate vocabulary.

2.4.4.2

text

The name itself.

M

As per structure 13.13 (Table 6.13).

2.5

address

The detailed address of the individual or organisation.

O

n

A separate entry is used per address.

2.5.1

typename

The type of address.

M

As per structure 13.4 (Table 6.13).  The domain type will be defined from an appropriate vocabulary.

2.5.2

comment

As per structure 13.2 (Table 6.13).

2.5.3

contentype

As per structure 13.3 (Table 6.13).

2.5.4

pobox

Post Office Box number.

O

String.
1-32 chars.

2.5.4.1

langtype

The default language used for the PO Box.

As per structure 13.2 (Table 6.13).

2.5.5

street

The street part of the address.

O

2.5.5.1

nonfieldedstreetaddress

Unformatted street address.

O

String.
1-256 chars.

2.5.5.1.1

langtype

The default language used for the non-fielded street address.

As per structure 13.2 (Table 6.13).

2.5.5.2

complex

The name of the complex on the street.

O

String.
1-128 chars

2.5.5.2.1

langtype

The default language used for the complex.

As per structure 13.2 (Table 6.13).

2.5.5.3

streetnumber

The street number.

O

String.
1-8 chars.

2.5.5.3.1

langtype

The default language used for the street number.

As per structure 13.2 (Table 6.13).

2.5.5.4

streetprefix

Street prefix e.g. ‘St.’.

O

String.
1-8 chars.

2.5.5.4.1

langtype

The default language used for the street prefix.

As per structure 13.2 (Table 6.13).

2.5.5.5

streetname

Street name.

O

String.
1-128 chars.

2.5.5.5.1

langtype

The default language used for the street name.

As per structure 13.2 (Table 6.13).

2.5.5.6

streetype

The type of street e.g. ‘Road’, ‘Avenue’ etc.

O

String.
1-32 chars.

2.5.5.6.1

langtype

The default language used for the street type

As per structure 13.2 (Table 6.13).

2.5.5.7

streetsuffix

Street suffix.

O

String.
1-8 chars.

2.5.5.7.1

langtype

The default language used for the street suffix.

As per structure 13.2 (Table 6.13).

2.5.5.8

apttype

Apartment type.

O

String.
1-32 chars.

2.5.5.8.1

langtype

The default language used for the apartment type.

As per structure 13.2 (Table 6.13).

2.5.5.9

aptnumprefix

Apartment number prefix.

O

String.
1-8 chars.

2.5.5.9.1

langtype

The default language used for the apartment number prefix.

As per structure 13.2 (Table 6.13).

2.5.5.10

aptnumber

The apartment number.

O

String.
1-8 chars.

2.5.5.10.1

langtype

The default language used for the apartment number.

As per structure 13.2 (Table 6.13).

2.5.5.11

aptnumsuffix

Apartment number suffix.

O

String.
1-2 chars.

2.5.5.11.1

langtype

The default language used for the apartment suffix number.

As per structure 13.2 (Table 6.13).

2.5.6

locality

Locality part of the address.

O

String.
1-128 chars.

This is typically the name of the immediate community.

2.5.6.1

langtype

The default language used for the locality.

As per structure 13.1 (Table 6.13).

2.5.7

city

City part of the address.

O

String.
1-128 chars.

2.5.7.1

langtype

The default language used for the city.

As per structure 13.1 (Table 6.13).

2.5.8

country

Country part of the address.

O

String.
1-128 chars.

2.5.8.1

langtype

The default language used for the country.

As per structure 13.1 (Table 6.13).

2.5.9

statepr

The state/province part of the address.

O

String.
1-128 chars.

2.5.9.1

langtype

The default language used for the state/province.

As per structure 13.1 (Table 6.13).

2.5.10

region

Region part of the address.

O

String.
1-128 chars.

2.5.10.1

langtype

The default language used for the region.

As per structure 13.1 (Table 6.13).

2.5.11

postcode

The postcode part of the address.

O

String.
1-16 chars.

2.5.11.1

langtype

The default language used for the  post code.

As per structure 13.1 (Table 6.13).

2.5.12

timezone

The time-zone part of the address.

O

String.
1-8 chars.

2.5.12.1

langtype

The default language used for the time-zone.

As per structure 13.1 (Table 6.13).

2.5.13

geo

Geographic location as defined by latitude and longitude.

O

2.5.13.1

lat

Latitude entry.

M

#PCDATA.

Degrees (AB), minutes (XY) and seconds (MN) i.e. AB.XY.MN where AB is an integer in the range 00-89 and, XY and MN are integers in the range 00-60.

2.5.13.2

lon

Longitude entry.

M

#PCDATA.

Degrees (AB), minutes (XY) and seconds (MN) i.e. AB.XY.MN where AB is an integer in the range 00-89 and, XY and MN are integers in the range 00-60.

2.6

contactinfo

The detailed contact information of the individual or organisation.

O

n

2.6.1

typename

The type of contact information e.g. home work, etc.

O

As per structure 13.4 (Table 6.13).  The domain type will be defined from an appropriate vocabulary.

2.6.2

comment

As per structure 13.2 (Table 6.13).

2.6.3

contentype

As per structure 13.3 (Table 6.13).

2.6.4

telephone

The telephone number.

O

2.6.4.1

countrycode

The country code.

O

#PCDATA.
Two integer code in the range 00-99.

2.6.4.2

areacode

The area code.

M

#PCDATA.
1-10 chars.

2.6.4.3

indnumber

The specific telephone number.

M

#PCDATA.
1-10 chars.

2.6.4.4

extnumber

The extension number within the PABX.

O

#PCDATA.
1-10 chars.

2.6.5

facsimile

The facsimile number.

O

2.6.5.1

countrycode

The country code.

O

#PCDATA.
Two integer code in the range 00-99.

2.6.5.2

areacode

The area code.

M

#PCDATA.
1-10 chars.

2.6.5.3

indnumber

The specific facsimile number.

M

#PCDATA.
1-10 chars.

2.6.5.4

extnumber

The extension number within the PABX.

O

#PCDATA.
1-10 chars.

2.6.6

mobile

The mobile number.

O

2.6.6.1

countrycode

The country code.

O

#PCDATA.
Two integer code in the range 00-99.

2.6.6.2

areacode

The area code.

M

#PCDATA.
1-10 chars.

2.6.6.3

indnumber

The specific mobile number.

M

#PCDATA.
1-10 chars.

2.6.7

pager

The pager number.

O

2.6.7.1

countrycode

The country code.

O

#PCDATA.
Two integer code in the range 00-99.

2.6.7.2

areacode

The area code.

M

#PCDATA.
1-10 chars.

2.6.7.3

indnumber

The specific pager number.

M

#PCDATA.
1-10 chars.

2.6.8

email

Email address.

O

#PCDATA.1-128 chars.

2.6.9

web

Web address defined as the URL.

O

#PCDATA.1-128 chars.

2.7

demographics

The mechanisms by which the individual can be recognised for learning.

O

n

2.7.1

typename

The type of demographics information.

O

As per structure 13.4 (Table 6.13).  The domain type will be defined from an appropriate vocabulary.

2.7.2

comment

As per structure 13.2 (Table 6.13).

2.7.3

contentype

As per structure 13.3 (Table 6.13).

2.7.4

representation

Representative information of the learner e.g. photograph.

O

n

2.7.4.1

date

Recorded dates appropriate to the representation.

O

n

As per structure 13.6 (Table 6.13).

2.7.4.2

description

The representation of the learner and a brief description of its usage.

O

n

As per structure 13.5 (Table 6.13).

2.7.5

gender

The gender of the learner.

O

Enumerated as ‘Male’ or ‘Female’.

The enumeration is language dependent.

2.7.6

date

Recorded dates appropriate to the demographics data.

O

n

As per structure 13.6 (Table 6.13).

2.7.7

placeofbirth

Place of birth of the learner.

O

String.
1-128 chars.

2.7.7.1

langtype

The default language used for the place of birth.

As per structure 13.1 (Table 6.13).

2.7.8

uid

An identifier assigned to the learner e.g. social security number.

O

String.
1-32 chars.

2.8

agent

The information of the ‘agents’ who can act on behalf of the learner.

O

n

A separate entry is used per agent.

2.8.1

typename

The type of agent e.g. Parent, Guardian, etc.

O

As per structure 13.3 (Table 6.13).  The domain type will be defined from an appropriate vocabulary.

2.8.2

comment

As per structure 13.2 (Table 6.13).

2.8.3

contentype

As per structure 13.3 (Table 6.13).

2.8.4

agentid

The identifier assigned to the agent.

O

String.
1-128 chars.

2.8.5

agentdomain

The role of the agent e.g. legal, financial etc.

O

2.8.5.1

typename

The type of role.

O

As per structure 13.4 (Table 6.13).  The domain type will be defined from an appropriate vocabulary.

2.8.6

description

The description of the role of the agent.

O

As per structure 13.5 (Table 6.13).

2.9

extension

The extension facility for the ‘identification’ learner information.

O

As per structure 13.16 (Table 6.13).


6.3.3       ‘accessibility’ Data Structure

Table 6.3 describes the accessibility learner information data structures.

Table 6.3  ‘accessibility’ learner information data structure detailed description.

No

Name

Explanation

Reqd

Mult

Type

Note

3.1

comment

As per structure 13.2 (Table 6.13).

3.2

contentype

As per structure 13.3 (Table 6.13).

3.3

language

The language reading, writing and speech capabilities of the learner.

O

n

A separate entry is used per language.

3.3.1

typename

The type of language.

O

As per structure 13.4 (Table 6.13).  The domain will be defined by a language-type vocabulary.

3.3.2

comment

As per structure 13.2 (Table 6.13).

3.3.3

contentype

As per structure 13.3 (Table 6.13).

3.3.4

proficiency

The language proficiency of the learner i.e. oral, reading, writing.

C

String.
1-1024 chars.

3.3.4.1

langtype

The default language used for the language proficiency.

As per structure 13.1 (Table 6.13).

3.3.4.2

profmode

The type of proficiency.

M

Enumerated.
Options are: Write, Read, OralSpeak, OralComp

3.3.5

extension

The extension facility for the ‘language’ learner.

As per structure 13.16 (Table 6.13).

3.4

preference

Learning preferences (optional and mandatory).

O

n

3.4.1

typename

The type of cognitive preference.

O

As per structure 13.4 (Table 6.13). The domain will be defined by a cognitive-type vocabulary.

3.4.2

comment

As per structure 13.2 (Table 6.13).

3.4.3

contentype

As per structure 13.3 (Table 6.13).

3.4.4

prefcode

The coding assigned to the preference.

O

#PCDATA

Free format entry used to describe the preference.

3.4.4.1

langtype

The default language used for the preference code.

As per structure 13.1 (Table 6.13).

3.4.5

description

The description of the preference.

O

As per structure 13.5 (Table 6.13).

3.4.6

extension

The extension facility for the ‘cognitive preferences’ learner information.

As per structure 13.16 (Table 6.13).

3.5

eligibility

The eligibilities associated with the learner.

O

n

For further development in V2.0.

3.5.1

typename

The type of eligibility being defined.

O

As per structure 13.4 (Table 6.13).  The domain type will be defined by an ‘eligibility’ vocabulary.

3.5.2

comment

As per structure 13.2 (Table 6.13).

3.5.3

contentype

As per structure 13.3 (Table 6.13).

3.5.4

extension

The extension facility for the ‘eligibility’ learner information.

As per structure 13.16 (Table 6.13).

3.6

disability

The disabilities associated with the learner.

O

n

For further development in V2.0.

3.6.1

typename

The type of disability being defined.

O

As per structure 13.4 (Table 6.13).  The domain type will be defined by a ‘disability’ vocabulary.

3.6.2

comment

As per structure 13.2 (Table 6.13).

3.6.3

contentype

As per structure 13.3 (Table 6.13).

3.6.4

extension

The extension facility for the ‘disability’ learner information.

O

As per structure 13.16 (Table 6.13).

3.7

extension

The extension facility for the ‘accessibility’ learner information.

O

As per structure 13.16 (Table 6.13).

6.3.4       ‘goal’ Data Structure

Table 6.4 describes the goal learner information data structures.

Table 6.4  ‘goal’ learner information data structure detailed description.

No

Name

Explanation

Reqd

Mult

Type

Note

4.1

typename

The type of goal.

O

As per structure 13.44 (Table 6.13).  The domain type will be defined by a 'goal' vocabulary.

4.2

comment

As per structure 13.2 (Table 6.13).

4.3

contentype

As per structure 13.3 (Table 6.13).

4.4

date

Recorded dates appropriate to the goal.

O

n

As per structure 13.6 (Table 6.13).

4.5

priority

Priority of the goal.

O

As per structure 13.7 (Table 6.13).

4.5.1

langtype

The default language used for the goal.

As per structure 13.1 (Table 6.13).

4.6

status

Recorded status of the goal.

O

n

As per structure 13.8 (Table 6.13).

4.7

description

The description of the goal itself.

O

As per structure 13.5 (Table 6.13).

4.8

goal

Recursive reference to enable the creation of sub-goals.

O

n

As per Table 6.4.

4.9

extension

The extension facility for the ‘goal’ learner information.

O

As per structure 13.16 (Table 6.13).

 

6.3.5       ‘qcl’ Data Structure

Table 6.5 describes the qcl learner information data structures.

Table 6.5  ‘qcl’ learner information data structure detailed description.

No

Name

Explanation

Reqd

Mult

Type

Note

5.1

typename

The type of qualification, certification or license.

O

As per structure 13.3 (Table 6.13).  The domain type will be defined by a corresponding vocabulary.

5.2

comment

As per structure 13.2 (Table 6.13).

5.3

contentype

As per structure 13.3 (Table 6.13).

5.4

title

The title of the qualification, certification or license.

O

5.4.1

langtype

The default language used for the qcl title.

As per structure 13.1 (Table 6.13).

 

5.5

organisation

The organisation responsible for the awarding of the qualification, certification or license.

O

As per structure 13.14 (Table 6.13).

5.6

registrationno

The identification number allocated to the qualification, certification or license by the awarding organisation.

O

String.
1-256 chars.

 

5.7

level

The level/grade of the qcl.

O

 

5.7.1

text

The textual description of the level.

M

As per structure 13.13 (Table 6.13).

5.7.2

level

A sub-level definition for the qualification, certification or license.

O

This creates a recursive structure of arbitrary depth for describing the level.

5.8

date

Recorded dates appropriate to the qualification, certification or license.

O

n

As per structure 13.6 (Table 6.13).

5.9

description

The description of the qualification, license or certification or license.

O

As per structure 13.5 (Table 6.13).

5.10

extension

The extension facility for the ‘qcl’ learner information.

O

As per structure 13.16 (Table 6.13).

 

6.3.6       ‘activity’ Data Structure

Table 6.6 describes the activity learner information data structures.

Table 6.6  ‘activity’ learner information data structure detailed description.

No

Name

Explanation

Reqd

Mult

Type

Note

 

6.1

typename

The type of education, training, vocational, service, etc. activity.

O

As per structure 13.4 (Table 6.13).  The domain type will be defined by an appropriate vocabulary.

 

6.2

comment

As per structure 13.2 (Table 6.13).

 

6.3

contentype

As per structure 13.3 (Table 6.13).

 

6.4

date

Recorded dates appropriate to the activity.

O

n

As per structure 13.6 (Table 6.13).

6.5

status

Recorded status of the activity.

O

As per structure 13.8 (Table 6.13).

 

6.6

units

The unit assigned to the activity in

O

The usage of this structure is determined per user.

 

6.6.1

unitsfield

The fields to be assigned to the units.

M

n

 

6.6.1.1

fieldlabel

The label of the field that will contain the unit data.

M

As per structure 13.10 (Table 6.13).

 

6.6.1.2

fielddata

The units field data content.

M

As per structure 13.11 (Table 6.13).

 

6.7

learningactivityref

External reference to the associated learning identifier.

O

n

 

6.7.1

sourcedid

The global identifier for the learning activity being referenced.

O

n

As per structure 13.3.1.1 (Table 6.13).

 

6.7.2

text

The textual description of the referenced learning activity.

O

n

As per structure 13.13 (Table 6.13).

 

6.8

definition

The definition of the material being studied as part of he activity.

O

n

This detailed structure of the material is defined with respect to each particular usage and so no standard format is mandated.

 

6.8.1

typename

The type of definition

O

As per structure 13.4 (Table 6.13).  The domain type is to be defined by an appropriate vocabulary.

 

6.8.2

comment

As per structure 13.2 (Table 6.13).

 

6.8.3

contentype

As per structure 13.3 (Table 6.13).

 

6.8.4

definitionfield

The fields that are to be used to hold the definition structure.

O

n

 

6.8.4.1

fieldlabel

The label of the field that will contain the definition data.

M

As per structure 13.10 (Table 6.13).

 

6.8.4.2

fielddata

The definition field data content.

M

As per structure 13.11 (Table 6.13).

 

6.8.5

description

The description of the material definition

O

As per structure 13.5 (Table 6.13).

 

6.8.6

definition

Recursive reference to the 'definition' structure allowing arbitrarily complex hierarchical definitions to be constructed.

O

n

As per structure 6.8.

 

6.8.7

extension

The extension facility for the ‘definition’ learner information.

As per structure 13.16 (Table 6.13).

 

6.9

product

The products created as part of undertaking the activity.

O

n

As per structure 13.9 (Table 6.13).

 

6.10

testimonial

A testimonial for the learner by someone associated with this activity,

O

n

 

6.10.1

typename

The type of testimonial.

O

As per structure 13.4 (Table 6.13).  The domain type is to be defined by an appropriate vocabulary.

 

6.10.2

comment

As per structure 13.2 (Table 6.13).

 

6.10.3

contentype

As per structure 13.3 (Table 6.13).

 

6.10.4

date

Recorded dates appropriate to the testimonial.

O

n

As per structure 13.6 (Table 6.13).

 

6.10.5

description

The testimonial itself.

O

As per structure 13.5 (Table 6.13).

 

6.10.6

extension

The extension facility for the testimonial information.

O

As per structure 13.16 (Table 6.13).

 

6.11

evaluation

Evaluation of the activity e.g. through an examination, etc.

O

n

 

6.11.1

typename

The type of evaluation.

O

As per structure 13.4 (Table 6.13).  The domain type is to be defined in a corresponding vocabulary.

 

6.11.2

comment

As per structure 13.1 (Table 6.13).

 

6.11.3

contentype

As per structure 11.2 (Table 7.11).

 

6.11.4

evaluationid

The identifier associated to the evaluation component

O

An example could be the Item, Section or Assessment identifier as defined within the IMS QTI Specification.

 

6.11.5

date

Recorded dates appropriate to the evaluation.

O

n

As per structure 13.6 (Table 6.13).

 

6.11.6

evalmetadata

The meta-data associated with this evaluation.

O

This could take the structure as defined within the IMS QTI Specification.

 

6.11.6.1

typename

The type of meta-data group.

O

As per structure 13.4 (Table 6.13).  The domain type is to be defined in a corresponding vocabulary.

 

6.11.6.2

evalmetadatafield

The structure that contains each of the meta-data fields.

M

n

 

6.11.6.2.1

langtype

The default language used for the meta-data.

As per structure 13.2 (Table 6.13).

 

6.11.6.2.2

fieldlabel

The label of the field that will contain the meta-data data.

M

As per structure 13.10 (Table 6.13).

 

6.11.6.2.3

fielddata

The meta-data field data content.

M

As per structure 13.11 (Table 6.13).

 

6.11.7

objectives

The objectives assigned to the evaluation materials.

O

n

This uses the mechanism similar to that used by the IMS QTI Specification.

 

6.11.7.1

view

The view associated with this particular set of objectives.

O

n

Uses an enumerated vocabulary as defined in the IMS QTI Spec.

This uses the mechanism employed by the IMS QTI Specification.

 

6.11.7.2

comment

As per structure 13.2 (Table 6.13).

 

6.11.7.3

media

The content placeholder for all text, image, video, etc. materials.

M

As per structure 13.12 (Table 6.13).

 

6.11.7.4

contentref

The external reference mechanism for the material associated with the objectives.

O

n

String.
1-2048 chars.

 

6.11.7.5

extension

The extension facility for the ‘objectives’ information.

O

As per structure 13.16 (Table 6.13).

 

6.11.8

status

Recorded status of the evaluation.

O

n

As per structure 13.8 (Table 6.13).

 

6.11.9

noofattempts

The number of attempts made on this evaluation.

O

An integer in the range 1-99.

 

6.11.10

duration

The different types of duration that are associated with the evaluation e.g. time to complete the last attempt.

O

n

The recorded durations are constructed using an arbitrary definition and so no standard format is imposed.

 

6.11.10.1

fieldlabel

The label of the field that will contain the duration data.

M

n

As per structure 13.10 (Table 6.13).

 

6.11.10.2

fielddata

The duration field data content.

M

n

As per structure 13.11 (Table 6.13).

 

6.11.11

result

The results that compose the evaluation.

O

n

The results are constructed using an arbitrary definition and so no standard format is imposed.

 

6.11.11.1

interpretscore

Information used to describe the context of the scoring data e.g. maximum possible score.

C

n

 

6.11.11.1.1

fieldtype

The field type that will contain the result data.

M

As per structure 13.10 (Table 6.13).

 

6.11.11.1.2

fielddata

The result field data content.

M

As per structure 13.11 (Table 6.13).

 

6.11.11.2

score

The scoring data itself.

C

n

The type of score is not restricted to just numerical values.

 

6.11.11.2

result

The sub-results that constitute the evaluation.

C

n

As per structure 6.11.11.

This allows for the support of complex results structures.

 

6.11.11.2.1

fieldlabel

The label of the field that will contain the score data.

M

As per structure 13.10 (Table 6.13).

 

6.11.11.2.2

fielddata

The score field data content.

M

As per structure 13.11 (Table 6.13).

 

6.11.12

description

The description of the evaluation.

O

As per structure 13.5 (Table 6.13).

 

6.11.13

evaluation

This recursive definition allows arbitrarily complex hierarchical evaluation structures to be constructed.

O

n

As per structure 6.11

 

6.11.14

extension

The extension facility for the ‘service’ learner information.

O

As per structure 13.16 (Table 6.13).

 

6.12

description

The description of the activity itself.

O

As per structure 13.5 (Table 6.13).

 

6.13

activity

This recursive reference enables arbitrarily complex activity structures to be constructed.

O

n

As per the structure in Table 6.6.

 

6.14

extension

The extension facility for the ‘activity’ information.

O

As per structure 13.16 (Table 6.13).

 

6.3.7       ‘competency’ Data Structure

Table 6.7 describes the competency learner information data structures.

Table 6.7  ‘competency’ learner information data structure detailed description.

No

Name

Explanation

Reqd

Mult

Type

Note

7.1

comment

As per structure 13.2 (Table 6.13).

7.2

contentype

As per structure 13.3 (Table 6.13).

7.3

exrefrecord

The description of the competency using an appropriate externally defined structure.

O

As per structure 13.15 (Table 6.13).

7.4

description

The description of the competency.

O

As per structure 13.5 (Table 6.13).

7.5

extension

The extension facility for the ‘competency’ learner information.

O

As per structure 13.16 (Table 6.13).

 

6.3.8       ‘interest’ Data Structure

Table 6.8 describes the interest learner information data structures.

Table 6.8  ‘interest’ learner information data structure detailed description.

No

Name

Explanation

Reqd

Mult

Type

Note

8.1

typename

The type of interest.

O

As per structure 13.4 (Table 6.13).  The domain type will be defined by an appropriate vocabulary.

8.2

comment

As per structure 13.2 (Table 6.13).

8.3

contentype

As per structure 13.3 (Table 6.13).

8.4

product

Copies of any product created as part of the interest activity.

O

As per structure 13.9 (Table 6.13).

8.5

description

The description of the interest.

O

As per structure 13.5 (Table 6.13).

8.6

extension

The extension facility for the ‘interest’ learner information.

O

As per structure 13.16 (Table 6.13).

6.3.9       ‘affiliation’ Data Structure

Table 6.9 describes the affiliation learner information data structures.

Table 6.9  ‘affiliation’ learner information data structure detailed description.

 

No

Name

Explanation

Reqd

Mult

Type

Note

 

9.1

typename

The type of affiliation e.g. professional.

O

As per structure 13.4 (Table 6.13).  The domain type will be defined by an appropriate vocabulary.

 

9.2

comment

As per structure 13.2 (Table 6.13).

 

9.3

contentype

As per structure 13.3 (Table 6.13).

 

9.4

classification

The type of affiliation membership e.g. ‘member’, ‘Fellow’.

O

String.
1-128 chars.

The classification of affiliation is distinct from the roles that may be undertaken.

 

9.4.1

langtype

The default language used for the classification.

As per structure 13.1 (Table 6.13).

 

 

9.5

affiliationid

Identifier assigned to the affiliation e.g. membership number.

O

String.
1-128 chars.

 

 

9.6

role

The role(s) undertaken by the learner.

O

n

 

 

9.6.1

typename

The type of role undertaken within the host organisation.

O

As per structure 13.4 (Table 6.13).  The domain type will be defined by a corresponding vocabulary.

 

 

9.6.2

comment

As per structure 13.2 (Table 6.13).

 

 

9.6.3

contentype

As per structure 13.3 (Table 6.13).

 

 

9.6.4

date

Recorded dates appropriate to the affiliation.

O

n

As per structure 13.6 (Table 6.13).

 

 

9.6.5

status

Recorded status of the role.

O

n

As per structure 13.8 (Table 6.13).

 

 

9.6.6

description

The description of the affiliation.

O

As per structure 13.5 (Table 6.13).

 

 

9.6.7

role

This recursive reference enables sub-roles to be defined.

O

n

As per structure in 9.6.

 

 

9.6.8

extension

The extension facility for the ‘role’ learner information.

O

As per structure 13.16 (Table 6.13).

 

 

9.7

organisation

The organisation to which the learner is affiliated.

O

As per structure 13.14 (Table 6.13).

 

 

9.8

date

Recorded dates appropriate to the affiliation.

O

n

As per structure 13.6 (Table 6.13).

 

 

9.9

status

Recorded status of the affiliation.

O

As per structure 13.8 (Table 6.13).

 

 

9.10

description

The description of the affiliation.

O

As per structure 13.5 (Table 6.13).

 

9.11

affiliation

This recursive reference enables arbitrarily complex affiliation structures to be constructed.

O

n

As per structure in Table 6.9.

 

9.12

extension

The extension facility for the ‘affiliation’ learner information.

O

As per structure 13.16 (Table 6.13).

6.3.10     ‘transcript’ Data Structure

Table 6.10 describes the transcript learner information data structures.

Table 6.10  ‘transcript’ learner information data structure detailed description.

No

Name

Explanation

Reqd

Mult

Type

Note

10.1

typename

The type of transcript.

O

As per structure 13.4 (Table 6.13).  The domain type is defined according to an agreed vocabulary.

10.2

comment

As per structure 13.2 (Table 6.13).

10.3

contentype

As per structure 13.3 (Table 6.13).

10.4

exrefrecord

The transcript itself using an appropriate externally defined structure.

O

As per structure 13.15 (Table 6.13).

 

10.5

description

The description of the transcript.

O

As per structure 13.5 (Table 6.13).

10.6

extension

The extension facility for the ‘transcript’ learner information.

O

As per structure 13.16 (Table 6.13).

 

6.3.11     ‘securitykey’ Data Structure

Table 6.11 describes the securitykey learner information data structures.

Table 6.11  ‘securitykey’ learner information data structure detailed description.

No

Name

Explanation

Reqd

Mult

Type

Note

 

11.1

typename

The type of security key

O

As per structure 13.4 (Table 6.13).  The domain type is defined using an appropriate vocabulary.

11.2

comment

As per structure 13.2 (Table 6.13).

11.3

contentype

As per structure 13.3 (Table 6.13).

11.4

keyfields

The classification of the key e.g. ‘PKC’, password, etc.

O

n

 

11.4.1

fieldlabel

The classification of the key e.g. ‘PKC’, password, etc.

M

As per structure 13.10 (Table 6.13).

 

11.4.2

fielddata

The key data itself e.g. the actual password or the encryption key.

M

As per structure 13.11 (Table 6.13).

 

11.5

description

The description of the key

O

As per structure 13.5 (Table 6.13).

11.6

extension

The extension facility for the ‘securitykey’ learner information.

O

As per structure 13.16 (Table 6.13).

 

6.3.12     ‘relationship’ Data Structure

Table 6.12 describes the relationship learner information data structures.

Table 6.12  ‘relationship’ learner information data structure detailed description.

No

Name

Explanation

Reqd

Mult

Type

Note

12.1

typename

The type of relationship

O

As per structure 13.4 (Table 6.13).  The domain type is to be defined according to an agreed vocabulary.

12.2

comment

As per structure 13.2 (Table 6.13).

12.3

contentype

As per structure 13.3 (Table 6.13).

12.4

tuple

The tuple that defines the required one to many relationship.

O

The tuple is defined as tuplesource, tuplerelationship, tupledestination and describes the relationship between the tuplesource and one or more tupledestination.

 

12.4.1

tuplesource

The source component for the relationship.

M

The source is defined by either a ‘sourcedid’ with an ‘indexid’ or just an ‘indexid’.

 

12.4.1.1

sourcedid

The ‘sourcedid’ of the learner information acting as the source of the relationship. 

O

As per structure 13.3.1.1 (Table 6.13).

 

12.4.1.2

indexid

A unique identifier for the source relationship

M

As per structure 13.3.1.2 (Table 6.13).

 

12.4.2

tuplerelation

The relationship between the source and destination(s) entities.

M

The type of relationship will be defined by an appropriate vocabulary.

 

12.4.2.1

typename

The vocabulary that is to be used to define the type of relationship.

O

As per structure 13.4 (Table 6.13).  The domain type is to be defined according to an agreed vocabulary.

 

12.4.2.2

text

The relationship type selected from the vocabulary.

O

As per structure 13.13 (Table 6.13).

 

12.4.3

tupledest

The destination component for the relationship.

M

n

The source is defined by either a ‘sourcedid’ with an ‘indexid’ or just an ‘indexid’.

 

12.4.3.1

sourcedid

The ‘sourcedid’ of the learner information acting as the destination of the relationship. 

O

As per structure 13.3.1.1 (Table 6.13).

 

12.4.3.2

indexid

A unique identifier for the source relationship

M

As per structure 13.3.1.2 (Table 6.13).

 

12.5

description

The description of the relationship.

O

As per structure 13.5 (Table 6.13).

12.6

extension

The extension facility for the ‘relationship’ learner information.

O

As per structure 13.16 (Table 6.13).


6.3.13     Common Data Objects

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

Table 6.13  Common data objects detailed description.

 

No

Name

Explanation

Reqd

Mult

Type

Note

 

13.1

langtype

The language that is being used for the information.

M

String.

The language entries will be defined as per the ISO standard.

 

13.2

comment

Comments of the LIP information.  These comments are not removed by a parser.

O

String.

These comments should be used to annotate the XML files.

13.2.1

langtype

The default language used for the comment.

As per structure 13.1 (Table 6.13).

 

 

13.3

contentype

The data that is used to describe the contents of the learner information structures.

O

The referential information must always be defined.  All other entries are optional.

 

13.3.1

referential

Reference information that is used to uniquely identify the learner information and the data structures within it.

M

n

An entry may be allocated more than one ‘sourcedid’ or ‘indexid’.

 

13.3.1.1

sourcedid

The initiating system’s source identification for the learner information.

C

If the entry is not defined as a ‘sourcedid’ it MUST be an ‘indexid’.

 

13.3.1.1.1

source

The name of the source system creating the learner information.

M

#PCDATA
1-256 chars.

The allocation of this name to the source is beyond the scope of this specification.

 

13.3.1.1.2

id

A unique identifier for the learner information record assigned by the creating entity.

M

ID
1-256 chars.

The uniqueness of the ‘id’ is enforced by the XML parser with respect to the XML file only.  This identifier should be persistent for usage between transaction messages.

 

13.3.1.2

indexid

A unique identifier for the actual data structure containing the learner information content.  This identifier is persistent and so mapping tables should be maintained to allow the identifier to be used in subsequent transactions.

C

ID
1-256 chars.

The uniqueness of the ‘id’ is enforced by the XML parser with respect to the XML file only.

If the entry is not defined as ‘indexid’ it MUST be a ‘sourcedid’.

 

13.3.2

temporal

Data describing time-based information about the data structure e.g. time of creation, date of expiry, etc.

O

n

If the expire date is undefined then the information is assumed to have an infinite period of validity.

Several different temporal definitions may be defined for a structure e.g. time of creation, and expiry date.

 

13.3.2.1

typename

The type of temporal relationship

M

The domain type is to be defined according to an agreed vocabulary (see Section 7).

 

13.3.2.2

temporalfield

The fields defined to contain the temporal data structures.

M

n

 

13.3.2.2.1

fieldlabel

The field type that will contain the temporal definition data.

M

As per structure 13.10.

 

13.3.2.2.2

fielddata

The field type that will contain the temporal data.

M

As per structure 13.11.

 

13.3.3

privacy

Data that is to be used to describe the access to and to ensure the integrity of the learner information.

O

The meaning of the content for each of these fields is beyond the scope of this specification.

 

13.3.3.1

privacyfield

The fields defined to contain the privacy data structures.

M

n

 

13.3.3.1.1

fieldlabel

The field type that will contain the privacy definition data.

M

As per structure 13.10.

 

13.3.3.1.2

fielddata

The field type that will contain the privacy data.

M

As per structure 13.11.

 

13.3.3.3

date

Dates appropriate to the privacy information e.g. expiry

O

n

As per structure 13.6 (Table 6.13).

 

 

13.4

typename

The label of the object whose type is being defined.

O

The naming convention should reflect the usage of the name.  See Section 7 for a further explanation of the vocabularies that must be supported.

 

13.4.1

tysource

The source of the vocabulary.

O

Contains either the vocabulary itself or the name of the external file containing vocabulary.

 

13.4.1.1

sourcetype

Reference to web-page or file that contains the appropriate vocabulary.

O

Enumerated list of:

imsdefault (default)

standard

list

proprietary

If the ‘list’ value occurs then the vocabulary is included as a character separated list.  See Section 7 for more information on the vocabularies.  If unused then the data is the single word entry.

 

13.4.2

tyvalue

The textual entry for the selected type.

M

String.
1-256 chars.

This will have an associated language string.

13.4.2.1

langtype

The default language used for the typing data.

As per structure 13.1 (Table 6.13).

 

 

13.5

description

The description (text image etc.) of the associated information.

O

 

13.5.1

short

A one line, text description.

M

String.
1-128 chars.

13.5.1.1

langtype

The default language used for the short description.

As per structure 13.1 (Table 6.13).

 

 

13.5.2

long

A detailed textual description.

O

String.
1-2048 chars.

13.5.2.1

langtype

The default language used for the typing data.

As per structure 13.1 (Table 6.13).

 

 

13.5.3

full

A full description of the activity, etc. using text, images, etc.

O

 

13.5.3.1

comment

As per structure 13.2.

 

13.5.3.2

media

The content placeholder for all text, image, video, etc. materials.

M

n

As per structure 13.12.

 

13.6

date

The date and/or time to be recorded.

O

 

13.6.1

typename

The type of date.

O

As per structure 13.4.  The domain type is to be defined according to an agreed vocabulary.

 

13.6.2

datetime

The underlying string structure is: YYYY:MM:DDTHH:MM:SS

M

String.
1-20 chars.

As defined by the ISO8601. 

 

13.6.3

description

The description of the date.

O

As per structure 13.5.

 

13.6.4

extension

The extension facility for the ‘date’ learner information.

O

As per structure 13.16.

 

13.7

priority

The priority of the event, activity, goal, etc.

O

String.
1-64 chars.

13.7.1

langtype

The default language used for the priority.

As per structure 13.1 (Table 6.13).

 

 

13.8

status

The status of a particular event, activity, goal, etc.

O

 

13.8.1

typename

The type of status.

O

As per structure 13.4.  The domain type is to be defined according to an agreed vocabulary.

 

13.8.2

date

The date that the status entry was made.

O

As per structure 13.6.

 

13.8.3

description

The status entry.

O

As per structure 13.5.

 

13.9

product

These are the electronic forms of the materials created as part of the activity e.g. a report, diagram, etc.

O

 

13.9.1

typename

The type of product.

O

As per structure 13.4.  The domain type is to be defined according to an agreed vocabulary.

 

13.9.2

comment

As per structure 13.2.

 

13.9.3

contentype

As per structure 13.3.

 

13.9.4

date

Dates relevant to the product e.g. date of creation.

O

As per structure 13.6.

 

13.9.5

description

The product itself.

O

As per structure 13.5.

 

13.9.6

extension

The extension facility for the ‘product’ learner information.

O

As per structure 13.16.

 

13.10

fieldlabel

Field definition extensions.

O

n

This information must be agreed by the communicating systems.  This structure is used to allow controlled extensions to the reference information.

 

13.10.1

typename

The vocabulary for the field.

O

As per structure 13.4.

 

13.11

fielddata

The data for that field.

O

n

#PCDATA

Its format will generally be either a text string or numerical.

 

13.12

media

The content placeholder for all text, image, video, etc. materials.

C

 

13.12.1

mediamode

The type of media data being stored e.g. text, image, etc.

M

Enumerated list of: text, video, audio, image, applet and application.

 

13.12.2

contentreftype

The type of the information i.e. embedded or external reference.

O

Enumerated list of: uri, entityref Base-64.  The default is Base-64.

 

13.12.3

mimetype

The mime type of the information to be stored.

M

As per MIME under RFC1521.

 

13.13

text

Text to be stored.

O

n

String.

The text could be embedded within the file itself or referenced using a URL.

13.13.1

langtype

The default language used for the text.

As per structure 13.1 (Table 6.13).

 

 

13.13.2

uri

External file reference to the associated text to be stored in the record.

O

String.
1-128 chars.

 

13.13.3

entityref

External file reference to the associated text to be stored in the record.

O

String.
1-128 chars.

This makes use of the XML ENTITY structure.

 

13.14

organization

The identification of the associated organisation.

C

String.
1-128 chars.

 

13.14.1

typename

The type of the organisation.

O

As per structure 13.4.  The domain type will be defined from an appropriate vocabulary.

 

13.14.2

description

The description of the organisation.

O

As per structure 13.5 (Table 6.13).

 

13.15

exrefrecord

The external record format and structure used to store the information.

O

 

13.15.1

comment

As per structure 13.2 (Table 6.13).

 

13.15.2

recformat

The format of the external record.

M

ANY

The content of this element can take any form.

 

13.15.2.1

uri

Uri of the file that contains the format information.

O

String.
1-256 chars.

 

13.15.2.2

entityref

External file reference to the associated text to be stored in the record.

O

String.
1-128 chars.

This makes use of the XML ENTITY structure.

 

13.15.3

recdata

The content of the external record.

M

ANY

The content of this element can take any form.

 

13.15.3.1

uri

Uri of the file that contains the data itself.

O

String.
1-256 chars.

 

13.15.3.2

entityref

External file reference to the associated text to be stored in the record.

O

String.
1-128 chars.

This makes use of the XML ENTITY structure.

 

13.15.4

date

Recorded dates appropriate to the record.

O

n

As per structure 13.6 (Table 6.13).

 

13.15.5

description

The description of the external record.

O

As per structure 13.5 (Table 6.13).

 

13.15.6

extension

The extension facility for the ‘exrefrecord’ learner information.

O

As per structure 13.16 (Table 6.13).

 

13.16

extension

Proprietary extension facility to support implementation specific features.

O

C

ANY

Each of the extensions within the information model have their own XML bind realisation.  These elements are described in Table 6.14.

 

6.3.14     ‘extension’ Definitions

Table 6.14 lists the set of extension names that are used within the XML Binding.  These names are mapped to the ‘extension’ element used within Tables 6.1 to 6.13 of the Information Model.

Table 6.14  List of extensions.

No

Name

Source Element

Usage

14.1

ext_accessibility

accessibility

Extension for the ‘Accessibility’ core data structure.

14.2

ext_activity

activity

Extension for the ‘Activity’ core data structure.

14.3

ext_affiliation

affiliation

Extension for the ‘Affiliation’ core data structure.

14.4

ext_competency

competency

Extension for the ‘Competency’ core data structure.

14.5

ext_contentype

contentype

Extension for the ‘Contentype’ meta-data structure.

14.6

ext_date

date

Extension for the ‘Date’ common data structure.

14.7

ext_definition

definition

Extension for the ‘Definition’ data object within the ‘Activity’ core data structure.

14.8

ext_disability

disability

Extension for the ‘Disability’ data object within the ‘Accessibility’ core data structure.

14.9

ext_eligibility

eligibility

Extension for the ‘Eligibility’ data object within the ‘Accessibility’ core data structure.

14.10

ext_evaluation

evaluation

Extension for the ‘Evaluation’ data object within the ‘Activity’ core data structure.

14.11

ext_exrefrecord

exrefrecord

Extension for the ‘Exrefrecord’ data object within the ‘Competency’ and ‘Transcript’ core data structures.

14.12

ext_goal

goal

Extension for the ‘Goal’ core data structure.

14.13

ext_identification

identification

Extension for the ‘Identification’ core data structure.

14.14

ext_interest

interest

Extension for the ‘Interest’ core data structure.

14.15

ext_language

language

Extension for the ‘Language’ data object within the ‘Accessibility’ core data structure.

14.16

ext_learnerinfo

learnerinfo

Extension for the IMS LIP top-level data structure i.e. an alternative to the eleven core data structures.

14.17

ext_objectives

objectives

Extension for the ‘Objectives’ data object within the ‘Evaluation’ data object.

14.18

ext_preference

preference

Extension for the ‘Preference’ data object within the ‘Accessibility’ core data structure.

14.19

ext_product

product

Extension for the ‘Product’ data object within the ‘Activity’ and ‘Interest’ core data structures.

14.20

ext_qcl

qcl

Extension for the ‘Qcl’ core data structure.

14.21

ext_relationship

relationship

Extension for the ‘Relationship’ core data structure.

14.22

ext_role

role

Extension for the ‘Role’ data object within the ‘Affiliation’ core data structure.

14.23

ext_securitykey

securitykey

Extension for the ‘Securitykey’ core data structure.

14.24

ext_testimonial

testimonial

Extension for the ‘Testimonial’ data object within the ‘Activity’ core data structure.

14.25

ext_transcript

transcript

Extension for the ‘Transcript’ core data structure.

7.     IMS Supported LIP Vocabularies & Taxonomies

Within the LIP there are many special vocabularies that are required to define the specific type of information being included.  These vocabularies and their default IMS file name are listed in Table 7.1.

Table 7.1  ‘typename’ list of vocabularies.

No

Source Element

File Name

Default Vocabulary

1

activity

imslipv1p0_activity.txt

Work, Service, Education, Training, Military

2

address

imslipv1p0_address.txt

Work, Permanent, Private, Temporary, Mailing, Campus, Billing

3

affiliation

imslipv1p0_affliliation.txt

Professional, Personal[3], Military, Civic

4

agent

imslipv1p0_agent.txt

Parent, Guardian, Proxy, Aide, Advisor, Tutor, Mentor, Sponsor

5

agentdomain

imslipv1p0_agentdomain.txt

Legal, Medical, Financial, Accessibility, Educational

6

contactinfo[4]

imslipv1p0_contactinfo.txt

Private, Work, Campus

7

date

imslipv1p0_date.txt

Effective[5], Birth, Start, Finish, Expiry, Death, Update, Create, Renewal, Delete, Publish, Award, Enrol, Join

8

definition

imslipv1p0_definition.txt

Class, Course, Curriculum, Module, Topic, Unit

9

demographics

imslipv1p0_demographics.txt

Adult, Mature, College, Primary, Secondary, Preschool, Nursery, University, Vocational, Enrichment, Graduate, Professional, Technical

10

disability

imslipv1p0_disability.txt

For further study in V2.0[6]

11

eligibility

imslipv1p0_eligibility.txt

For further study in V2.0[7]

12

evaluation[8]

imslipv1p0_evaluation.txt

QTI_Assessment, QTI_Section, QTI_Item

14

goal

imslipv1p0_goal.txt

Work, Education, Personal

15

interest

imslipv1p0_interest.txt

Recreational, Vocational, Domestic

16

language

imslipv1p0_language.txt

Use the ISO Standard terminology

17

name

imslipv1p0_name.txt

Contact, Full, Alias, Maiden, Preferred, Former

18

organization

imslipv1p0_organization.txt

Professional, Employer, Government, Recreational, Educational, Training, Military

19

partname

imslipv1p0_partname.txt

Particle[9], Prefix, Suffix, Given, Middle, Surname, Nickname, Last, First, Family, Maternal, Paternal, Initials

20

preference

imslipv1p0_preference.txt

Cognitive, Physical, InputTech, OutputTech

21

privacy

imslipv1p0_privacy.txt

Creator, Owner, Steward, Learner, Default, [All][10]

22

product

imslipv1p0_product.txt

Exam, Coursework, Portfolio, Participation

23

qcl

imslipv1p0_qcl.txt

Qualification, Certification, Licence, Degree

24

relationship

imslipv1p0_relationship.txt

Activity, Accessibility, Affiliation, Competency, Goal, Identification, Interest, Qcl, Securitykey, Transcript

25

representation

imslipv1p0_representation.txt

Photo, Voice, Biometric, Signature

26

role

imslipv1p0_role.txt

Administrative, Executive, Officer, Representative, Member

27

securitykeys

imslipv1p0_securitykeys.txt

Password, Certificates, PIN, Username

28

status

imslipv1p0_status.txt

Active, Inactive, Retired, Completed, InProgress, Pending, Expired

29

temporal

imslipv1p0_temporal.txt

Expiry, Creation, Update, Purge

30

testimonial

imslipv1p0_testimonial.txt

Academic, Personal, Work, Military, Service

31

transcript

imslipv1p0_transcript.txt

Academic, Vocational, Training

These default file names are used when the ‘sourcetype’ attribute has the value ‘imsdefault’ assigned to it.  These file names are not to be included in the XML instance and thus binding must be achieved indirectly by the parsers of the instance.

Note:      We recognise that the vocabularies currently defined are inadequate for many systems.  We will expand and amend these vocabularies as we receive direction from adopters of the specification.  Please contact IMS to suggest amendments to these vocabularies.

In a later release of the specification we will include a more formal definition of the vocabulary files.  This will be based upon XML.

8.     Meta-data Descriptions

There is one type of meta-data included explicitly in this specification:

8.1     IMS Meta-data Inclusion

The IMS Meta-data elements are not supported directly within the IMS LIP.  This is because IMS LIP instances will be packaged using the IMS Content Packaging specification.  The IMS Content Packaging specification already defines how IMS Meta-data should be included.

9.     Conformance

The purpose of this conformance statement is to provide a mechanism for customers to fairly compare vendors of Learner Information content and tools.  It is not required for a vendor to support every feature to claim conformance, however, a vendor must detail their level of conformance with a “Conformance Statement”.   As such this is an Informative Conformance statement only.

9.1     Valid Data Issues

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

9.2     Conformance Statement

Vendors claiming conformance must provide a “Conformance Statement”, detailing their level of conformance.  The Conformance Statement takes the form of twelve tables, namely:

In each table the relevant tick-boxes are checked to indicate that the corresponding property is supported.  The conformance statement then becomes the collection of the checked tick-boxes.

9.2.1       Learnerinformation Conformance Statement Table

Table 9.1  Learnerinformation conformance statement table.

Learnerinformation

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

empty check box contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  identification

empty checkbox  accessibility

empty checkbox  goal

empty checkbox  qcl

empty checkbox  activity

empty checkbox  competency

empty checkbox  interest

empty checkbox  affiliation

empty checkbox  transcript

empty checkbox  securitykey

empty checkbox  relationship

       

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

        Vocabularies

<empty checkboxtypename

Functions

empty checkbox  ext_learnerinfo

     

9.2.2       Accessibility Conformance Statement Table

empty checkbox

Table 9.2  Accessibility conformance statement table.

Accessibility

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

empty checkbox  contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  language

empty checkbox  preference

       

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

        Vocabularies

empty checkboxtypename

Functions

empty checkboxext_accessibility 

empty checkboxext_language

empty checkbox  ext_preference

empty checkboxext_disability

empty checkbox  ext_eligibility

 

9.2.3       Activity Conformance Statement Table

Table 9.3  Activity conformance statement table.

Activity

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

empty checkbox  contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  date

empty checkbox  status

empty checkbox  units

empty checkbox  learningrefactivity

empty checkbox  product

empty checkbox  definition

empty checkbox  evaluation

empty checkbox  testimonial

empty checkbox  status

empty checkbox  description

       

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

        Vocabularies

empty checkboxtypename

Functions

empty checkboxext_activity

empty checkbox  ext_definition

empty checkbox  ext_product

empty checkbox  ext_testimonial

empty checkbox  ext_evaluation

9.2.4       Affiliation Conformance Statement Table

Table 9.4  Affiliation conformance statement table.

Affiliation

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

empty checkbox  contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  affiliationid

empty checkbox  role

empty checkbox  organization

empty checkbox  date

empty checkbox  status

empty checkbox  description

       

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

        Vocabularies

empty checkboxtypename

Functions

empty checkboxext_affiliation

empty checkbox  ext_role


9.2.5       Competency Conformance Statement Table

Table 9.5  Competency conformance statement table.

Competency

 

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

empty checkbox  contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  exrefrecord

empty checkbox  description

       

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

        Functions

empty checkboxext_competency

empty checkboxext_exrefrecord

9.2.6       Goal Conformance Statement Table

Table 9.6  Goal conformance statement table.

Goal

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

empty checkbox  contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  date

empty checkbox  priority

empty checkbox  status

empty checkbox  description

       

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

        Vocabularies

empty checkboxtypename

Functions

empty checkboxext_goal

 


9.2.7       Identification Conformance Statement Table

Table 9.7  Identification conformance statement table.

Identification

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

empty checkbox  contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  formname

empty checkbox  name

empty checkbox  contactinfo

empty checkbox  telephone

empty checkbox  facsimile

empty checkbox  mobile

empty checkbox  pager

empty checkbox  email

empty checkbox  web

empty checkbox  address

empty checkbox  pobox

empty checkbox  street

empty checkbox  locality

empty checkbox  city

empty checkbox  country

empty checkbox  statepr 

empty checkbox  region

empty checkbox  postcode

empty checkbox  timezone

empty checkbox  geo

empty checkbox  demographics

empty checkbox  representation

empty checkbox  gender

empty checkbox  date

empty checkbox  uid

empty checkboxagent

empty checkbox  agentid

empty checkbox  agentdomain

empty checkbox  description

       

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

        Vocabularies

empty checkboxtypename

Functions

empty checkboxext_identification

 

9.2.8       Interest Conformance Statement Table

Table 9.8  Interest conformance statement table.

Interest

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

empty checkbox  contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  product

empty checkbox  description

       

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

        Vocabularies

empty checkboxtypename

Functions

empty checkboxext_interest

empty checkboxext_product


9.2.9       Qcl Conformance Statement Table

Table 9.9  Qcl conformance statement table.

Qcl

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

empty checkbox  contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  title

empty checkbox  organization

empty checkbox  registrationno

empty checkboxlevel

empty checkboxdate

empty checkbox  description

       

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

        Vocabularies

empty checkboxtypename

Functions

empty checkboxext_qcl

9.2.10     Relationship Conformance Statement Table

Table 9.10  Relationship conformance statement table.

Relationship

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

empty checkbox  contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  tuplesource

empty checkbox  tuplerelation

empty checkbox  tupledest

empty checkbox  description

       

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

        Vocabularies

empty checkboxtypename

Functions

empty checkboxext_relationship

 

9.2.11     Securitykey Conformance Statement Table

Table 9.11  Securitykey conformance statement table.

Goal

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

empty checkbox  contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  keyfields

empty checkbox  description

       

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

        Vocabularies

empty checkboxtypename

Functions

empty checkboxext_securitykey

9.2.12     Transcript Conformance Statement Table

Table 9.12  Transcript conformance statement table.

Transcript

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

empty checkbox  contentype

empty checkbox  referential

empty checkbox  temporal

empty checkbox  privacy

empty checkbox  comment

empty checkbox  exrefrecord

empty checkbox  description

       

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

        Vocabularies

empty checkboxtypename

Functions

empty checkboxext_transcript

empty checkboxext_exrefrecord

Appendix A - Object Model Representation

Figure A1 shows an object-oriented perspective of the LIP specification.

Object oriented representation of the LIP specification

Figure A1  Object oriented representation of the LIP specification.

The different classes and their functional capabilities are:

learnerinformation-The data structure responsible for encapsulating the eleven core learner information classes.  The control information describing the learner information as a whole is contained within the ‘contentype’ class;

identification-The learner information that contains all of the data for a specific individual or organisation.  This includes data such as: names, addresses, contact information, agent and demographics;

accessibility-The learner information that consists of the cognitive, technical and physical preferences for the learner, their language capabilities, disability and eligibilities;

goal-This learner information consists of the description of the personal objectives and aspirations.  These descriptions may also include information for monitoring the progress in achieving those goals.  A goal can be defined in terms of sub-goals;

qcl-This learner information consists of the qualifications, certificates and licenses awarded to the learner i.e. the formally recognised products of their learning and work history.  This includes information on the awarding body and may also include electronic copies of the actual documents;

activity-The learner information that consists of the education/training, work and service (military, community, etc.) record and products (excluding formal awards).  This may include the descriptions of the courses undertaken and the records of the corresponding evaluation;

transcript-The summary record of the academic performance of an individual with respect to a particular institution.  The transcript is normally supplied by the body responsible for evaluating of the performance of the individual;

competency-This learner information consists of the descriptions of the skills the learner has acquired.  These skills may be associated with some formal or informal training or work history (described in the ‘activity’) and formal awards (described in the ‘qcl’).  The corresponding level of competency may also be defined;

interest-The learner information that consists of descriptions of the hobbies and other recreation activities.  These activities may have formal awards (as described in the associated ‘qcl’).  Electronic versions of the products of these interests may also be contained;

affiliation-This learner information is used to store the descriptions of the affiliations associated with the learner e.g. professional affiliations.  A learner’s membership of the relevant class, cohorts, groups, etc. undertaken when being educated, trained, etc. should be supported using the IMS Enterprise specification;

securitykey-This learner information is used to store the descriptions of the passwords, encryption keys and authentication keys.  These keys are used for transactions with the learner;

relationship-The container for the definition of the relations between the other core data structures e.g. ‘qcl’s and the awarding organisation.  This enables the construction of complex relationships between the core data structures;

contentype-The container for the control information that is used to describe the learner information.  This information consists of referential, temporal and privacy information and is applied to each of the ‘atomic’ parts of the learner information structure;

referential-The referential information is used to uniquely identify the learner information record as a whole and the individual data components within that record.  These enable each piece of information to be identified.  The actual identification system is outside the scope of this specification;

temporal-This information is used to describe any time-based dependencies of the data.  This includes information such as the date of creation, time-stamp and expiry date of the learner information.  The date/time descriptions are expected to conform to the ISO8601 standard;

privacy-All of the data relevant to the privacy, authenticity and integrity of the learner information is contained within this structure.  The actual privacy etc. mechanism and architectures used to support the learner information are outside of the scope of the specification but they interact with the learner information through these structures.



[1] Version 1.0 of the IMS LIP specifications is focussed on the Learners.  Producer related learner information will be addressed in later versions.

[2] The method of visualisation is similar to that developed by the IEEE Public and Private Information (PAPI) working-group.

[3] This would be used for affiliations such as ‘Garden Club’, ‘Astronomical Society’, etc.

[4] The contact information is considered to be electronic in nature whereas the address refers to physical location and postal contact.

[5] The usage of the ‘Effective’ date is combined with an associated status to produce a time-based perspective e.g. an ‘Effective’ date with a status of ‘Completion’ would be equivalent to the ‘Finish’ date.

[6] The <disability> vocabulary will be informed by work from the IMS Accessibility specification.

[7] The <eligibility> vocabulary will be developed as part of later releases of this specification.

[8] The <evaluation> vocabulary is currently defined to support the IMS QTI specification data structures for results interoperability.  This vocabulary needs further development.

[9] The ‘Particle’ component refers to name parts such as ‘von’, ‘van’, etc.

[10] The ‘All’ entry for the privacy entry means that the data is available to everyone.

About This Document

 
Title IMS Learner Information Package
Information Model Specification
Authors Colin Smythe, Frank Tansey and Robby Robson
Version 1.0
Version Date 9thMarch, 2001
Status Final Specification.
Summary This document describes the IMS Learner Information Package Information Model that is used to support interoperability between learner information management systems.
Revision Information Last revised 9th March, 2001
Purpose Defines the Learner Information Package Information Model.
Document Location http://www.imsglobal.org/profiles/lipinfo01.html.

List of Contributors

The following individuals contributed to the development of this document:

Susan Beidler PeopleSoft,USA
Geoff Collier Saba Software, USA
Andy Heath JISC/CETIS,UK
Wayne Martin Miami-Dade Community College, USA
Bill Olivier JISC/CETIS,UK
Tom Probert Enterprise Computing, USA
Rob by Robson Saba Software, USA
Colin Smythe Dunelm Services, UK
Frank Tansey IMS, USA
Tom Wason IMS, USA     

Revision History

 

Version No.

Release Date

Comments

Base Document v1.0

9th August, 2000

This is the first version of the IMS LIP Information Model Base Document.

Public Draft Specification v1.0

21st December, 2000

This is the first publicly available version of the IMS LIP Information Model Public Draft Specification.

Final Specification v1.0

9th March, 2001

Version 1.0 of the IMS LIP Information Model Final Specification.

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Learner Information Package Information Model ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

IMS makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

IMS would appreciate receiving your comments and suggestions.

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

Please refer to Document Name:
IMS Learner Information Package Information Model v1 Revision: March 2001