1EdTech Learner Information Packaging Information Model Specification Final Specification Version 1.0

Copyright © 2001 1EdTech Consortium, Inc. All Rights Reserved.

The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name:1EdTech 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.

1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © 2001 1EdTech Consortium. All Rights Reserved.

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

This document may be copied and furnished to others by Registered Users who have registered on the 1EdTech 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 1EdTech, except as needed for the purpose of developing 1EdTech specifications, under the auspices of a chartered 1EdTech project group.

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

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

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

 

---

Table of Contents

ABOUT THIS DOCUMENT
LIST OF CONTRIBUTORS
REVISION HISTORY

1. INTRODUCTION

1.1 1EdTech 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. 1EdTech SUPPORTED LIP VOCABULARIES & TAXONOMIES

8. META-DATA DESCRIPTIONS

8.1 1EdTech 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 1EdTech 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     1EdTech Learner Information Specifications Overview

1EdTech 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 1EdTech Learner Information Package specification does not address requests for learner information or the exchange transaction mechanism.

1.1.1       Requirements

1EdTech 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 1EdTech 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 1EdTech 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.

1EdTech 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

1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech Learner Information Package (LIP) Information Model Final Specification.  As such it will be used as the basis for the production of the following documents:

 

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

   

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

This requirement has been derived from the agreed 1EdTech Learner Information Packaging Requirement Specification [LIP, 00a].  As will be seen from this information model there is overlap with the 1EdTech 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 1EdTech 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 1EdTech 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.     1EdTech Supported LIP Vocabularies & Taxonomies	The definition and description of the vocabularies and taxonomies that are supported as default by 1EdTech;
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]1EdTech Content Packaging Information Model, T.Anderson, W.Young, C.Moffatt, Version 1.0, 1EdTech, May 2000.

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

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

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

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

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

[Gestalt, 00]Gestalt: WP4 - Integrating 1EdTech 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, 1EdTech, March 2000.

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

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

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

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

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

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

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

[QTI, 01]1EdTech Question & Test Interoperability Information Model, C.Smythe and E.Shepherd, Version 1.1, 1EdTech, 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech.  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 1EdTech 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.

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

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.

 

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.

7.     1EdTech 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 1EdTech file name are listed in Table 7.1.

Table 7.1  ‘typename’ list of vocabularies.

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

 

• The <evalmetadata> structure (located within the <evaluation> structure) is used to house the meta-data associate with the mechanism used to provide the evaluation.  The meta-data used here should be drawn from the associated evaluation mechanism e.g. using the 1EdTech QTI specification for Assessments, Sections and Items as defined by the QTI specification [QTI, 00a].

8.1     1EdTech Meta-data Inclusion

The 1EdTech Meta-data elements are not supported directly within the 1EdTech LIP.  This is because 1EdTech LIP instances will be packaged using the 1EdTech Content Packaging specification.  The 1EdTech Content Packaging specification already defines how 1EdTech 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 1EdTech LIP instance the conformance statement shall:

 

• Indicate that all of the mandatory information model elements are correctly formed and located within the instance;

   

• Indicate that all of the optional information model elements are correctly formed and located when relevant to the instance;

   

• Indicate where the extension facilities made available within the LIP have been used and/or required.

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:

 

• Table 9.1 – <learnerinformation> data structure conformance;

   

• Table 9.2 – <accessibility> data structure conformance;

   

• Table 9.3 – <activity> data structure conformance;

   

• Table 9.4 – <affiliation> data structure conformance;

   

• Table 9.5 – <competency> data structure conformance;

   

• Table 9.6 – <goal> data structure conformance;

   

• Table 9.7 – <identification> data structure conformance;

   

• Table 9.8 – <interest> data structure conformance;

   

• Table 9.9 – <qcl> data structure conformance;

   

• Table 9.10 – <relationship> data structure conformance;

   

• Table 9.11 – <securitykey> data structure conformance;

   

• Table 9.12 – <transcript> data structure conformance.

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.
contentype
referential	temporal		privacy
comment   identification   accessibility   goal	qcl   activity   competency   interest		affiliation   transcript   securitykey   relationship
Extension Fields:                  These features allow the data model to be extended.
Vocabularies <typename		Functions   ext_learnerinfo

 

 

9.2.2       Accessibility Conformance Statement Table

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.
contentype
referential	temporal		privacy
comment	language		preference
Extension Fields:                  These features allow the data model to be extended.
Vocabularies typename		Functions ext_accessibility  ext_language   ext_preference ext_disability   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.
contentype
referential	temporal		privacy
comment   date   status   units	learningrefactivity   product   definition   evaluation		testimonial   status   description
Extension Fields:                  These features allow the data model to be extended.
Vocabularies typename		Functions ext_activity   ext_definition   ext_product   ext_testimonial   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.
contentype
referential	temporal		privacy
comment   affiliationid   role	organization   date		status   description
Extension Fields:                  These features allow the data model to be extended.
Vocabularies typename		Functions ext_affiliation   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.
contentype
referential	temporal		privacy
comment	exrefrecord		description
Extension Fields:                  These features allow the data model to be extended.
Functions
ext_competency ext_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.
contentype
referential	temporal		privacy
comment   date	priority   status		description
Extension Fields:                  These features allow the data model to be extended.
Vocabularies typename		Functions ext_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.
contentype
referential	temporal		privacy
comment   formname   name   contactinfo   telephone   facsimile   mobile   pager   email   web	address   pobox   street   locality   city   country   statepr    region   postcode   timezone   geo		demographics   representation   gender   date   uid agent   agentid   agentdomain   description
Extension Fields:                  These features allow the data model to be extended.
Vocabularies typename		Functions ext_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.
contentype
referential	temporal		privacy
comment	product		description
Extension Fields:                  These features allow the data model to be extended.
Vocabularies typename		Functions ext_interest ext_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.
contentype
referential	temporal		privacy
comment   title   organization	registrationno level		date   description
Extension Fields:                  These features allow the data model to be extended.
Vocabularies typename		Functions ext_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.
contentype
referential	temporal		privacy
comment   tuplesource	tuplerelation   tupledest		description
Extension Fields:                  These features allow the data model to be extended.
Vocabularies typename		Functions ext_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.
contentype
referential	temporal		privacy
comment	keyfields		description
Extension Fields:                  These features allow the data model to be extended.
Vocabularies typename		Functions ext_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.
contentype
referential	temporal		privacy
comment	exrefrecord		description
Extension Fields:                  These features allow the data model to be extended.
Vocabularies typename		Functions ext_transcript ext_exrefrecord

 

 

Appendix A - Object Model Representation

Figure A1 shows an object-oriented perspective 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 1EdTech 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.

 

About This Document

 

Title	1EdTech 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 1EdTech 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: