IMS Learner Information Packaging Best Practice & Implementation Guide 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 Best Practice & Implementation Guide 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 NOMENCLATURE

1.5 REFERENCES

2. RELATIONSHIP TO OTHER SPECIFICATIONS

2.1 IMS SPECIFICATIONS

2.2 RELATED SPECIFICATIONS
2.2.1 IEEE P1484
2.2.2 Schools Interoperability Framework (SIF)
2.2.3 ANSI TS 130 Student Educational Record
2.2.4 Internet vCard Specification
2.2.5 Internet2 eduPerson
2.2.6 HR-XML Consortium Specifications

2.3 RELATED ACTIVITIES
2.3.1 ISO/IEC JTC1/SC36 Learning Technology
2.3.2 Advanced Distributed Learning (ADL) Initiative
2.3.3 Aviation Industry CBT Committee (AICC)
2.3.4 EU ACTS Gestalt Project
2.3.5 CEN/ISSS

2.4 IMS SPECIFICATION DEVELOPMENT PROCESS

3. OVERALL DATA MODEL

3.1 INFORMATION MODEL

3.2 XML SCHEMA TREE
3.2.1 Core XML Schema Tree
3.2.2 <identification> XML Schema Tree
3.2.3 <goal> XML Schema Tree
3.2.4 <qcl> XML Schema Tree
3.2.5 <accessibility> XML Schema Tree
3.2.6 <activity> XML Schema Tree
3.2.7 <competency> XML Schema Tree
3.2.8 <interest> XML Schema Tree
3.2.9 <transcript> XML Schema Tree
3.2.10 <affiliation> XML Schema Tree
3.2.11 <securitykey> XML Schema Tree
3.2.12 <relationship> XML Schema Tree

4. BASIC EXAMPLE LIP INSTANCES

4.1 ACCESSIBILITY EXAMPLES
4.1.1 Accessibility Language Examples
4.1.2 Accessibility Preference Examples

4.2 ACTIVITY EXAMPLES
4.2.1 Activity Learningactivetyref Examples
4.2.2 Activity Definition Examples
4.2.3 Activity Product Examples
4.2.4 Activity Testimonial Examples
4.2.5 Activity Evaluation Examples

4.3 AFFILIATION EXAMPLES

4.4 COMPETENCY EXAMPLES

4.5 GOAL EXAMPLES

4.6 IDENTIFICATION EXAMPLES
4.6.1 Identification Formatted Name Examples
4.6.2 Identification Name Examples
4.6.3 Identification Address Examples
4.6.4 Identification Contactinfo Examples
4.6.5 Identification Demographics Examples
4.6.6 Identification Agent Examples

4.7 INTEREST EXAMPLES

4.8 QCL EXAMPLES

4.9 RELATIONSHIP EXAMPLES

4.10 SECURITYKEY EXAMPLES

4.11 TRANSCRIPT EXAMPLES

5. ADVANCED EXAMPLE LIP INSTANCES

5.1 ENGINEERING RESUME
5.1.1 The Example
5.1.2 The XML Instance
5.1.3 Key Features of the Engineering Resume Example

5.2 FEFC FUNDING RECORDS EXCHANGE
5.2.1 The Example
5.2.2 The Instance - Version 1
5.2.3 The Instance - Version 2
5.2.4 Key Features of the ISR Mapping Examples

6. IMS LIP AND OTHER RELEVANT SPECIFICATIONS

6.1 IMS SPECIFICATIONS
6.1.1 Enterprise
6.1.2 Content Packaging
6.1.3 Meta-data
6.1.4 Accessibility
6.1.5 Competency Definitions
6.1.6 Question & Test Interoperability

6.2 OTHER SPECIFICATIONS
6.2.1 IETF vCard
6.2.2 IEEE PAPI
6.2.3 Internet2/Educase 'eduPerson'

7. IMPLEMENTATION GUIDANCE

7.1 NOMENCLATURE

7.2 USING THE CORE DATA STRUCTURES
7.2.1 <accessibility>
7.2.2 <activity>
7.2.3 <affiliation>
7.2.4 <competency>
7.2.5 <goal>
7.2.6 <identification>
7.2.7 <interest>
7.2.8 <qcl>
7.2.9 <relationship>
7.2.10 <securitykey>
7.2.11 <transcript>

7.3 LIP STRUCTURAL META-DATA
7.3.1 Referential Structure
7.3.2 Temporal Structure
7.3.3 Privacy Structure

7.4 THE LIP VOCABULARIES
7.4.1 The Basic Vocabularies
7.4.2 Extending the Vocabularies
7.4.3 Data Entry Using the Vocabularies

7.5 BUILDING RELATIONSHIPS WITHIN THE LIP

7.6 IDENTIFIERS

7.7 PACKAGING, TRANSACTIONS, MESSAGING & PROTOCOLS

7.8 SECURITY ARCHITECTURES & CONSIDERATIONS
7.8.1 LIP Identifiers
7.8.2 Access Control
7.8.3 Privacy
7.8.4 Data Integrity
7.8.5 Miscellaneous

7.9 DISTRIBUTED ARCHITECTURES & CONSIDERATIONS

8. V2.0 ELEMENTS

9. EXTENSIBILITY

10. CONFORMANCE

10.1 VALID DATA ISSUES

10.2 CONFORMANCE STATEMENT
10.2.1 Learnerinformation Conformance Statement Table
10.2.2 Accessibility Conformance Statement Table
10.2.3 Activity Conformance Statement Table
10.2.4 Affiliation Conformance Statement Table
10.2.5 Competency Conformance Statement Table
10.2.6 Goal Conformance Statement Table
10.2.7 Identification Conformance Statement Table
10.2.8 Interest Conformance Statement Table
10.2.9 Qcl Conformance Statement Table
10.2.10 Relationship Conformance Statement Table
10.2.11 Securitykey Conformance Statement Table
10.2.12 Transcript Conformance Statement Table

10.3 A CONFORMANCE STATEMENT EXAMPLE

APPENDIX A - LIP AND ITS SCHEMAS

A1 OVERVIEW

A2 FEATURES OF THE DIFFERENT DTDS/XDRS

A3 RECOMMENDED USAGE OF THE XSDS AND DTDS

A4 FULL DIRECTORY STRUCTURE

APPENDIX B - THE LIP XML INSTANCE EXAMPLE FILES

APPENDIX C - GLOSSARY OF TERMS

C1 GENERAL TERMS

C2 LIP ELEMENTS AND ATTRIBUTES

FIGURE 1.1 THE IMS LEARNER INFORMATION PACKAGE (LIP) CORE DATA STRUCTURES.
FIGURE 3.1 THE IMS LIP DATA MODEL.
FIGURE 3.2 THE CORE XML SCHEMA TREE.
FIGURE 3.3 THE <IDENTIFICATION> XML SCHEMA TREE.
FIGURE 3.4 THE <GOAL> XML SCHEMA TREE.
FIGURE 3.5 THE <QCL> XML SCHEMA TREE.
FIGURE 3.6 THE <ACCESSIBILITY> XML SCHEMA TREE.
FIGURE 3.7 THE <ACTIVITY> XML SCHEMA TREE.
FIGURE 3.8 THE <COMPETENCY> XML SCHEMA TREE.
FIGURE 3.9 THE <INTEREST> XML SCHEMA TREE.
FIGURE 3.10 THE <TRANSCRIPT> XML SCHEMA TREE.
FIGURE 3.11 THE <AFFILIATION> XML SCHEMA TREE.
FIGURE 3.12 THE <SECURITYKEY> XML SCHEMA TREE.
FIGURE 3.13 THE <RELATIONSHIP> XML SCHEMA TREE.
FIGURE 6.1 SCHEMATIC REPRESENTATION OF THE FILES TO BE PACKAGED.
FIGURE 6.2 THE USAGE OF IMS LIP TO SUPPORT IEEE PAPI.
FIGURE 7.1 A SCHEMATIC MODEL OF LAYER-BASED COMMUNICATING PROFILE SERVERS.

List of Tables

TABLE 5.1 ISR MAPPING TO THE IMS LIP.
TABLE 6.1 THE USAGE OF IMS LIP TO SUPPORT THE IETF VCARD SPECIFICATION.
TABLE 6.2 THE USAGE OF IMS LIP TO EXCHANGE THE EDUPERSON INFORMATION
TABLE 8.1 LIST OF V1.X/2.0 SPECIFIC ELEMENTS.
TABLE 9.1 LIST OF PROPRIETARY EXTENSION ELEMENTS.
TABLE 10.1 LEARNERINFORMATION CONFORMANCE STATEMENT TABLE.
TABLE 10.2 ACCESSIBILITY CONFORMANCE STATEMENT TABLE.
TABLE 10.3 ACTIVITY CONFORMANCE STATEMENT TABLE.
TABLE 10.4 AFFILIATION CONFORMANCE STATEMENT TABLE.
TABLE 10.5 COMPETENCY CONFORMANCE STATEMENT TABLE.
TABLE 10.6 GOAL CONFORMANCE STATEMENT TABLE.
TABLE 10.7 IDENTIFICATION CONFORMANCE STATEMENT TABLE.
TABLE 10.8 INTEREST CONFORMANCE STATEMENT TABLE.
TABLE 10.9 QCL CONFORMANCE STATEMENT TABLE.
TABLE 10.10 RELATIONSHIP CONFORMANCE STATEMENT TABLE.
TABLE 10.11 SECURITYKEY CONFORMANCE STATEMENT TABLE.
TABLE 10.12 TRANSCRIPT CONFORMANCE STATEMENT TABLE.
TABLE 10.13 EXAMPLE LEARNERINFORMATION CONFORMANCE STATEMENT TABLE.
TABLE 10.14 EXAMPLE IDENTIFICATION CONFORMANCE STATEMENT TABLE.
TABLE 10.15 EXAMPLE QCL CONFORMANCE STATEMENT TABLE.
TABLE B1 THE LIP XML INSTANCE VALID BASIC EXAMPLE FILES.
TABLE B2 THE LIP XML INSTANCE VALID ADVANCED EXAMPLE FILES.

