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

If you wish to distribute this document or use this document to implement a product or service, you must complete a valid license registration with IMS and receive an email from IMS granting the license. 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 Licensee organizations 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 work 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/profiles/lipv1p0/lipv1p0speclicense.html.

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

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

Table of Contents

1. INTRODUCTION

1.1 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:

• Recording and managing learning-related history, goals, and accomplishments;

• Engaging a learner in a learning experience;

• Discovering learning opportunities for learners.

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:

• Distributed information: A learner information system may in fact consist of multiple distributed systems that share learner information or that store learner information in a distributed fashion.  This necessitates the inclusion of adequate indexing and time stamping of learner information data as it is packaged;

• Scalability: To support large-scale systems it is necessary to exchange and reassemble chunks of arbitrary granularity as well as bulk transfer.  Packaging of multiple LIPs will use the IMS Content &Packaging specification;

• Privacy and Data Protection: Learner information systems must be able to implement privacy and data protection policies and insure the integrity of data;

• Flexibility and External references: Learner information includes many constructs, such as learning objectives and learning history, which are in practice represented by different structures in different contexts.  Learner information data models must be flexible enough to accommodate this need.

Privacy and Data Protection

The IMS project recognizes the need to:

• Maintain the privacy of learner information;

• Protect information from inappropriate access;

• Ensure the integrity of information;

• Accommodate the regulatory policies and requirements of different jurisdictions.

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:

• Time-related information; 

• Identification and indexing information;

• Privacy and data protection information.

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:

• A tree;

• An object model;

• A tabular representation.

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.

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

• Identification: Biographic and demographic data relevant to learning;

• Goal: Learning, career and other objectives and aspirations;

• Qualifications, Certifications and Licenses (qcl): Qualifications, certifications and licenses granted by recognized authorities;

• Activity: Any learning-related activity in any state of completion.  Could be self-reported.  Includes formal and informal education, training, work experience, and military or civic service;

• Transcript:  A record that is used to provide an institutionally-based summary of academic achievement.  The structure of this record can take many forms;

• Interest: Information describing hobbies and recreational activities;

• Competency: Skills, knowledge, and abilities acquired in the cognitive, affective, and/or psychomotor domains; 

• Affiliation: Membership of professional organizations, etc.  Membership of groups is covered by the IMS Enterprise specification;

• Accessibility: General accessibility to the learner information as defined through language capabilities, disabilities, eligibilities and learning preferences including cognitive preferences (e.g. issues of learning style), physical preferences (e.g. a preference for large print), and technological preferences (e.g. a preference for a particular computer platform);

• Securitykey:  The set of passwords and security keys assigned to the learner for transactions with learner information systems and services;

• Relationship:  The set of relationships between the core components.  The core structures do not have within them identifiers that link to the core structures.  Instead all of these relationships are captured in a single core structure thereby making the links simpler to identify and manage.

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:

• Time Information: Time of creation and time of expiration of a piece of data;

• Index and Source: Supports a pair consisting of a source and an ID assigned by that source, a local index that is used for cross-referencing, and a URI;

• Privacy and data protection information: Unstructured data to be determined by practice and implementation.

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:

• IMS Learner Information Package XML Binding Final Specification v1.0;

• IMS Learner Information Package Best Practice & Implementation Guide Final Specification v1.0.

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.

Figure 2.1  Learner information system component representation.

The key components of the learner information system are:

• Local learner information system - local server(s) that are directly accessible by the corresponding user community;

• Remote learner information system - a reflection of the distributed nature of a learner information server i.e. different parts of the ‘learner information’ could be stored on several servers;

• Other systems - others systems that may be interconnected to the learner information servers e.g. e-mail.  The interfaces to these systems are beyond the scope of this specification;

• Data structures
  • Learner info - the actual learner information data itself
  • Access - the access rights to the learner information data i.e. who can see what
  • Messaging - the messaging protocol used to implement the actual profile interchanges;

• Actors - the different roles of the users accessing a profile server.  The different actors shown in Figure 2.1 are not an exhaustive list.  The actors will access the system through a ‘GUI’.

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:

• Education record - the record of educational achievement from school through to college/university.  The different education systems throughout the world need to be supported;

• Training log - the record of training activities undertaken e.g. courses carrying formal certification;

• Professional development record - the record of professional development activities undertaken including membership in the appropriate professional bodies;

• Resume/CV - a record of personal achievement that includes relevant work experience, qualifications and education history.  Different types of resumes need to be supported e.g. business, academic, medical, etc;

