IMS Logo

IMS Abstract Framework: Applications, Services, and Components

Version 1.0

Copyright © 2003 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Abstract Framework: Applications, Services, and Components
Revision: 01 July 2003 

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/af/afv1p0/afv1p0speclicense.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 Scope and Context
     1.2 Using this Document
     1.3 Structure of this Document
     1.4 Reference Documents
     1.5 List of Acronyms

2. Application Layer

3. Application Services Layer
     3.1 Assessment
     3.2 Calendar
     3.3 Class Administration
     3.4 Collaboration
     3.5 Commerce
     3.6 Competency Management
     3.7 Content Management
     3.8 Digital Repository Management
     3.9 Enterprise Service
     3.10 Group Management
     3.11 Learner Progression Management
     3.12 Membership Management
     3.13 Meta-data Management
     3.14 Party Management
     3.15 Portfolio Management
     3.16 Profile Management
     3.17 Sequencing
     3.18 Simulation

4. Common Services Layer
     4.1 Access Management
     4.2 Authentication
     4.3 Authorization
     4.4 Database Management
     4.5 Digital Rights Management
     4.6 Directory Service
     4.7 Discovery
     4.8 File Management
     4.9 Identification
     4.10 Querying
     4.11 Registry
     4.12 Relational Rules
     4.13 Scheduling
     4.14 Security and Privacy
     4.15 Subscription
     4.16 Tracking and Logging
     4.17 User Messaging
     4.18 Workflow

5. Sea of Components
     5.1 Accessibility
     5.2 Activity
     5.3 Affiliation
     5.4 Assessment
     5.5 Competency
     5.6 Content
     5.7 Course Catalogue
     5.8 Glossary
     5.9 Goal
     5.10 Grade-book
     5.11 Group
     5.12 Interest
     5.13 Item
     5.14 LOM
     5.15 Manifest
     5.16 Object-bank
     5.17 Outcomes Processing
     5.18 Party
     5.19 PLIRI
     5.20 Profile
     5.21 QCL
     5.22 Relationship
     5.23 Result Report
     5.24 Section
     5.25 SecurityKey
     5.26 Sequencing
     5.27 Syllabus
     5.28 Table of Contents
     5.29 Transcript

Appendix A - OKI APIs

About This Document

Revision History

Index

1. Introduction

1.1 Scope and Context

The IMS Abstract Framework (IAF) is a device to enable the IMS to describe the context within which it will continue to develop its eLearning technology specifications. This framework is not an attempt to define the IMS architecture, rather it is a mechanism to define the set of services for which IMS may or may not produce a set of interoperability specifications. In the cases where IMS does not produce a specification then every effort will be made to adopt or recommend a suitable specification from another organization.

The IAF is a layered framework consisting of the Applications, Application Services, Common Services and Infrastructure layers. This document addresses the set of applications and services that are included within the scope of the Applications, Application Services and Common Services layers. The list of these applications and services is not exhaustive and as such it will be extended as and when new examples are identified.

1.2 Using this Document

This is a 'living' document i.e., it is not archival in nature. Our ideas for various parts of the IAF are constantly being developed and so the information contained herein should always be considered in that context. This document is one of a set of closely related documents, the others being:

The list of applications, services, and components in this document will be continually developed and as such they will form the basis of the specification development work programme to be undertaken. Not all of the services and components listed will undergo specification by IMS.

1.3 Structure of this Document

The structure of this document is:

2. Application Layer
The brief description of some of the possible eLearning Applications;
3. Application Services Layer
The detailed description of the Application Services. This includes the definition of the different services including identification of the core application service components, interactions between the application services, interactions with the common services and the interactions with the applications layer;
4. Common Services Layer
The detailed description of the Common Services. This includes the definition of the different services including identification of the common components, interactions between the common services, interactions with the application services and the interactions with the infrastructure layer;
5. Components
The set of components that must be specified to support the identified set of application and common service;
Appendix A - OKI APIs
The set of APIs that have been developed under the Open Knowledge Initiative.

1.4 Reference Documents