About This Document

Title	IMS Learner Information Package Best Practice & Implementation Guide
Authors	Colin Smythe, Frank Tansey and Robby Robson
Version	1.0
Version Date	9th March, 2001
Status	Final Specification.
Summary	This document provides additional information regarding IMS Learner Information Packaging best practices and implementation guidelines. It is meant to complement the IMS LIP XML Binding and IMS LIP Information Model documents.
Revision Information	9th March, 2001
Purpose	Defines the best practice usage of the XML binding for the LIP Information Model specification.
Document Location	http://www.imsglobal.org/profiles/lipbest01.html.

List of Contributors

The following individuals contributed to the development of this document:

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

Revision History

Version No.	Release Date	Comments
Public Draft Specification v1.0	21st December, 2000	This is the first publicly available version of the IMS LIP Best Practice & Implementation Guide.
Final Specification v1.0	9th March, 2001	This is the first final version of the IMS LIP Best Practice & Implementation Guide.

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

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

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

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

IMS would appreciate receiving your comments and suggestions.

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

Please refer to Document Name: IMS Learner Information Package Best Practice Guide v1 Revision: March 2001

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:

1. Time-related information; 
2. Identification and indexing information;
3. 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:

1. A tree;
2. An object model;
3. 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 Learning Information Package (LIP) Best Practice & Implementation Guide.  As such it should be used in conjunction with the:

• IMS Learner Information Package Information Model specification v1.0;

• IMS Learner Information Package XML Binding v1.0;

1.3     Structure of this Document

The structure of this document is:

2.     Relationship to Other Specifications	The relationship of this specification to other IMS and external specification activities;
3.     Overall Data Model	A brief summary of the IMS Learner Information Packaging information model;
4.     Basic Example LIP Instances	Examples of the basic LIP instances (for each of the core structures) that are supported by this specification;
5.     Advanced Example LIP Instances	Advanced examples of LIP instances that are supported by this specification;
6.     IMS LIP and Other Relevant Specifications	An explanation of how the IMS LIP can be used to capture some of the other relevant specifications;
7.     Implementation Guidance	Tips on how distributed learning systems can make best usage of the LIP specification;
8.     V1.x Developments	The areas of the specification that are for further development in later releases;
9.     Extensibility	The extension facilities and their usage;
10.   Conformance	The expectations on systems that claim conformance to the IMS LIP specifications;
Appendix A – LIP and its Schemas	The range of available LIP XSDs and DTDs;
Appendix B – The LIP XML Instance Example Files	The set of LIP examples and their associated file names;
Appendix C – Glossary of Terms	A glossary of the key terms and elements used within the specification.

1.4     Nomenclature

ADL                       Advanced Distributed Learning

AICC                      Aviation Industry CBT Committee

ANSI                      American national Standards Institute

CBT                        Computer Based Training

CEN                        Centre for European Normalisation

CORBA                  Common Object Repository Brokerage Architecture

DCOM                   Distributed Common Object Management

DTD                       Document Type Definition

EDI                         Electronic Data Interchange

FEFC                      Further Education Funding Council

GUID                      Global User Identifier

IEEE                        Institute of Electronic & Electrical Engineering

IETF                       Internet Engineering Task Force

ISO                         International Standards Organisation

ISR                          Individualised Student Record

ISSS                        Information Society Standardisation Service

JTC                         Joint Technical Committee

LDAP                     Lightweight Directory Access Protocol

LIP                          Learner Information Packaging

LOM                       Learner Object Meta-data

LTSC                      Learning Technology Standards Committee

NATO                    North Atlantic Treaty Organisation

PAPI                       Public And Private Information

PDI                         Personal Data Interchange

QTI                         Question & Test Interoperability

SCORM                 Shareable Courseware Object Reference Model

SEP                         Staffing Exchange Protocol

SIF                          Schools Interoperability Framework

URI                         Universal Resource Identifier

W3C                       World Wide Web Consortium

XDR                       XML Data Reduced

XML                       Extensible Mark-up Language

XSD                        XML Schema

1.5     References