• Life-long learning record - a cradle-to-grave record of the learning activities and achievements of an individual.  The time-related nature of the record is reflected by the sequential nature of the information and the tagging of the specific record by its date of entry;

• Community service record - a record of the community-oriented activities of an individual and the corresponding work and training experience.

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 3^rd party.  Certified 3^rd 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:

• Creators – Developers of learning content, such as a corporation that developed a class, or a digital photographer providing JPEG materials;

• Providers – The organisation that delivers learning content to the learner, such as a corporate training department, a university, or a tutor;

• Vendors – An entity offering products in support of a learning environment, such as software tools used for content development, enterprise systems, etc.

Table 2.1  Learner information general categories.^[1]

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:

• Individual perspective - the process that would be undertaken for an individual who is applying for a job and wishes to include their appropriate educational/work history in their application;

• Vendor perspective - the processes that may be supported by vendor products that wish to supply human resource management systems and student administration systems;

• UK Higher Education (Inter-organisational) - learner information that must be exchanged between organisations i.e. via the ‘Internet’;

• Career management - a record of career achievements, and associated planning and monitoring of career goals and objectives;

• Training group management - the management of groups undergoing training e.g. a group of employees who are undergoing induction training.

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:

• Most organizations go through a yearly review process at which time the employee and manager agree on the work products and competencies achieved in the prior review period and plan future objectives, including education and training goals.  The employee’s competency, skills and/or education record is updated (currently, this is generally a manual process), but some aspects of the records could be updated through a message from a learning management system used by the training/education provider.  This example illustrates the creation and update of the learner information;

• Most organizations attempt to track an employee’s training and educational efforts; in many industries this is mandated.  The training administration system at an organization, often part of the overall HRMS, should provide profile information about learner preferences, certifications and licenses, current training involvement and training/education needs.  This data should be sent to the training provider so a tailored learning experience can be created, perhaps even including the “membership” for the training event.  The training provider, in turn, returns the information about certifications achieved, classes completed and so on.  This data should update the employee learner information on the organization’s HRMS or training administration system;

• The organization’s recruitment function is directly impacted by the exchange of learner information; in fact, a simple way to describe a profile is to compare it to a resume or CV.  Most major organizations now receive applications and resumes electronically; the electronic format allows them to systematically populate the applicant’s record on the HRMS database so targeted searches can be performed by the hiring manager.  As more organizations use the online “exchanges” to look for employees, we can envision the transfer of the profile information from the exchange to the hiring organization’s database as the recruitment process is finalized.

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: 

• The learner information for a learner could be initiated at the first entrance to a formal educational setting, where there is some systematic means to track educational efforts and progress.  The idea of a Life-long Learning (LLL) profile could extend literally to the 5 year-olds entrance to kindergarten.  Most likely, however, the educationally-focused aspect of a learner might begin with the High School transcript, which is then stored in the system of the post-secondary institution the student attends.  Many transcripts are currently electronically processed via EDI, so the possibility of the High School passing elements of learner information data to the post-secondary school is simple to grasp.  The student administration system establishes the student record and therefore elements of the learner information, using data from the application and the High School transcript;

• As a student progresses through the educational process, his/her learner information data is updated through the normal posting of grades, degrees awarded and so on that occurs in the student information system;

• When a student transfers to another educational institution, the learner information (e.g. data contained in the Official or Unofficial transcript) can be sent to the receiving institution.  This is a familiar transfer credit or articulation scenario.  If the institution’s academic systems contain information on preferences, educational history, goals, etc. those could be passed to the receiving academic system;

• Finally, when the student visits the institution’s career placement centre, his/her learner information data is available to be delivered to the online job exchange or directly to a prospective employer.

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:

• Improved management of information exchange across the parts of a university. The use of heterogeneous incompatible information systems provides many opportunities for error and confusion as data is communicated from one department to another.  Exchanging learner information in a standard form reduces the possibilities for confusion to occur.  The greater transparency of operation can enable many improvements in management of the processes;

• The LIP specification can enable greater flexibility for the learner for example in moving between provider institutions.  By providing a mechanism for recording the detail of courses taken by a learner the LIP can also provide for flexibility over time as a learner takes parts of courses when they best fit with the learner's lifestyle;

• In a similar manner LIP can provide inter-institution flexibility for providers. In the future as we move towards more open flexible provision the LIP specification can provide a means for information exchange and recording of achievement data on courses with multiple institutional providers.  There can be many advantages in sharing provision between institutions in particular circumstances.  One particularly striking example is that of courses with foreign language components where different parts of the course are provided by different institutions in different countries.  There are many other examples where specialisation can allow a provider organisation to carry a level of expertise in an area that would not be viable otherwise;