[IMS, 03a]
IMS Abstract Framework: Glossary, K.Blinco, S.Griffin, J.Merriman, C.Smythe, IMS Publication, Final Release, July 2003.
[IMS, 03b]
IMS Abstract Framework: White Paper, C.Smythe, IMS Publication, Final Release, July 2003.
[IMS, 03c]
IMS Specification Development Methods & Best Practices, C.Smythe, IMS Publication, Final Release, July 2003.
[SIF, 00]
Schools Interoperability Framework Implementation Specification, V1.0, Software & Information Industry Association, June 2000.
[SIF, 01]
Schools Interoperability Framework Draft Data Objects Specification, Draft, Software & Information Industry Association, December 2001.

1.5 List of Acronyms

API
Application Programming Interface
OKI
Open Knowledge Initiative
OSID
Open Service Interface Definition
SIF
Schools Interoperability Framework
IAF
IMS Abstract Framework
XML
Extensible Mark-up Language
PDF
Portable Document Format
LMS
Learning Management System
LCMS
Learning Content Management System
HTML
Hypertext Mark-up Language
OPAC
Online Public Access Catalogue
SIS
Student Information System

2. Application Layer

The entities in the application layer are a direct reflection of the eLearning domains. As such these domains are defined as:

The intention is that the IAF can be adopted by different specification development organizations. As such this means that SIF will use it to support their work on specifications for K12, OKI for higher education, etc. Therefore, the applications listed below should be viewed as domain dependent, i.e., a K12 Assessment System will, in general, differ from a corporate training Assessment system but interoperability can be based upon the usage of the relevant profiled application services.

Only some of the applications available for eLearning applications are detailed below. The intention is not to create a definitive list but to identify a set of typical applications. The types of applications that could use the abstract framework application and common services are:

Note: IMS will not undertake the specification of these applications. They are out-of-scope of the IMS specification activity. Information concerning the types of applications is included to demonstrate how the set of application services and common services can be used.

3. Application Services Layer

Only some of the application services available for eLearning applications are detailed below. The intention is not to create a definitive list but to identify a set of core application services, such as:

Note: In general, the specification of the Components to supply these Application Services will be the core IMS specification activity. Also, an Application Service may or may not be an aggregation of other application services.

3.1 Assessment

Assessment

Service Description:
A service that is responsible for the presentation and reporting of an appropriate low-stakes/high stakes assessment. The assessment presentation and reporting is managed at the group and individual level.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • Assessment
  • Item
  • Object-bank
  • Section
  • Result Report
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.2 Calendar

Calendar

Service Description:
A service that enables events to be sequenced as per their date. The calendar has a resolution covering hours to years.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Common Service Dependencies:
  • Scheduling
Infrastructure Dependencies:
TBD.

3.3 Class Administration

Class Administration

Service Description:
A service allowing educational applications to use and manage information regarding classes and people. In higher education implementations this service typically defines the interface between educational applications and student information systems.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • Person
  • Group
  • Membership
Common Service Dependencies:
  • Scheduling
Infrastructure Dependencies:
TBD.

3.4 Collaboration

Collaboration

Service Description:
A service that enables two or more learners to work together through in an electronically mediated environment. Features include the provision of document sharing, white-boarding, application sharing, and videoconferencing.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.5 Commerce

Commerce

Service Description:
A service that provides financial administration information relevant to the eLearning system.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.6 Competency Management

Competency Management

Service Description:
A service that allows the management of the competencies-related aspects within an eLearning system. This includes the management of a learner's competencies, the creation of competency definitions and the association of these definitions within learner content, etc.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • RDCEO
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.7 Content Management

Content Management

Service Description:
A service that provides mechanisms for the creation, flexible management (e.g., aggregation, sequencing, dynamic rendering) and publishing of content. This service allows educational applications to publish, deliver, search for, and manage rights, role and meta-data information on digital assets.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • Manifest
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.8 Digital Repository Management

Digital Repository Management

Service Description:
A service that enable access to, and the management, of a Repository. The repository may contain any type of content consistent with its function.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • LOM
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.9 Enterprise Service

Enterprise

Service Description:
A service that enables the management of learning activities that are based upon groups e.g., courses. This is an aggregation of other application services.
Service Access Points:
  • Party Service;
  • Group Service;
  • Membership Service.