[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.

[eduPerson, 01]    EduPerson 1.0 Specification, Internet2/Educause, Feb 2001.

[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, 01a]               IMS Learner Information Package Information Model Final Specification, R.Robson, C.Smythe and F.Tansey, Version 1.0, IMS, March 2001.

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

[LIP, 01c]               IMS Learner Information Package Best Practices & Implementation Guide Final 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.     Relationship to Other Specifications

2.1     IMS Specifications

Version 1.0 of the IMS Learner Information Package (LIP) specification is made up of three documents:

• IMS Learner Information Package Information Model – Version 1.0.  This document describes the data structures that are used to provide interoperability of Internet-based learner information systems;

• IMS Learner Information Package XML Binding – Version 1.0.  This document describes how to encode the learning information objects in XML and provides the corresponding XML schema;

• IMS Learner Information Package Best Practice & Implementation Guide – Version 1.0.  This document (the one you are reading now) provides an overview and describes how the IMS LIP Information Model and XML Binding can be applied to specific types of interoperability scenarios.

The IMS LIP specification is related to several other IMS specifications, both complete and in-progress.  This specification is intended to be consistent with these other initiatives wherever possible, in order to reduce redundancy and confusion between specifications. The related specifications are:

• IMS Meta-data Specification – the IMS LIP specification recommends the usage, where appropriate, of the IMS Meta-data definitions to support the meta-data entities to be used in the context of the LIP;

• IMS Enterprise Specification – the IMS LIP is not to be used for the exchange of information concerning education groups and the membership of such groups.  This type of information exchange should be based on the IMS Enterprise specification;

• IMS Content Packaging Specification – multiple IMS LIP XML instances should be packaged using the IMS Content Packaging mechanisms;

• IMS Question & Test Interoperability – summary results interoperability is support by the IMS LIP.  This will also be addressed by the IMS QTI working-group and when their work has been completed the two solutions will be formally harmonised (IMSP LIP method is more generic that that proposed for the QTI and as such is capable of supporting the QTI method).

2.2     Related Specifications

2.2.1     IEEE P1484

The IEEE Learning Technology Standardisation Committee P1484 is the only body engaged in the educational domain, which has a recognised formal standing.  Given the diversity of the fora represented by the participants in the IEEE, there exist a large number of working groups focused on specific activities, as well as more horizontal activities (such as the Architecture and Reference Model and the Glossary working groups) that attempt to tie the wider ranging work together.  The IEEE Public & Private Information (PAPI) Specification is an attempt to define a ‘portable’ learner [IEEE, 98].  The IMS LIP has, in part, been derived from the PAPI (versions 5.0 and 6.0).

2.2.2     Schools Interoperability Framework (SIF)

The Schools Interoperability Framework is an industry initiative to develop a technical blueprint for K-12 software that will enable diverse applications to interact and share data now and in the future. SIF has two deliverables: the SIF Message Specification and the Implementation Specification. While the SIF Message Specification defines the messages that each application can exchange with others, the Implementation Specification defines the software implementation guidelines for SIF. The Implementation Specification does not make any assumption of what hardware and software products need to be used to develop SIF-compliant applications. Instead, it only defines the requirements of architecture, communication, software components, and interfaces between them. The goal of SIF is to ensure that all the SIF-compliant applications can achieve interoperability, regardless of how they are implemented. SIF is truly an open industrial initiative.  SIF is focused on supporting interoperability between schools-based educational administration systems whereas LIP is focussed on learner educational information.

2.2.3     ANSI TS 130 Student Educational Record

The ANSI TS130 contains the format and establishes the data contents of a Student Educational Record (Transcript) Transaction Set for use within the context of Electronic Data Interchange (EDI) environment.  The student transcript is used by schools and school districts, and by post-secondary educational institutions to transmit current and historical records of educational accomplishment and other significant information for students enrolled at the sending schools and institutions.  The transcript may be sent to other educational institutions, to other agencies, or to prospective or current employers.  The student transcript contains personal history and identifying information about the student, the current academic status, dates of attendance, courses completed with grades earned, degrees and diplomas awarded, health information (Pre-Kindergarten through Grade 12 only), and testing information.^[1]

2.2.4     Internet vCard Specification

The vCard specification allows the open exchange of Personal Data Interchange (PDI) information typically found on traditional paper business cards. The specification defines a format for an electronic business card, or vCard.  The vCard specification is suitable as an interchange format between applications or systems. The format is defined independent of the particular method used to transport it. The transport for this exchange might be a file system, point-to-point public switched telephone networks, wired-network transport, or some form of unwired transport. The vCard has direct application to the way users utilize the Internet network. The vCard can be used to forward personal data in an electronic mail message. The numerous forms a user of the WWW fills out on a homepage can also be automated using the vCard. The Internet Mail Consortium is working with the Internet Engineering Task Force (IETF) to complete work on an extension to the Internet MIME-based electronic mail standard to allow for this capability.  An XML binding of the vCard specification has produced a DTD [vCard, 98] and this has been used to inform the development of the IMS LIP.

2.2.5     Internet2 eduPerson

In February 2001the joint Internet2(R) and EDUCAUSE working group announced the release of the ‘eduPerson’ specification for services that provide seamless access to network-accessible information regardless of where or how the original information is stored.  The eduPerson specification provides a set of standard higher-education attributes for an enterprise directory, which facilitate inter-institutional access to applications and resources across the higher education community. The EDUCAUSE/Internet2 eduPerson task force has the mission of defining a Lightweight Directory Access Protocol (LDAP) object class that includes widely-used person attributes in higher education.  An example of how to use the IMS LIP to exchange the eduPerson information is shown in Section 6.

2.2.6     HR-XML Consortium Specifications

The HR-XML Consortium is an independent, non-profit association dedicated to the development and promotion of a standard suite of XML specifications to enable e-commerce and the automation of human resources-related data exchanges.  The mission of the HR-XML Consortium is to develop and publish open data exchange standards based upon XML.  Some of the Consortium’s initial targets for standardization activities include recruiting, staffing, compensation and benefits.  The Consortium’s Recruiting and Staffing workgroup is working on a first version of Staffing Exchange Protocol (SEP), an XML-based messaging framework that supports dynamic, real-time staffing transactions over the Web. Transactions supported by SEP include the posting of job opportunities to job boards and other recruiting venues and the return of resumes matching those postings. The protocol also supports the up-dating and recall of job postings, the supplying of contact information for a job candidate where only partial information was initially supplied, employer feedback to job boards on positions that have been filled, and the update and recall of resumes by job seekers.  The Consortium’s Compensation and Benefits Workgroup has begun work on an XML framework for communicating employee benefit enrollment information between employers and insurance carriers, managed care organizations, and third party administrators. The workgroup also is working to deploy a demonstration of how standardized XML can streamline the transfer of Defined Contribution and Defined Benefit (DC/DB) data between a plan sponsor, such as an employer, and a plan provider.

2.3     Related Activities

2.3.1     ISO/IEC JTC1/SC36 Learning Technology

As of 10^th November 1999, the ISO/IEC Joint Technical Committee 1 meeting in Seoul agreed resolution 6, which brought into existence Sub-Committee 36 - Learning Technology. The international secretariat for SC36 is provided by the US National Body, the American National Standards Institute (ANSI).  ISO/IEC JTC1/SC36 is intended to address standardisation in the area of information technologies that support automation for learners, learning institutions, and learning resources. It is the intention that SC36 shall not create standards or technical reports that define educational standards, cultural conventions, learning objectives, or specific learning content.  Their activity in the field of question and test has yet to be defined.  The UK delegation to ISO has offered to undertake preliminary work on learning profiles on behalf of ISO.

2.3.2     Advanced Distributed Learning (ADL) Initiative

ADL is a US military programme started by the White House in 1997 that aims to advance the use of state-of-the-art on-line training amongst the countries defence forces. There is some collaboration with experts in military training applications from other NATO countries.  ADL is very focused on content for particular areas of training. It also has the Shareable Courseware Object Reference Model (SCORM v1.0) as a working document to encourage discussion and input on the emerging standards.  No separate Learner Information specification is underway.

2.3.3     Aviation Industry CBT Committee (AICC)

The Aviation Industry CBT Committee is a membership-based international forum that develops recommendations on interoperable learning technology, principally for the commercial aviation and related industries. As such its members include both plane and equipment manufacturers, carriers, software and multimedia vendors and a growing number of interested parties not directly engaged in the sector, but nevertheless interested in the work being done there.  A sub-group of the AICC have been working with the ADL and other organisation from the IEEE LTSC.

2.3.4     EU ACTS Gestalt Project

The EU ACTS Project GESTALT (Getting Educational Systems Talking Across Leading-edge Technologies) addressed the issues of integrating a number of technologies able to support the planned integration. CORBA and DCOM were used to provide the distributed platform support required by this application. A meta-data format servicing the requirements of the application was specified, drawing on the work of bodies such as the IMS Project and the IEEE LTSC. In addition, W3C XML meta-data extensions, such as SMIL, were explored for providing object synchronisation.  The Gestalt project was completed in March, 2000.

2.3.5     CEN/ISSS

CEN/ISSS, in co-operation with the European Commission’s DG III & DG XIII has set up a working group to address European requirements for Educational Technology. This working group aims to achieve a consensus view in this area through the following actions:

• A requirements gathering stage to discover the precise needs of European developers and users;

• Consensus within a working group established under the TEISS (Telematics European Industry Standardisation Support) framework on the standardisation process for educational technology;

• Coherent developments within metadata under the CEN/ISSS workshop process after this stage;

• Coherent development of standards for interoperability which allow learning resources to work together and seamlessly with learning management systems;

• Publication and transmission of recommendations by the work group to publishers, suppliers of hardware and services, telecommunications operators, industry bodies generally, standardisation bodies, the European Commission and international standards bodies.

2.4     IMS Specification Development Process

The development life-cycle for an IMS specification has been established as:

• Month 1 – set-up of the team including identification of the team leads (for LIP this is Robby Robson, Saba, and Frank Tansy, IMS), editor (for LIP this is Colin Smythe, Dunelm Services Ltd) and key collaborating groups and organisations;

• Month 2 – Team and scope/requirements development;

• Month 3 – Initial internal team documents developed;

• Month 4 – Base document development and vote.  Approval of the Base Documents by the Technical Board;

• Month 5 – Document improvement.  Open issues are identified and solutions developed.  Companies are encouraged to develop code against the base documents;

• Month 6 – Further document improvement and feedback from organisations involved in implementations;

• Month 7 – Completion of the Public Draft Specification and approval by the IMS Technical Board;

• Months 8 & 9 – Accept feedback from organisations working to the Public Draft Specification.  Resolve any issues raised;

• Month 10 – Completion of the Final Specification and approval by the IMS Technical Board.  This is the combination of the Public Draft Specification plus resolutions due to experience gained in working with it.

A draft specification is developed within the IMS developer and user community, which currently includes more than 200 organisations from around the world.  In a number of cases, one of these organisations represents many other organisations, such as the Australian Government’s DETYA organisation, which provides access to the IMS community for all institutions of learning in Australia.

The term ‘Base Document’ is used for draft specifications that have reached a relatively high level of stability based on input from the team and the Technical Board.  Base documents represent the stage in the specification process of final development and refinement.  It is base documents that are presented in their final forms to the IMS Technical Board for vote.  If approved, the document becomes a ‘Public Draft Specification’ and is listed as such on the IMS public web site.  If not approved, the team works through whatever adjustments and recommendations the Technical Board provides, and then resubmits the document.  After three months the Public Draft Specification should be adopted as a ‘Final Specification’.

After a final specification is released, the team develops the next scope document for the subsequent work.  New requirements and features dropped from the previous specification constitute the scope of the next effort.

3.     Overall Data Model

3.1     Information Model

The data model for the LIP is shown in Figure 3.1 (this is the same as that described in the LIP Information Model, [LIP, 01b]).

Figure 3.1  The IMS LIP data model.

The objects in this model and their key behaviours 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, demographics and agent;

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, certificationss 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, voluntary, etc.) record and products (excluding formal awards).  This information 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 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 recreational activities.  These activities may have formal awards (as described in the associated ‘qcl’).  Electronic versions of the products of these interests may also be contained;

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