• Within the set of HE stakeholders are several bodies that need to exchange data with all UK universities.  UCAS is one such example.  By providing a common logical data format the LIP enables this exchange to be more efficient and for associated processes, such as qualification validation, to take place with greater rigour.  Where a learner interfaces with these systems, such as in enrolment on courses, there are usability benefits and potential cost savings.

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:

• Static Biographical - describes invariant characteristics of the Life-long Learner such as date of birth;

• Dynamic Biographical - describes variant characteristics of the individual such as current address or email information;

• Self-Reported - information under the direct control of the Life-long Learner and modifiable by them regardless of source such as a writing sample, a computer aided design work product, or a transcript furnished to the Life-long Learner by a third party and entered into their Portfolio by the Life-long Learner;

• Third Party Validated - information placed in the LLL Portfolio with the permission of the Life-long Learner but under the control of a validating third party such as a certifying training provider or degree granting educational institution. The obvious example is a transcript but also includes test and evaluation scores and may be extended to include performance reviews and personnel evaluations and health certifications as well.

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

• Life-long Learners - can review information in their Portfolio at any time under direct and secure access. Furthermore such learners can create “views” of their Portfolio information in a manner similar to creating a resume or curricula vitae by using Portfolio elements as building blocks. These views can be made available either to a “public” view that is generally accessible or to “specific” views restricted to one or more recipients;

• Recipients - may include prospective employers, advisors, evaluators, etc, have secure access to  views provided to them by learners;

• Providers - those parties that, at the request of the learner, provide information to an individual LLL Portfolio (these are the providers of third party validated information such as transcripts and test results);

• Systems Managers - the maintainers of the CMA and its security apparatus.

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:

• A ‘Trainer’ needs to create the group profile.  This group learner information may require links to the learner information records of the individuals that constitute the group.  The group information should be supported using the IMS Enterprise specification [Enterprise, 99a], [Enterprise, 99b], [Enterprise, 99c];

• The trainer needs to record any of the outcomes from the training for each individual in their learner profile.  The IMS LIP provides support for the description of the material structure, the results from the evaluation, the learning products produced by the individual/group and if appropriate a formal transcript and/or qualification/certification/license.

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

• Details concerning the course(s) undertaken and the corresponding outcome must be recorded.  This information should be aggregated with other similar information already stored in the learner’s training record.  The IMS LIP provides mechanisms by which this information can be added to previously stored information independent of the location and nature of the storage of that information;

• The associated goals and required competencies for the development of the learner’s career can be used to inform the choice for the most suitable training materials.  These goals and competencies can be transferred using the IMS LIP.

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

• The group learner information is updated as the group progresses through the training programme.  These updates could be accompanied by changes to the linked individual records (provided the access rights to the individual profile is set appropriately), depending on the implementation;

• Once the group’s training programme has been completed the issue of persistence of the group record must be considered. The group information should be supported using the IMS Enterprise specification [Enterprise, 99a], [Enterprise, 99b], [Enterprise, 99c].

4.     Basic Information Model

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

• Learner information package - the core data structures that contain the learner information;

• Learner information exchange - support for the package aggregation, transaction processing and messaging protocol;

• Learner information query - the querying mechanism by which components of the learner information can be retrieved according to defined search criteria.

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.

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:

• referential - information that enables the data component to be uniquely identified.  This reference is used to ensure that later actions on the data can be linked to the original creation of the data;

• temporal - information that is used to describe the timeliness, or otherwise, of the information e.g. creation date/time stamp, etc;

• privacy - information that is used to describe the privacy of, and to ensure the integrity of, the data.

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:

• The learner information may consist of only one of the atomic sub-structures i.e. some sub-structure of one of the eleven core data structures.  This means that only the relevant data needs to be transferred;

• The learner information may describe an individual or an organisation.  It should be noted that IMS Enterprise specification should be adopted for the exchange of group-based information.

4.2     Learner Information Exchange

The exchange of LIP instances requires the following processing capabilities:

• Aggregate packaging of multiple LIP instances - this is required if multiple LIP instances are to be exchanged between the sane systems e.g. all of the information concerning a particular cohort.  It is recommended that the IMS Content Packaging specification [CP, 00a][CP, 00b][CP, 00c] is adopted for this aggregation;

• Transactions management - this is the mechanism by which the instructions concerning the data carried within the LIP can be processed by the receiving system.  Communicating systems must agree a set of transactions e.g. create record, delete record, update record, etc.  This transaction processing requires implementers to define an agreed mechanism;

