IMS Question and Test Interoperability Overview Version 2.0 Final Specification

Copyright © 2005 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a registered trademark of IMS/GLC.
Document Name: IMS Question and Test Interoperability Overview
Revision: 24 January 2005

Table of Contents

1. Question and Test Interoperability

1.1. History of this Specification

1.2. Scope

2. Specification Use Cases

2.1. Use Case Actors

3. Structure of this Specification

4. References

1. Question and Test Interoperability

The IMS Question & Test Interoperability (QTI) specification describes a data model for the representation of question (assessmentItem) and test (assessment) data and their corresponding results reports. Therefore, the specification enables the exchange of this item, assessment and results data between authoring tools, item banks, learning systems and assessment delivery systems. The data model is described abstractly, using [UML] to facilitate binding to a wide range of data-modeling tools and programming languages, however, for interchange between systems a binding is provided to the industry standard eXtensible Markup Language [XML] and use of this binding is strongly recommended. The IMS QTI specification has been designed to support both interoperability and innovation through the provision of well-defined extension points. These extension points can be used to wrap specialized or proprietary data in ways that allows it to be used alongside items that can be represented directly.

1.1. History of this Specification

An initial V0.5 specification was released for discussion in March 1999 and in November it was agreed to develop IMS Question & Test Interoperability v1.0 which was released as a public draft in February 2000 and as a final specification in May that year. The specification was extended and updated twice, in March 2001 and January 2002. By February of that year in excess of 6000 copies of the IMS QTI 1.x specifications had been downloaded from the IMS web-site.

Since then, a number of issues of have been raised by implementers and reviewed by the QTI project team. Many of them were dealt with in an addendum, which defined version 1.2.1 of the specification and was released in March 2003. Some of the issues could not be dealt with this way as they required changes to the specification that would not be backwardly compatible or because they uncovered more fundamental issues that would require extensive clarification or significant extension of the specification to resolve.

Since the QTI specification was first conceived, the breadth of IMS specifications has grown and work on Content Packaging, Simple Sequencing and most recently Learning Design created the need for a cross-specification review. This review took place during 2003 and a number of harmonization issues affecting QTI were identified. In September that year a project charter was agreed to address both the collected issues from 1.x and the harmonization issues and to draft QTI V2.0. In order to make the work manageable and ensure that results were returned to the community at the earliest opportunity some restrictions were placed on the scope of the recommended work. Therefore, this release of the specification concentrates only on the individual assessmentItem and does not update those parts of the specification that dealt with the aggregation of item's into sections and assessments or the reporting of results.

1.2. Scope

The IMS QTI work specifically relates to content providers (that is, question and test authors and publishers), developers of authoring and content management tools, assessment delivery systems and learning systems. The data model for representing question-based content is suitable for targeting users in learning, education and training across all age ranges and national contexts.

2. Specification Use Cases

QTI is designed to facilitate interoperability between a number of systems that are described here in relation to the actors that use them.

Specifically, QTI is designed to:

• Provide a well documented content format for storing items independent of the authoring tool used to create them.
• Support the deployment of item banks across a wide range of learning and assessment delivery systems.
• Support the deployment of items and item banks from diverse sources in a single learning or assessment delivery system.
• Provide systems with the ability to report test results in a consistent manner.

The Role of Assessments and Assessment Items

authoringTool

A system used by an author for creating or modifying an assessment item.

itemBank

A system for collecting and managing collections of assessment items.

assessmentDeliverySystem

A system for managing the delivery of assessments to candidates. The system contains a delivery engine for delivering the items to the candidates and scores the responses automatically (where applicable) or by distributing them to scorers.

learningSystem

A system that enables or directs learners in learning activities, possibly coordinated with a tutor. For the purposes of this specification a learner exposed to an assessment item as part of an interaction with a learning system (i.e., through formative assessment) is still described as a candidate as no formal distinction between formative and summative assessment is made. A learning system is also considered to contain a delivery engine though the administration and security model is likely to be very different from that employed by an assessmentDeliverySystem.

2.1. Use Case Actors

The set of roles identified in this specification have been reduced to a small set of abstract actors for simplicity. Typically roles in real learning and assessment systems are more complex but, for the purposes of this specification, it is assumed that they can be generalized by one or more of the roles defined here.

author

The author of an assessment item. In simple situations an item may have a single author, in more complex situations an item may go through a creation and quality control process involving many people. In this specification we identify all of these people with the role of author. An author is concerned with the content of an item, which distinguishes them from the role of an itemBankManager. An author interacts with an item through an authoringTool.

itemBankManager

An actor with responsibility for managing a collection of assessment items with an itemBank.

proctor