securitykey                  This learner information is used to store the descriptions of the passwords, certificates, PINs 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.

3.2     XML Schema Tree^[2]

3.2.1     Core XML Schema Tree

The core XML schema tree is shown in Figure 3.2.

Figure 3.2  The core XML schema tree.

3.2.2     <identification> XML Schema Tree

The identification XML schema tree is shown in Figure 3.3.

Figure 3.3  The <identification> XML schema tree.

3.2.3     <goal> XML Schema Tree

The goal XML schema tree is shown in Figure 3.4.

Figure 3.4  The <goal> XML schema tree.

3.2.4     <qcl> XML Schema Tree

The qcl XML schema tree is shown in Figure 3.5.

Figure 3.5  The <qcl> XML schema tree.

3.2.5     <accessibility> XML Schema Tree

The accessibility XML schema tree is shown in Figure 3.6.

Figure 3.6  The <accessibility> XML schema tree.

3.2.6     <activity> XML Schema Tree

The activity XML schema tree is shown in Figure 3.7.

Figure 3.7  The <activity> XML schema tree.

3.2.7     <competency> XML Schema Tree

The competency XML schema tree is shown in Figure 3.8.

Figure 3.8  The <competency> XML schema tree.

3.2.8     <interest> XML Schema Tree

The interest XML schema tree is shown in Figure 3.9.

Figure 3.9  The <interest> XML schema tree.

3.2.9     <transcript> XML Schema Tree

The transcript XML schema tree is shown in Figure 3.10.

Figure 3.10  The <transcript> XML schema tree.

3.2.10   <affiliation> XML Schema Tree

The affiliation XML schema tree is shown in Figure 3.11.

Figure 3.11  The <affiliation> XML schema tree.

3.2.11   <securitykey> XML Schema Tree

The securitykey XML schema tree is shown in Figure 3.12.

Figure 3.12  The <securitykey> XML schema tree.

3.2.12   <relationship> XML Schema Tree

The relationship XML schema tree is shown in Figure 3.13.

Figure 3.13  The <relationship> XML schema tree.

4.     Basic Example LIP Instances

The basic examples are arranged according to the eleven core data structures.  The examples supplied are:

• Accessibility

  – Language: the definition of the language proficiencies for a learner

  – Preference: the definition of a learner’s cognitive, physical and technology preferences;

• Activity

  – Learning activity reference: an external reference mechanism to the learning materials

  – Definition: the definition of the materials studied

  – Product: the materials developed by the learner themselves

  – Testimonial: statements attesting to the capabilities of the learner

  – Evaluation: the results of the evaluations undertaken;

• Affiliation – the professional affiliations and associated roles of the learner;

• Competency ­ the competencies of the learner;

• Goal ­– the goals and sub-goals of the learner

• Identification

  – Formatted Name: the formatted names for a learner

  – Name: the names for a learner

  – Address: the addresses for a learner

  – Contactinfo: the electronic-based contact information for the a learner

  – Demographics: the demographics information about the learner

  – Agent: the representatives permitted to act on behalf of the learner;

