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.

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

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

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.

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.

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.

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

Time-related information;

Identification and indexing information;

Privacy and data protection information.

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

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.

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.

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.

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

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

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

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

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

Data structures

Learner info - the actual learner information data itself

Access - the access rights to the learner information data i.e. who can
see what

Messaging - the messaging protocol used to implement the actual profile
interchanges;

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

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

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

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

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

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

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.

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

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

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

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

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

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.

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

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

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

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.

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

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

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

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

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

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

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.

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.

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It is important to state that:

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

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

The exchange of LIP instances requires the following processing capabilities:

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

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

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

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

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

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

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

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

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

interest

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

transcript

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

affiliation

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

securitykey

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

relationship

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

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

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

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

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.

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

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

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

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

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

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.

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.

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.

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

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

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

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

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

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.

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

O

String.

These comments should be used to annotate the XML files.

13.2.1

langtype

The default language used for the comment.

As per structure 13.1 (Table 6.13).

13.3

contentype

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

O

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

13.3.1

referential

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

M

n

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

13.3.1.1

sourcedid

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

C

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

13.3.1.1.1

source

The name of the source system creating the learner
information.

M

#PCDATA
1-256 chars.

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

13.3.1.1.2

id

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

M

ID
1-256 chars.

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

13.3.1.2

indexid

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

C

ID
1-256 chars.

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

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

13.3.2

temporal

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

O

n

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

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

13.3.2.1

typename

The type of temporal relationship

M

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

13.3.2.2

temporalfield

The fields defined to contain the temporal data structures.

M

n

13.3.2.2.1

fieldlabel

The field type that will contain the
temporal definition data.

M

As per structure 13.10.

13.3.2.2.2

fielddata

The field type that will contain the temporal data.

M

As per structure 13.11.

13.3.3

privacy

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

O

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

13.3.3.1

privacyfield

The fields defined to contain the privacy data structures.

M

n

13.3.3.1.1

fieldlabel

The field type that will contain the privacy definition data.

M

As per structure 13.10.

13.3.3.1.2

fielddata

The field type that will contain the privacy data.

M

As per structure 13.11.

13.3.3.3

date

Dates appropriate to the privacy information e.g. expiry

O

n

As per structure 13.6 (Table 6.13).

13.4

typename

The label of the object whose type is being defined.

O

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

13.4.1

tysource

The source of the vocabulary.

O

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

13.4.1.1

sourcetype

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

O

Enumerated list of:

imsdefault (default)

standard

list

proprietary

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

13.4.2

tyvalue

The textual entry for the selected type.

M

String.
1-256 chars.

This will have an associated language string.

13.4.2.1

langtype

The default language used for the typing data.

As per structure 13.1 (Table 6.13).

13.5

description

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

O

13.5.1

short

A one line, text description.

M

String.
1-128 chars.

13.5.1.1

langtype

The default language used for the short description.

As per structure 13.1 (Table 6.13).

13.5.2

long

A detailed textual description.

O

String.
1-2048 chars.

13.5.2.1

langtype

The default language used for the typing data.

As per structure 13.1 (Table 6.13).

13.5.3

full

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

O

13.5.3.1

comment

As per structure 13.2.

13.5.3.2

media

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

M

n

As per structure 13.12.

13.6

date

The date and/or time to be recorded.

O

13.6.1

typename

The type of date.

O

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

13.6.2

datetime

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

M

String.
1-20 chars.

As defined by the ISO8601.

13.6.3

description

The description of the date.

O

As per structure 13.5.

13.6.4

extension

The extension facility for the ‘date’ learner information.

O

As per structure 13.16.

13.7

priority

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

O

String.
1-64 chars.

13.7.1

langtype

The default language used for the priority.

As per structure 13.1 (Table 6.13).

13.8

status

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

O

13.8.1

typename

The type of status.

O

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

13.8.2

date

The date that the status entry was made.

O

As per structure 13.6.

13.8.3

description

The status entry.

O

As per structure 13.5.

13.9

product

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

O

13.9.1

typename

The type of product.

O

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

13.9.2

comment

As per structure 13.2.

13.9.3

contentype

As per structure 13.3.

13.9.4

date

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

O

As per structure 13.6.

13.9.5

description

The product itself.

O

As per structure 13.5.

13.9.6

extension

The extension facility for the ‘product’ learner information.

O

As per structure 13.16.

13.10

fieldlabel

Field definition extensions.

O

n

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

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

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

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

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

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 IMS
QTI specification for Assessments, Sections and Items as defined by the
QTI specification [QTI, 00a].

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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