A person charged with overseeing the delivery of an assessment. Often referred to as an invigilator. For the purposes of this specification a proctor is anyone (other than the candidate) who is involved in the delivery process but who does not have a role in assessing the candidate's responses.

scorer

A person or external system responsible for assessing the candidate's responses during assessment delivery. Scorers are optional, for example, many assessment items can be scored automatically using response processing rules defined in the item itself.

tutor

Someone involved in managing, directing or supporting the learning process for a learner but who is not subject to (the same) assessment.

candidate

The person being assessed by an assessment or assessment item.

3. Structure of this Specification

The specification is spread over a number of documents:

Implementation Guide: A document that takes you through the data model for assessment items by example. The best starting point for readers who are new to QTI and want to get an idea of what it can do.
• Information Model: The reference guide to the main data model for assessment items. The document provides detailed information about the model and specifies the requirements of delivery engines and authoring systems.
• Meta-data and Usage Data: A document that describes a profile of the IEEE Standard for Learning Object Metadata [LOM] data model suitable for use with assessment items and a separate data model for representing usage data (i.e., item statistics). This document will be of particular interest to developers and managers of item banks and other content repositories, and to those who construct assessments from item banks.
• Integration Guide: A document that describes the relationship between this specification other related specifications such as IMS Content Packaging [IMS_CP], IMS Simple Sequencing [IMS_SS] and IMS Learning Design [IMS_LD].
• XML Binding: A document describing the way the data models have been bound to [XML].
• Conformance Guide: A document that describes conformance requirements and provides a data model for the construction of QTI profiles including a predefined profile that replaces the QTI Lite specification [QTI_LITE] released as part of version 1.
• Migration Guide: A document aimed at people familiar with version 1.x. It takes you through the main changes that have been made to the data model and includes an alphabetical listing of version 1 elements providing detailed information about how the same information is represented in version 2.

This specification updates version 1 however, in its current form, it does not yet replace it entirely. The following documents were released with version 1.2:

• ASI Information Model [ASI_INFO], XML Binding [ASI_BIND] and Best Practice Guide [ASI_BP]: these documents describe the Assessment, Section and Item data-models with associated bindings and examples. The item data-model defined by this specification obsoletes the one in these documents but the assessment and section data models are still current. See Migration Guide for advice on using these structures together with the updated new data-model.
• QTILite Specification [QTI_LITE]: this document is now obsolete. It has been replaced with a profile of the new data-model described in Conformance Guide and the packaging recommendations given in Integration Guide.
• ASI Selection & Ordering [QTI_SAO]: this document describes methods of determining the sequence of items within assessments and sections and is still current. This part of the specification has not been widely deployed and the suggested solutions given in Integration Guide should be considered as an alternative until an updated version becomes available (or it is made obsolete).
• ASI Outcomes Processing [QTI_OUT]: this document describes methods of aggregating the outcomes from individual items and sections to create a set of section or assessment level outcomes. This specification is still current.
• Results Reporting Information Model [RR_INFO], XML Binding [RR_BIND] and Best Practice Guide [RR_BP]: these documents are still current. Developers are encourage, however, to look also at the itemSession data-model defined in this specification.

4. References

ASI_BIND

IMS Question & Test Interoperability: ASI XML Binding Specification, Version 1.2

Published: 2002-02

ASI_BP

IMS Question & Test Interoperability: ASI Best Practice & Implementation Guide, Version 1.2

Published: 2002-02

ASI_INFO

IMS Question & Test Interoperability: ASI Information Model Specification, Version 1.2

Published: 2002-02

IMS_CP

IMS Content Packaging Specification, Version 1.3.1

IMS_LD

IMS Learning Design Specification, Version 1.0

Published: 2003-01

IMS_SS

IMS Simple Sequencing Specification, Version 1.0

Published: 2003-03

LOM

IEEE 1484.12.1-2002 Standard for Learning Object Meta-data (LOM)

QTI_LITE

QTI Lite

QTI_OUT

IMS Question & Test Interoperability: ASI Outcomes Processing, Version 1.2

Published: 2002-02

QTI_SAO

IMS Question & Test Interoperability: ASI Selection & Ordering, Version 1.2

Published: 2002-02

RR_BIND

IMS Question & Test Interoperability: Results Reporting XML Binding, Version 1.2

Published: 2002-02

RR_BP

IMS Question & Test Interoperability: Results Reporting Best Practice & Implementation Guide, Version 1.2

Published: 2002-02

RR_INFO

IMS Question & Test Interoperability: Results Reporting Information Model, Version 1.2

Published: 2002-02

UML

OMG Unified Modeling Language Specification, Version 1.4

Published: 2001-09

XML

Extensible Markup Language (XML), Version 1.0 (second edition)

Published: 2000-10

About This Document

List of Contributors

The following individuals contributed to the development of this document:

Revision History