• Interest – the hobbies and recreational interests of the learner;

• Qcl – description of the qualification, certifications and licences for a learner;

• Relationship – the set of relationships that are to be defined between the learner and their identification, accessibility, qualifications, competencies, goals, activities, interests, transcripts, securitykeys and affiliations;

• Securitykey – the security-oriented information to be used with respect to the learner;

• Transcript – the transcripts that summarise the performance of the learner.

4.1     Accessibility Examples

4.1.1     Accessibility Language Examples

This example defines the ‘German’ language abilities of the learner.  The example contains all of the IMS LIP information required to construct the instance record.

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

<learnerinformation>    <comment>An example of LIP Accessibility information.</comment>    <contentype>        <referential>           <sourcedid>               <source>IMS_LIP_V1p0_Example</source>               <id>basic_1001</id>           </sourcedid>        </referential>    </contentype>    <accessibility>        <contentype>           <referential>               <indexid>accessibility_01</indexid>           </referential>        </contentype>        <language>           <typename>               <tysource sourcetype="imsdefault"/>               <tyvalue>German</tyvalue>           </typename>           <contentype>               <referential>                  <indexid>language_01</indexid>               </referential>           </contentype>           <proficiency profmode="OralSpeak">Excellent</proficiency>           <proficiency profmode="OralComp">Excellent</proficiency>           <proficiency profmode="Read">Good</proficiency>           <proficiency profmode="Write">Poor</proficiency>        </language>    </accessibility> </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/accs_lang_001/accs_lang_001.xml.

The key features of this example are:

• The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_1001’ (lines 6 and 7).  This must be used for all further references to this learner;

• The language is identified as ‘German’ in line 20;

• The language oral, reading and writing proficiencies are defined in lines 27-30 respectively.

The next stage is to create a second set of language proficiencies for the same learner.  The example contains all of the IMS LIP information required to construct the instance record.

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

<learnerinformation>    <comment>An example of LIP Accessibility information.</comment>    <contentype>        <referential>           <sourcedid>               <source>IMS_LIP_V1p0_Example</source>               <id>basic_1001</id>           </sourcedid>        </referential>    </contentype>    <accessibility>        <contentype>           <referential>               <indexid>accessibility_01</indexid>           </referential>        </contentype>        <language>           <typename>               <tysource sourcetype="imsdefault"/>               <tyvalue>Spanish</tyvalue>           </typename>           <contentype>               <referential>                  <indexid>language_02</indexid>               </referential>           </contentype>           <proficiency profmode="OralSpeak">Poor</proficiency>           <proficiency profmode="OralComp">Poor</proficiency>           <proficiency profmode="Read">Good</proficiency>           <proficiency profmode="Write">Good</proficiency>        </language>    </accessibility> </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/accs_lang_002/accs_lang_002.xml.  The key features of this example are:

• The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_1001’ (lines 6 and 7) – as per the previous language example;

• The same accessibility record is denoted by the usage of the same indexid i.e. ‘accessibility_01’ (line 14 in both examples).  The fact that a new language is being supplied is denoted by the fact that a new language indexid is used i.e. ‘language_02’ (cf. line 21 in both examples);

• The language oral, reading and writing proficiencies are defined in lines 27-30 respectively.

4.1.2     Accessibility Preference Examples

This example creates the input technology preferences of the learner.  The example contains all of the IMS LIP information required to construct the instance record.

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

<learnerinformation>    <comment>An example of LIP Accessibility information.</comment>    <contentype>        <referential>           <sourcedid>               <source>IMS_LIP_V1p0_Example</source>               <id>basic_1001</id>           </sourcedid>        </referential>    </contentype>    <accessibility>        <contentype>           <referential>               <indexid>accessibility_01</indexid>           </referential>        </contentype>        <preference>           <typename>               <tysource sourcetype="imsdefault"/>               <tyvalue>InputTech</tyvalue>           </typename>           <contentype>               <referential>                  <indexid>preference_01</indexid>               </referential>           </contentype>           <prefcode>Large Font Display Devices</prefcode>        </preference>    </accessibility> </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/accs_pref_001/accs_pref_001.xml.  The key features of this example are:

• The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_1001’ (lines 6 and 7).  This must be used for all further references to this learner;

• The preference is defined as ‘Input Technology’ in line 20;

• The actual preference entry is given in line 27.

The next stage is to create a second preference for the same learner.  The example contains all of the IMS LIP information required to construct the instance record.

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

<learnerinformation>    <comment>An example of LIP Accessibility information.</comment>    <contentype>        <referential>           <sourcedid>               <source>IMS_LIP_V1p0_Example</source>               <id>basic_1001</id>           </sourcedid>        </referential>    </contentype>    <accessibility>        <contentype>           <referential>               <indexid>accessibility_01</indexid>           </referential>        </contentype>        <preference>           <typename>               <tysource sourcetype="imsdefault"/>               <tyvalue>Cognitive</tyvalue>           </typename>           <contentype>               <referential>                  <indexid>preference_02</indexid>               </referential>           </contentype>           <prefcode>Exploratory</prefcode>        </preference>    </accessibility> </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/accs_pref_001/accs_pref_002.xml.