• Messaging - the appropriate messaging system that must include the protocols for the actual transmission of the data.  A new protocol will not be defined instead a suitable mechanism will be adopted from those currently available e.g. SOAP.

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:

• The definition of a suitable query language.  Several such languages exist and it is better to adopt the most suitable available;

• The packaging of the results produced by the query. It is recommended that the IMS Content Packaging specification [CP00a][CP,00b][Cp,00c] is adopted for this aggregation of the LIQ data structures.

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.

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 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 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 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 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 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 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 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 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 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 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 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:

• Sourcedid - the learner information record identifier.  This consists of a source label, unique to the source responsible for creating the learner information, and the identifier of the record within that source.  The source is responsible for ensuring that each different learner information record has a unique identifier.  The uniqueness of the source label is outside of the scope of this specification and assumes that each learner information server has an unique source label pre-assigned to it.  Once IMS has agreed the definition mechanism for the Global User Identifier (GUID) it is assumed that this will be the basis for the generation of the unique ‘sourcedid’;

• Indexid - the eleven core data structures and the associated sub-structures used to contain the learner information may be assigned an index number that is unique within the learner information record as a whole.  This allows later operations on the record to identify the appropriate piece of information thereby requiring only that piece of information to be transferred as opposed to the full learner information.  An important implication for this approach is that the indexid is a persistent pointer and so a system that uses it must maintain a mapping table between the indexid (as used for interoperability) and the local database address resolution structure.

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:

• A complete learner information record;

• A partial learner information record - this is the more likely scenario.

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:

i. Exchange granularity that requires only the pertinent information to be included.  This is achieved by breaking the learner information down into clearly defined discrete packages that could range from a new single character name to a 90 minute digitally encoded film.  Each discrete package is uniquely identifiable within a uniquely identified learner information structure;

ii. The exchange structure can consist of one or more independent or related learner information structures.  This means that the transfer of information can be arranged to take advantage of the most efficient packaging structures;

 iii. External reference to materials through the usage of URIs and XML Entity definitions as well as support for embedding the material directly into the package.

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:

i. Support for the inclusion of information that can be used to describe the level of privacy, access rights and integrity of the data.  This is defined as the privacy and data protection meta-structure;

ii. Support for learner information that will be used to enable the secure and/or authenticated transfer of the data.  This is described as the learner security keys.

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:

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:

• Definition extensions - extensions to the specification according to the agreed policies of the communicating systems.  The internal structure of the ‘results’ is an example of this type of extension.  The internal organisation of these structures is beyond the scope of the specification but the manner in which they are structured and used is well bounded by the specification.  Further versions of this specification will fully support these features;

• Vocabulary extensions – extensions that allow the basic vocabularies to be extended.  These vocabularies are assigned to many of the data objects and they are used to define the type of information being contained.  The basic vocabularies are defined within a set of default files maintained by IMS.  The vocabulary extensions may be included in a string list or referenced using a URI;

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

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:

• M = Mandatory Element that must be included in the data object, if the element at the higher level is included;

• C = Conditional Element.  Existence is dependent on values of other Elements;

• O = Optional Element.

Multi:                     Multiplicity of the element:

• Blank = single instance;

• Number = maximum number of times the element is repeatable;

• n = multiple occurrences allowed, no limit;

• Repeatability of an element implies that all sub-elements repeat with the same element.

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

• ID = element used to uniquely identify an object;

• Code = element value from a list of codes;

• Description = descriptive element, human language

• Flag = binary flag

• Enumerated = list of predefined non-numeric options i.e. the definitive list of objects

• The international character set specified by ISO 10646 will be used for all fields.

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

• Coding schemes using numerical values;

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

Note: Additional descriptive information about the element.

In the following tables the data objects are organised as:

• Table 6.1 - the learnerinformation data structure i.e. the structures that constitute the learner information itself;

• Table 6.2 - the identification data structure;

• Table 6.3 - the accessibility data structure;

• Table 6.4 - the goal data structure;

• Table 6.5 - the qcl data structure;

• Table 6.6 - the activity data structure;

• Table 6.7 - the competency data structure;

• Table 6.8 - the interest data structure;

• Table 6.9 - the affiliation data structure;

• Table 6.10 - the transcript data structure;

• Table 6.11 - the securitykey data structure;

• Table 6.12 - the relationship data structure;

• Table 6.13 - the common data structures (these are used in many different parts of the other data structures):
  • comment
  • contentype
  • typename
  • description
  • date
  • priority
  • status
  • product
  • fieldtype
  • fielddata
  • media
  • text
  • organisation
  • exrefrecord
  • extension

• Table 6.14 – the functional extensions, <extension>, that are supported.
  

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.

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.