Core Attributes:
TBD.
Core Components:
  • Party;
  • Group;
  • Membership.
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.10 Group Management

Group Management

Service Description:
A service that enables the management of Groups. A group can consists of other groups and may or may not have its own sub-groups.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • Group
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.11 Learner Progression Management

Learner Progression Management

Service Description:
A service that is used to access and manipulate the information related to the progression of a learner through learning activities.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • Profile
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.12 Membership Management

Membership Management

Service Description:
A service that enables the management of memberships. A party or group can be a member of a group. The membership information describes the role(s) that are undertaken as part of that membership.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • Membership
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.13 Meta-data Management

Meta-data Management

Service Description:
A service that enable access to, and the manipulation of, the meta-data for a set of objects.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • LOM
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.14 Party Management

Party Management

Service Description:
A service that enables the management of a party. A party is either a person or an organization.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • Party
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.15 Portfolio Management

Portfolio Management

Service Description:
A service that enables the management of ePortfolios.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.16 Profile Management

Profile Management

Service Description:
A service that enables access to, and the manipulation of a learner's profile. This service enables a single point of management access to a profile that may be replicated and or distributed in partial form across many Profile Repositories.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • Profile
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.17 Sequencing

Sequencing

Service Description:
A service that enables any set of objects to be performed in any particular sequence. The set of possible sequences is defined using an appropriate set of sequencing rules.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • Sequencing
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

3.18 Simulation

Simulation

Service Description:
A service that enables real-time simulation of a system to be rendered through a generic interface. Any type of system can be simulated and so this service defines the set of permitted interactions to a particular simulation.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Common Service Dependencies:
TBD.
Infrastructure Dependencies:
TBD.

4. Common Services Layer

The following set of common services is not exhaustive, but is indicative of those that are to required by the different applications and application services (the set of OKI APIs that are available to support some of these common services are listed in Appendix A):

Note: In general the IMS will not undertake the specification of these services1. This is because they are generic in nature and as such are equally valuable in domains other than eLearning. Wherever possible IMS will advocate the adoption of specifications for these services that have been developed by other activities e.g., OKI (the set of OKI APIs are listed in Appendix A).

4.1 Access Management

Access Management

Service Description:
A service that manages data about users, user profiles and services to access control systems so that authenticated users have access to those system, functions and resources that they are authorized to use. Single sign on, where the user is challenged for a single name and password and has access to more than one system or resource, functionality is also included.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • A trusted communications infrastructure for the service.

4.2 Authentication

Authentication

Service Description:
The authentication service gathers required credentials from an agent, vouches for their (the credentials) authenticity and introduces the agent to the system. The invoking application can determine and manipulate the authentication status of an agent without having to manage the details of a particular institution's environment. The service must work over various kinds of authentication infrastructure. Many institutions already have, or are striving for, central authentication. Examples of technologies in play include Kerberos, X.509 and cookie-based single sign-on technologies such as webISO. Increasingly institutions will be reaching beyond their traditional boundaries and operating in a universe of federated security domains, as for example with Shibboleth.


Not only must the service handle different methods across the range of institutions, it must also handle these within a given institution. Some applications might rely on userid/password; some on certificates; most users authenticate locally; some might remotely. This range is represented in the interface using the concept of authentication type. There is typically a default type at an institution, the common method of authentication for the generality of use. Additional types are available to accommodate the rest.


An agent, a human or inhuman principal, is authenticated according to one or more such types. There are, indeed, situations when an agent may need to be authenticated more than once in a session. This can happen when an agent switches from one type of activity to another. Checking the class schedule, for example, may require userid/password, while updating the final grades may require an X.509 certificate issued with a high level of assurance.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • A trusted communications infrastructure for the service.

4.3 Authorization

Authorization

Service Description:
A service that allows applications and application services to establish and query Authorizations. An Authorization has three components: the Agent that is authorized; the Function that the Agent is authorized to do; and the Qualifier representing the context in which the Agent can perform the Function.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • A trusted communications infrastructure for the service.

4.4 Database Management

Database Connectivity