• The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_1001’ (lines 6 and 7) – as per the previous language example;

• The same accessibility record is denoted by the usage of the same indexid i.e. ‘accessibility_01’ (line 14 in both examples).  The fact that a new preference is being supplied is denoted by the fact that a new preference indexid is used i.e. ‘preference_02’ (cf. line 21 in both examples);

• The new preference (a cognitive type) is stored in line 27.

4.2     Activity Examples

4.2.1     Activity Learningactivetyref Examples

This example creates an activity containing a learninactivityref record for the learner.  The example contains all of the IMS LIP information required to construct the instance record.

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

<learnerinformation>    <comment>An example of LIP Activity information.</comment>    <contentype>        <referential>           <sourcedid>               <source>IMS_LIP_V1p0_Example</source>               <id>2001</id>           </sourcedid>        </referential>    </contentype>    <activity>        <typename>           <tysource sourcetype="imsdefault"/>           <tyvalue>Education</tyvalue>        </typename>        <contentype>           <referential>               <indexid>activity_1</indexid>           </referential>        </contentype>        <date>           <typename>               <tysource sourcetype="imsdefault"/>               <tyvalue>Award</tyvalue>           </typename>           <datetime>1980:7</datetime>        </date>        <units>           <unitsfield>               <fieldlabel>                  <typename>                      <tyvalue>CreditNumber</tyvalue>                  </typename>               </fieldlabel>               <fielddata>10</fielddata>           </unitsfield>        </units>        <learningactivityref>           <text>HNC in Mathematics</text>        </learningactivityref>    </activity> </learnerinformation>

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/actv_lref_001/actv_lref_001.xml. The key features of this example are:

• The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7).  This must be used for all further references to this learner;

• The type of activity is defined in line 14;

• The content of the record is based upon the date of the activity (lines 21-27), the credits assigned to the activity (lines 28-37) and the external reference to the learning activity (lines 38-40).

The next stage is to create a second learningactivityref record for the same learner.  The example contains all of the IMS LIP information required to construct the instance record.

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

<learnerinformation>    <comment>An example of LIP Activity information.</comment>    <contentype>        <referential>           <sourcedid>               <source>IMS_LIP_V1p0_Example</source>               <id>2001</id>           </sourcedid>        </referential>    </contentype>    <activity>        <typename>           <tysource sourcetype="imsdefault"/>           <tyvalue>Education</tyvalue>        </typename>        <contentype>           <referential>               <indexid>activity_2</indexid>           </referential>        </contentype>        <date>           <typename>               <tysource sourcetype="imsdefault"/>               <tyvalue>Award</tyvalue>           </typename>           <datetime>1988:7</datetime>        </date>        <learningactivityref>           <text>HND in Electronics</text>        </learningactivityref>    </activity> </learnerinformation

This example is stored in the file: IMS_LIPv1p0/Valid/Basic/actv_lref_002/actv_lref_002.xml. The key features of this example are:

• The core record for this learner is identified by the <sourcedid> of ‘IMS_LIP_V1p0Example:basic_2001’ (lines 6 and 7) – as per the previous learningactiviyref example;

• The type of activity is defined in line 14;

• The content of the record is based upon the date of the activity (lines 21-27) and the external reference to the learning activity (lines 28-30).

4.2.2     Activity Definition Examples

This example creates an activity containing a course definition record for the learner.  The example contains all of the IMS LIP information required to construct the instance record.

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98

<learnerinformation>    <comment>An example of LIP Activity information.</comment>    <contentype>        <referential>           <sourcedid>               <source>IMS_LIP_V1p0_Example</source>               <id>2001</id>           </sourcedid>        </referential>    </contentype>    <activity>        <typename>           <tysource sourcetype="imsdefault"/>           <tyvalue>Education</tyvalue>        </typename>        <contentype>           <referential>               <indexid>activity_1</indexid>           </referential>        </contentype>        <definition>           <typename>               <tysource sourcetype="imsdefault"/>               <tyvalue>Course</tyvalue>           </typename>           <contentype>               <referential>                  <indexid>DegreeCourse</indexid>               </referential>           </contentype>           <definition>              <typename>                  <tysource sourcetype="imsdefault"/>                  <tyvalue>Curriculum</tyvalue>               </typename>               <contentype>                  <referential>                      <indexid>Year1</indexid>                  </referential>               </contentype>               <definition>                  <typename>                      <tysource sourcetype="imsdefault"/>                      <tyvalue>Module</tyvalue>                  </typename>                  <contentype>                      <referential>                         <indexid>Electronics_101</indexid>                      </referential>                  </contentype>                  <definitionfield>                      <fieldlabel>                         <typename>       &n