Service Description:
A service that allows an application or application service to access and update the contents of a database. The intent of this service is to allow actual connection to the database to exist on a machine other than the machine hosting the application.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • A reliable end-to-end communications system.

4.5 Digital Rights Management

Digital Rights Management

Service Description:
A service that provides mechanisms to enable permissions over learning object usage to be offered, controlled, tracked, and managed. The service also provides for the management of rights holders and their entitlements related to the usage of learning objects.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • A trusted communications infrastructure for the service.

4.6 Directory Service

Directory Service

Service Description:
A service that typically holds information about network-accessible entities such as services, other repositories, specifications, content objects, people and organizations, and provides a way of storing, manipulating and retrieving directory information that is both human and machine accessible. Information required by other services such as an authorization service or digital rights management service may be provided by a directory service.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • Optional usage of LDAP;
  • Optional support for X.500.

4.7 Discovery

Identification

Service Description:
A service that enables the discovery of learning materials and other related information. Discovery is an action resulting from a query that involves presentation of results to the user. Querying typically depends on meta-data being exposed for effective discovery. Querying, browsing, 'following a path' are all a part of the discovery function.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • Optional usage of UDDI.

4.8 File Management

File Management

Service Description:
A service that provides a way of storing and retrieving static content. It provides an abstraction layer between the file system and the Application. This service may also provide automated recovery using multiple physical copies of a logical file.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • Should make usage of FTP;
  • A trusted communications infrastructure for secure file access.

4.9 Identification

Identification

Service Description:
A service that is responsible for producing and making available Global/Local User Identifiers (GUIDs/LUIDs).
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
  • PLIRI
Infrastructure Dependencies:
  • A trusted communications infrastructure for the service.

4.10 Querying

Querying

Service Description:
A service that permits a repository to be searched for objects that conform to a defined set of criteria. Querying is an operation performed typically by a user or agent wishing to discover and have information delivered from a system.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • Support for XML based and non-XML based querying and aggregation across a reliable communications system.

4.11 Registry

Registry

Service Description:
A service that enables access to, and the manipulation of, a registry. A registry typically holds meta-data schemas, configuration data, application profiles, identifiers or other lookup data that is both human and machine accessible.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • A reliable end-to-end communications system.

4.12 Relational Rules

Relational Rules

Service Description:
A service that enables relationship rules to be established between objects. These rules are stored in an appropriate Rules Repository.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • A reliable end-to-end communications system.

4.13 Scheduling

Scheduling

Service Description:
A service that enables a sequence of events to be tabled according to a particular calendar. This service enables activities from one or more sources to be coordinated using a single schedule.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • A reliable end-to-end communications system.

4.14 Security and Privacy

Security and Privacy

Service Description:
A service that provides data encryption thereby making the information private and/or secure (the degree of depends on the cryptographic security of the encryption codes). This service may or may not be used in conjunction with other similar services supplied as a part of the Infrastructure Layer.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • A reliable end-to-end communications system.

4.15 Subscription

Subscription

Service Description:
A service that provides the mechanism by which learners can subscribe to available services. This subscription may or may not include a financial transaction.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • A trusted communications infrastructure for the service.

4.16 Tracking and Logging

Tracking and Logging

Service Description:
A service that enables any other service to be tracked and the corresponding information and events to be logged. The log will be made available via a range of report formats. The tracking of a service enables all of the sequence of stable and meta-stable states to be recreated. The purpose of the Logging Service is to support logging throughout the system for diagnostic, performance: metrics, tuning, benchmarking, monitoring, security, performance, data collection, usage or trend analysis, forecasting, and statistics.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • A trusted communications infrastructure for the service.

4.17 User Messaging

User Messaging

Service Description:
A service that supports posting of instant or deferred and/or reliable messages from user to user, user to group, or system to user.
Service Access Points:
TBD.
Core Attributes:
TBD.
Core Components:
TBD.
Infrastructure Dependencies:
  • Based upon the Internet Protocol Suite messaging services: SMTP, POP3, and IMAP.

4.18 Workflow

Workflow

Service Description:
A service that supports the automation of the learning process. As such it allows a set of procedural rules to be defined and actioned across a number of actors and supporting systems.
Service Access Points:


Core Attributes:


Core Components:


Infrastructure Dependencies:

5. Sea of Components

The following set of components is not exhaustive, but is indicative of those that are to be developed by IMS:

5.1 Accessibility

Accessibility Component

Component Description:
An Accessibility Component contains the data structures and interfaces responsible for describing 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.
Source Specification(s):
  • IMS LIP V1.0 (<accessibility>)
  • IMS Accessibility Guidelines V1.0
  • IMS ACCLIP V1.0
Interfaces:
TBD.
Core Attributes:
TBD.
Protocol Requirements:
TBD.
Component Dependencies:
  • PLIRI
  • Vocabulary

5.2 Activity

Activity Component

Component Description:
An Activity Component contains the data structures and interfaces responsible for describing the learning materials produced by the learner. This may consist 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.
Source Specification(s):
  • IMS LIP V1.0 (<activity>)
Interfaces:
TBD.
Core Attributes:
TBD.
Protocol Requirements:
TBD.
Component Dependencies:
  • Content
  • Results Report
  • Content
  • Vocabulary
  • PLIRI

5.3 Affiliation

Affiliation Component

Component Description:
An Affiliation Component contains the data structures and interfaces responsible for describing the organization affiliations associated with the learner e.g., professional memberships.
Source Specification(s):
  • IMS LIP (<affiliation>)
Interfaces:
TBD.
Core Attributes:
TBD.
Protocol Requirements:
TBD.
Component Dependencies:
  • Vocabulary
  • PLIRI

5.4 Assessment

Assessment Component

Component Description:
An Assessment Component contains all of the necessary instructions to enable the presentation of the associated Items, variable sequencing of the Items, the aggregated scoring for all of the Sections/Items to produce the final score(s), and the corresponding feedback. The Section Component is used to construct the appropriate hierarchical Section/Item groups. The results from an Assessment can be reported using the Result Report Component.
Source Specification(s):
  • IMS QTI V1.2 (<assessment>)
Interfaces:
TBD.
Core Attributes:
TBD.
Protocol Requirements:
TBD.
Component Dependencies:
  • Section
  • Item
  • Content
  • Sequencing
  • Outcomes Processing
  • Vocabulary
  • LOM
  • PLIRI

5.5 Competency

Competency Component

Component Description:
A Competency Component contains the data structures and interfaces responsible for describing 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 Component).
Source Specification(s):
  • IMS LIP V1.0 (<competency>)
  • IMS RDCEO V1.0
  • HR-XML Competency Definition
Interfaces:
TBD.
Core Attributes:
TBD.
Protocol Requirements:
TBD.
Component Dependencies:
  • Vocabulary
  • PLIRI

5.6 Content

Content Component

Component Description:
A Content Component contains the data structures and interfaces responsible for describing the logical structure, physical layout and associated presentation styles of the learning material. The material itself can take the form of text, image, video, audio, applet and an executable application. Alternative content issues are also addressed to support multi-lingual systems and to ensure the accessibility of the material.
Source Specification(s):
  • IMS QTI V1.2
  • IMS Learning Design V1.0
  • IMS Accessibility Guidelines V1.0
Interfaces:
TBD.
Core Attributes:
TBD.
Protocol Requirements:
TBD.
Component Dependencies:
TBD.

5.7 Course Catalogue

Course Catalogue Component

Component Description:
A Course Catalogue Component contains the data structures and interfaces responsible for listing the set of courses available to a learner. The catalogue contains at least the title, identifiers, and the start/end dates of the course. Other information may also be made available depending on the type of catalogue.
Source Specification(s):
  • IMS Enterprise V1.1 (<group>)
Interfaces:
TBD.
Core Attributes:
TBD.
Protocol Requirements:
TBD.
Component Dependencies:
  • Vocabulary
  • PLIRI

5.8 Glossary

Glossary Component

Component Description:
A Glossary Component contains the data structures and interfaces responsible for defining a glossary of key words and phrases. It is possible to define different types of glossary and to have hierarchical glossaries.
Source Specification(s):
  • IMS Learning Design V1.0
Interfaces:
TBD.
Core Attributes:
TBD.
Protocol Requirements: