IMS Final Release

 

IMS Accessible Portable Item Protocol™ (APIP™): Technical Specification Overview

 

Final Specification
Version 1.0

 

Date Issued:            31 March 2014

Latest version:         http://www.imsglobal.org/apip/

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 draws attention to the fact that it is claimed that compliance with this specification may involve the use of Measured Progress U.S. patent 8,303,309. IMS takes no position concerning the evidence, validity or scope of such patent rights. Measured Progress has assured IMS that it is willing to license patent rights it owns or controls which would necessarily be infringed by any implementation of this specification to those licensees (Members and non-Members alike) desiring to implement this specification. The statement of Measured Progress to such effect has been filed with IMS. Information regarding a Reasonable and Non-Discriminatory - Zero cost (RAND-Z) license may be obtained from Measured Progress at http://www.measuredprogress.org/ipr-apip.

Attention is also drawn to the possibility that some of the elements of this specification may be the subject of patent rights other than those identified above. IMS shall not be responsible for identifying any or all such patent rights. 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 © 2012-14 IMS Global Learning Consortium. All Rights Reserved.

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/speclicense.html.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

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.

Public contributions, comments and questions can be posted here: http://www.imsglobal.org/community/forum/categories.cfm?catid=110

© 2014 IMS Global Learning Consortium, Inc.
All Rights Reserved.

The IMS Logo, Accessible Portable Item Protocol (APIP), and Question and Test Interoperability (QTI) are trademarks of the IMS Global Learning Consortium, Inc. in the United States and/or other countries.
Document Name:  IMS APIP Technical Specification Overview - Revision: 31 March 2014

Executive Summary

This document contains the technical specification overview of the Accessible Portable Item Protocol™ (APIP™) Standard.  The APIP Standard provides assessment programs and question item developers with a data model for standardizing the interchange file format for digital test items. When applied properly, the APIP standard accomplishes two important goals. First, the standard allows digital Tests and Items to be ported across APIP compliant test item banks.  Second, it provides a test delivery interface with all the information and resources required to make a Test and Item accessible for students with a variety of disabilities and special needs.  In this version of the APIP Standard the focus is on:

a)      Enabling the exchange of question Items and Tests;

b)      Adopting, wherever possible, established learning technology interoperability standards and specifications, and only extending these when required;

c)      Ensuring that the solution can be readily expanded, at a later date, to support the exchange of other related assessment information;

d)     Ensuring the solution can be combined with other IMS Global Learning Consortium (IMS) and non-IMS specifications to support new functionality e.g. the reporting of assessment scores and outcomes;

e)      Ensuring that further profiling can be undertaken to tailor the approach to meet the needs of specific State assessment activities without compromising the baseline interoperability requirement and capability;

f)       Enabling vendors to adopt the solution without constraining their ability to create market-differentiated products and services.

The APIP standard builds on the IMS Question and Test Interoperability (QTI) v2.2 specification; this in turn makes use of the IMS Content Packaging (CP) v1.2 specification. The APIP Standard expands the QTI model into a comprehensive framework that encompasses the requirements for creating accessible tests.  The IMS Access For All Personal Needs & Preferences (AfA PNP) v2.0 specification is also adopted as the basis for supplying the user preferences when using an APIP-enabled system.  It is these accessibility preferences that are used by an assessment system to tailor, in real-time, the presentation of the question items to fit the accessibility needs of the user.

The technical specification work has involved the development of extensions to the base IMS specifications and profiling of several IMS and non-IMS specifications.  Profiling is the process by which, one or more specifications, are tailored and combined to provide a best practice solution.  It is this combination of specifications that makes the APIP a powerful solution.

A conformance program and online validation tool have also been developed and deployed. Organizations that wish to achieve content or system compliance are encouraged to contact IMS.  The APIP Project Team welcomes feedback and advice from the community for the improvement of this proposed standard.

1.               Introduction

1.1.         The Context for APIP

The Accessible Portable Item Protocol (APIP) Standard provides assessment programs and item developers with a tool for standardizing the file format of digital test items. When applied properly, the APIP standard accomplishes two important goals. First, the standard allows digital test items to be ported across APIP compliant test item banks. Second, it provides a test delivery interface with all the information and resources required to make a test item accessible for students with a variety of disabilities and special needs.

The APIP standard builds on the IMS Question and Test Interoperability (QTI) and the Access for All Personal Needs and Preferences (AfA PNP) specifications. QTI is based on an Item and Test model that allows item developers to specify a variety of information about a test item. Test items, directions, and other test information can then be brought together in a test section, or a complete assessment. The APIP standard expands the QTI model into a comprehensive content accessibility framework for Items and Tests.  The AfA PNP defines the data model for the exchange of user (student) preferences for the use of learning systems.  Again, APIP has expanded this specification.

The concept of test accommodations has evolved rapidly over the past decade as a result of computer-based test delivery. Test accommodations have traditionally been defined as changes to test conditions made after a test was developed. Since changes were made post-hoc, concerns often surfaced about the extent to which changes affected the measure of the intended construct. In addition, when changes were made by local test administrators concerns were raised about the accuracy of the changes.

However, computer-based test delivery provides important opportunities to define appropriate changes to the presentation or administration of test content a priori and to standardize the provision of these changes across all test takers.  In essence, this transition from post-hoc changes to a priori specifications has resulted in a shift from test accommodations to test accessibility. This shift from accommodations to accessibility is reflected in many recent papers, reports, and, most importantly, guidelines for test accommodations developed by the Council of Chief State School Officers Assessing Student Education Students (CCSSO ASES) group. APIP is an attempt to evaluate the potential and capability of the specification-based approach.

1.2.         Conceptual Overview

APIP is an interoperability standard that enables the exchange of assessment content, the exchange of one or more test-takers accessibility needs, and provides expectations for a computer-based, accessible, assessment delivery system. APIP focuses on the tools and settings used by students, rather than assuming a particular physical or cognitive diagnosis prescribes the solution. It enables educators to make decisions that support the specific needs of individual students.

The goal of APIP is to ensure that when an assessment is initiated for a test-taker, that test-taker will have all the tools available to them needed to access the assessment materials. Optimally, the test-taker will not be provided with tools that are not necessary, and may be distracting, and thereby negatively impact the measurement of the test-taker's true abilities. To achieve that goal, the APIP standard provides three major components (as shown in Figure 1.1), including: 1) an XML-based exchange format for assessment content, 2) an XML-based exchange format for online assessment tool preferences for test-takers (called a Personal Needs and Preferences file), and 3) a certification process to ensure an APIP delivery system is capable of importing and properly using information supplied by APIP accessible content and APIP PNP files.

Authoring tools yield APIP accessible content. Roster tools (specifically preference systems) yield APIP Personal Needs and Preferences profile (PNP) information. APIP delivery systems deliver APIP content in a way that meets student needs as specified in their PNP.

Figure 1.1 The APIP Major Components Set

APIP Accessible Content may be created by a single organization, or may involve a string of organizational exchanges to complete the accessible information for the content. Content authoring systems/applications may use their own proprietary data storage formats. As long as the authoring system(s) can import and/or export APIP formatted content packages, that system will be considered an APIP content system. Content authoring systems may or may not store the assessment content in the APIP XML defined structures. APIP content is primarily concerned with interoperability -  transferring accessible assessment content from one organization to another (see the use cases in section 1.3), or between systems within an organization.

APIP PNP files store specific tool and assessment session preferences for individual students. The information contained in these files is designed to be used by an APIP compliant delivery system at the time of an assessment session. The intent is for the specific accessibility information supplied in these files to instruct the delivery system which specific accessibility tools or settings should be used for the test-taker during the assessment session. PNP files could come from a variety of sources including (but not limited to) student information systems, assessment rostering systems, or other academic administrative systems.

An APIP Delivery System is capable of importing the information supplied in the APIP content packages, and delivering that content to test-takers. Using individual test-taker preference information supplied by APIP PNP files, the delivery system will provide the test-taker with the necessary tools and settings to access the assessment's content. If needed, the delivery system will use the additional accessibility information supplied in the APIP accessible content and present that content to the test-taker. In many cases, the delivery system does not need information supplied in the accessibility portion of the content to provide the settings for the test taker. For example, the test-taker's PNP may indicate they need extra time to complete the assessment. No accessibility information needs to be included in the content file in order to provide that setting for the test-taker. That setting would be provided by the delivery system itself.

APIP does NOT recommend or enforce specific choices about the how content should be made accessible, which tools should be assigned to test-takers, or specific technical or interface solutions for delivery systems. APIP provides the structure to enable educators and developers to make choices of their own. Using the standard, organizations can exchange their choices with other organizations. There is likely a great deal of effort that will need to be taken by programs to define their specific implementation business rules. APIP is designed to support the decisions made by these programs.

1.3.         The Core Use Cases

Version 1.0 of APIP is designed to support six core use cases, in addition to other minor ones:

•         Importing of APIP Item(s) into an APIP compliant system/application/tool - the reading of an APIP interchange file (a form of zip file) and the storage of the contents of that file in the system/application/tool;

•         Exporting of APIP Item(s) from APIP compliant system/application/tool - the creation of an APIP interchange file that can be stored in an external repository and/or which can be imported into another APIP-compliant system/application/tool;

•         Importing of APIP Test(s) into an APIP compliant system/application/tool - the reading of an APIP interchange file (a form of 'zip' file) and the storage of the contents of that file in the system/application/tool;

•         Exporting of APIP Test(s) from APIP compliant system/application/tool - the creation of an APIP interchange file that can be stored in an external repository and/or which can be imported into another APIP-compliant system/application/tool;

•         Loading of APIP Item(s) into an APIP run-time system/application/tool - real-time reading of a set of APIP Items (APIP defines only the interchange data model and not the exchange communications method);

•         Obtaining APIP personal needs and preferences - reading a set of personal needs and preferences, from a Preferences System, so that a system/tool/application can be configured to render APIP Items in a manner suited to the personal needs and preferences of the user.

A broader set of use cases have been defined for APIP [APIP, 14a] so that later versions of APIP can be extended without causing incompatibilities with version 1 implementations.

1.4.         The APIP Technical Documentation Set

The technical specification work has involved the development of extensions to the base IMS specifications and profiling of several IMS and non-IMS specifications.  Profiling is the process by which, one or more specifications, are tailored and combined to provide a best practice solution.  In the case of APIP, profiling has been completed for the IMS QTIv2.1 [QTI, 12], IMS AfA PNPv2.0 [PNP, 09], IMS Content Packaging v1.2 [CP, 07], IMS AfA Digital Resource Description (DRD) [DRD, 09] and IMS Metadata v1.3.  Profiling of the IEEE Learning Object Metadata (LOM) [LOM, 02] has also been undertaken.

The technical documentation set for APIP consists of six other documents and the set of XML Schema Description (XSD) files and examples.  Namely:

a)      Accessible Portable Item Protocol (APIP) Use Cases [APIP, 14a] - containing the set of use cases to be addressed in APIP v1.0 and later versions (this ensures that the v1.0 solution is set within a broader interoperability framework);

b)      Accessible Portable Item Protocol (APIP) Technical Specification [APIP, 14b] - containing the detailed profiling of the various interoperability specifications and a description of how systems are expected to process the information contained within the APIP Item, APIP Test and AfA PNP data files. This document is relevant to organizations wishing to adopt the APIP;

c)      Accessible Portable Item Protocol (APIP) Technical Specification of Features for QTIv2.2 [APIP, 14c] - containing the detailed description of the information model and XSD binding for the extensions to the IMS QTIv2.2 specification required by APIP.  This document is relevant, in particular, to organizations wishing to implement the APIP and who require the detailed technical descriptions of the new features;

d)     Accessible Portable Item Protocol (APIP) Technical Specification of Features for AfA PNP v2.0 [APIP, 14d] - containing the detailed description of the information model and XSD binding for the extensions to the IMS AfA PNP v2.0 specification required by APIP.  This document is relevant, in particular, to organizations wishing to implement the APIP and who require the detailed technical descriptions of the new features;

e)      Accessible Portable Item Protocol (APIP) Best Practice & Implementation Guide [APIP, 14e] - containing a number of annotated examples of the data files exchanged by APIP compliant systems for the import/export of APIP Items and access to the APIP preferences.  These examples demonstrate how the core use-cases are supported by the technical solution. This document is relevant to anyone wishing to understand how the APIP can be used;

f)       Accessible Portable Item Protocol (APIP) Conformance & Certification [APIP, 14f] - containing the conformance specification for APIP v1.0.  This also describes how an APIP instance and an APIP application/tool/system must comply to achieve the various APIP conformance certification marks;

g)      Accessible Portable Item Protocol (APIP) Terms and Definitions [APIP, 14g] - containing the terms and definitions, and other useful information that is required to provide a full context for the APIP;

h)      XSD files - these are the control validation files used by applications to confirm that the data instance files being exchanged by APIP compliant systems are syntactically correct;

i)        Annotated examples - the set of example instance files that are described in the best practices examples document [APIP, 14h].

1.5.         Feedback

IMS strongly encourages its members and the community to provide feedback to continue the evolution and improvement of the APIP standard. To join the IMS developer and conformance certification community focused on APIP and QTI please visit the IMS QTI/APIP Alliance online here: http://www.imsglobal.org/apip/index.html
Public contributions, comments and questions can be posted here: http://www.imsglobal.org/community/forum/categories.cfm?catid=110

 

2.               The Technical Approach

The technical approach has combined a traditional use-case driven requirements consideration with a priori knowledge that the solution will be based upon a number of IMS specifications.  Furthermore, the approach is a reflection of the extensive IMS experience in creating learning technology interoperability solutions based upon the profiling of the IMS specifications.

2.1.         Architectural Model

The architectural framework for the use of the APIP v1.0 is shown in Figure 2.1. The APIP is used to support four types of data interchange:

•         Repository to repository exchange - interactions between digital repositories that are configured to make APIP compliant data available;

•         Repository to content tool exchange - interactions between digital repositories and the tools that make the APIP data available to users such as content authors, learners, etc;

•         Repository to assessment system - real-time provision of APIP Items from a digital repository to assessment systems;

•         Preferences server to content tool exchange - interactions between content tools, such as an assessment system, and a preferences server that makes personal profile information available to other systems.

The APIP v1.0 architectural model.

Figure 2.1 The APIP v1.0 architectural model.

2.2.         Content Accessibility Model

The APIP content accessibility framework, as shown in Figure 2.2, is comprised of two information models to allow items to be ported across item banks and which allow test delivery engines to tailor the presentation of items to meet the access needs of each individual test taker (also referred to in this documentation as the test-taker).

The APIP content accessibility model.

Figure 2.2 The APIP content accessibility model.

The first information model focuses on Examinee Access Information.  During test delivery, the Examinee Access Information model performs two functions.  First, it provides information that allows a test delivery engine to activate specific tools that tailor the presentation of item content to the examinee.  These embedded access definitions may include features such as magnification, alternate contrast, auditory calming, breaks and answer masking.  Second, it provides information that specifies which accessibility information embedded within the item model is pertinent to the examinee.  A variety of types of access information can be placed within an item, including specifications for how an item is to be presented in auditory, Braille, signed, or tactile representations.  In addition, the item information model allows an item developer to point to alternate versions of the item that are presented in an alternate language (e.g. Spanish) or in simplified English.

As depicted in Figure 2.2, the APIP item model has five components:

•         Item Information - this is the metadata that accompanies the Item.  This could include information about versioning, subject domain, relevant curriculum standard learning objectives addressed, etc.

•         Content Information - information about the contents of the item that are to be presented to an examinee assuming no access needs have been defined for that user; 

•         Companion Material - content props that provide key information to be used when answering an Item, e.g., a calculator, protractor, lookup chart, map, reading passage, etc.

•         Accessibility Information - the alternative content to be used to render the content in its described accessibility forms, e.g., read aloud, Braille, sign language, etc.

•         Inclusion Order - the rendering order of the content to be presented to the user undertaking the assessment.  The actual order is determined by the user's accessibility preferences and the range of alternative rendering options created for the Item.

2.3.         Content Assessment Model

The APIP Items and Tests are encoded in the IMS QTI format: this uses the Extensible Mark-up Language (XML) and is commonly termed QTI-XML.  In fact, the encoding also makes use of the IMS Content Packaging format.  A schematic representation of the APIP content assessment model is shown in Figure 2.3. An APIP Item consists of a set of related QTI 'assessmentItems' that reflect the alternative versions of the default instance.  Each of these 'assessmentItems' is contained within its own QTI XML instance file.  The QTI XML instances also contain the Companion Materials, Inclusion Order and Accessibility Information, i.e., these are inserted at extension points inside the original IMS QTI XML structure.  An APIP Item also consists of the set of asset files (an asset is a file that contains a digital resource to be used in rendering the APIP Item, e.g., an image file, an audio recording, web pages, etc.) and the metadata that is used to describe the APIP Item and to help in searching for, and identifying, APIP Items that conform to specific properties.  A similar approach is taken for constructing the APIP Tests, i.e., QTI-XML profiles are used to create APIP equivalent forms of 'assessmentSections' and 'assessmentTests'.  Each test and section is supplied in its own XML instance file.  An 'assessmentTest' contains the set of identifiers for the associated 'assessmentSections' and each 'assessmentSection' points to the associated 'assessmentItems'. 

The APIP content assessment model.

Figure 2.3 The APIP content assessment model.

An IMS Content Package (CP) is used to collate all of this information and to structure it in a convenient exchange format (once the content package has been constructed it is exchanged as a zip file).  Within a content package the manifest file (always termed the 'imsmanifest.xml') is used to identify the set of files and their relationships, e.g., order of presentation, etc.  Each APIP item, section and test consists of a set of resources within a content package (so an 'assessmentItem' XML file is one such resource as is each asset).  Furthermore, the metadata is linked to a resource (this means that a repository which does not have access to, or cannot interpret, the actual XML and assets can still obtain a catalogue of the contents and properties of the contained APIP Items, Sections and Tests).

It is recommended that all of the 'assessmentItem', 'assessmentSection' and 'assessmentTest' files be placed into a single directory for items, sections and tests respectively, within the content package and within that directory each APIP Item, Section and Test is assigned its own sub-directory to contain the XML instances and the associated assets[1].  All of the common assets should be placed in a separate resources directory and finally any control files (such as the validation XSDs) be placed in a third separate directory.  The final recommendation is the inclusion of a mime-type file that a system can access to identify APIP Item compliant zip files.

2.4.         Accessibility Preferences

The accessibility preferences are contained within their own AfA PNP XML instance file, or within an APIP PNP bulk transfer file.  This is a file that conforms to the format defined by the AfA PNP v2.0 specification plus the extensions that have been added by APIP.  The manner in which this data file is obtained by an APIP compliant system is outside the scope of APIP, i.e., this is implementation dependent.

2.5.         Specification Adoption and New Development

The technical specification work that has been undertaken to realize the APIP is:

•         Profiling of the IMS QTI v2.2 specification to meet the specific needs of the APIP (further input is required from the community to ensure that this is fit for purpose).  Separate QTI Metadata, QTI Item QTI Section and QTI Test profiles have been developed;

•         Profiling of the IMS CP v1.2 specification to meet the specific needs of the APIP;

•         Profiling of the IMS AfA PNP v2.0 specification to meet the specific needs of the APIP;

•         Profiling of the IMS AfA DRD v2.0 specification to meet the specific needs of the APIP metadata and integration with the APIP profile of the IMS Content Packaging specification;

•         Profiling of the IEEE LOM to meet the specific needs of the APIP and integration with the APIP profile of the IMS Content Packaging specification (further input is required from the community to ensure that this is fit for purpose);

•         Creation of the APIP extension features for the IMS QTI v2.1 specification and reconciliation with the APIP profile of QTI (feedback from the community will identify amendments);

•         Creation of the APIP extension features to the IMS AfA PNP v2.0 and reconciliation with the APIP profile of QTI (feedback from the community will identify amendments).

3.               Adopting APIP

3.1.         The Technical Implications

APIP is concerned with interoperability of information.  It does not define how data is to be stored and processed within an end system, e.g., assessment authoring tool, etc. So, from the perspective of APIP Item(s) and Test(s) it is about exchanging them in the form of an APIP Interchange File, i.e., a zip file.  Systems, tools and applications are not prevented from importing and/or exporting the same information in other formats.  Furthermore, it is not a requirement, or even an expectation, that the APIP format is assumed as the internal formats used by a system.  A conformance program for APIP is also available.  This addresses compliance in terms of: the APIP interchange files and the systems that exchange these files; the APIP personal needs and preferences files and the systems that use them.  Organizations wishing to achieve conformance for their APIP products should contact IMS. Details about conformance are explained in the Conformance and Certification document [APIP, 14f] and support for implementers is available on the IMS website: http://www.imsglobal.org/developers/apipalliance/index.cfm

3.2.         The Benefits

The benefits of the approach undertaken for the development of the APIP are:

a)      the adoption, wherever possible, of established learning technology interoperability standards and specifications, and only extending these when required, reduces the risk of encountering unknown implementation difficulties;

b)      the assurance that the solution can be readily expanded, at a later date, to support the exchange of tests and related assessment information, e.g., curriculum coverage metadata.  This avoids wasting implementation effort and maximizes return on investment;

c)      the assurance the solution can be combined with other IMS and non-IMS specifications (including SIF) to support new functionality, e.g., the reporting of assessment scores and outcomes.  Again this minimizes implementation effort and risk;

d)     the assurance that further profiling can be undertaken to tailor the approach to meet the needs of specific State assessment activities without compromising the baseline interoperability requirement and capability;

e)      that it enables vendors to adopt the solution without constraining their ability to create market-differentiated products and services.  One objective of APIP is to ensure that vendors can still differentiate their commercial offerings without depending on proprietary content formats;

f)       that it provides an 'open' approach that is developed in conjunction with the end user and vendor communities.  This joint ownership is essential in achieving a useful and used solution;

g)      that it takes advantage of the extensive experience that IMS has of developing and support, for the adoption, of learning interoperability specifications.  This includes a number of special specification development tools and access to a conformance test capability for all content package based solutions (as is the case for APIP).

Appendix A Related Documents

[APIP, 14a]     Accessible Portable Item Protocol (APIP) Use Cases, v1.0 Final Specification, G.Driscoll, T.Hoffmann, W.Ostler, M.Russell, M.McKell and C.Smythe, IMS Global Learning Consortium, Inc., March 2014.

[APIP, 14b]     Accessible Portable Item Protocol (APIP) Technical Specification, v1.0 Final Specification, G.Driscoll, T.Hoffmann, W.Ostler, M.Russell, M.McKell and C.Smythe, IMS Global Learning Consortium, Inc., March 2014.

[APIP, 14c]     Accessible Portable Item Protocol (APIP) Technical Specification of QTIv2.1 Features, v1.0 Final Specification, G.Driscoll, T.Hoffmann, W.Ostler, M.Russell, M.McKell and C.Smythe, IMS Global Learning Consortium, Inc., March 2014.

[APIP, 14d]    Accessible Portable Item Protocol (APIP) Technical Specification of AfA PNP v2.0 Features, v1.0 Final Specification, G.Driscoll, T.Hoffmann, W.Ostler, M.Russell, M.McKell and C.Smythe, IMS Global Learning Consortium, Inc., March 2014.

[APIP, 14e]     Accessible Portable Item Protocol (APIP) Best Practices and Implementation Guide, v1.0 Final Specification, G.Driscoll, T.Hoffmann, W.Ostler, M.Russell, M.McKell and C.Smythe, IMS Global Learning Consortium, Inc., March 2014.

[APIP, 14f]     Accessible Portable Item Protocol (APIP) Conformance and Compliance, v1.0 Final Specification, G.Driscoll, T.Hoffmann, W.Ostler, M.Russell, M.McKell and C.Smythe, IMS Global Learning Consortium, Inc., March 2014.

[APIP, 14g]     Accessible Portable Item Protocol (APIP) Terms and Definitions, v1.0 Final Specification, G.Driscoll, T.Hoffmann, W.Ostler, M.Russell, M.McKell and C.Smythe, IMS Global Learning Consortium, Inc., March 2014.

[CP, 07]           IMS Content Packaging Information Model v1.2, W.Kraan, J.Posten-Day, N.Ward, N.Boyd and C.Smythe, CM/DN Revision 2, IMS Global, Inc., March 2007.

[DRD, 09]       IMS Access For All Digital Resource Description Information Model v2.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Final Release, IMS Global, Inc., October 2009.

[LOM, 02]       IEEE 1484.12.1-2002 Standard for Learning Object Metadata, The Institute of Electrical and Electronics Engineers Inc., 2002. ISBN:0-7381-3297-7.

[PNP, 10]        IMS Access For All Personal Needs & Preferences Information Model v2.0, R.Schwerdtfeger, M.Rothberg and C.Smythe, Final Release, IMS Global, Inc., April 2010.

[QTI, 12]         IMS Question & Test Interoperability Assessment Test, Section and Item Information Model,v2.1 Final Specification. S.Lay and P.Gorissen, IMS Global, Inc., August 2012.

About this Document

Title:                                 IMS Accessible Portable Item Protocol (APIP) Technical Specification Overview

Editors:                             Colin Smythe (IMS Global) and Mark McKell (IMS Global)

Co-chairs:                         Gary Driscoll (ETS), Thomas Hoffmann (Measured Progress) and Wayne Ostler (Pearson)

Version:                            1.0

Version Date:                    31 March 2014

Status:                               Final Specification

Summary:                         The aim of the APIP Project is to use well established e-learning interoperability standards to enable the exchange of accessible assessment content between computer-based assessment systems, tools and applications.  Users of systems, tools and applications that adopt the APIP are able to use their accessible assessment content on a wide range of systems.

Purpose:                            This document is made available for adoption by the public community at large.

Document Location:         http://www.imsglobal.org/apip/

 

List of Contributors

The following individuals contributed to the development of this document:

Rob Abel, IMS Global (USA)

Justin Marks, NWEA (USA)

Michael Aumock, Pacific Metrics (USA)

Mark McKell, IMS Global (USA)

Marty Christensen, ACT (USA)

Sue Milne, JISC (UK)

Jason Craft, Pearson (USA)

Wayne Ostler, Pearson (USA)

Gary Driscoll, ETS (USA)

Zack Pierce, Measured Progress (USA)

Eric Hansen, ETS (USA)

Michelle Richard, Pearson (USA)

Regina Hoag, ETS (USA)

Mike Russell, Measured Progress (USA)

Thomas Hoffmann, Measured Progress (USA)

Farhat Siddiqui, ETS (USA)

Wilbert Kraan, JISC (UK)

Colin Smythe, IMS Global (UK)

Devin Loftis, McGraw-Hill/CTB (USA)

Wyatt VanderStucken, ETS (USA)

Revision History

 

Version No.

Release Date

Comments

Candidate Final v1.0

26 March 2012

The first formal release of the Candidate Final Release version of this document.

Final Specification v1.0

31 March 2014

The Final v1.0 specification.

 

 

 

 

 

IMS Global Learning Consortium, Inc. ("IMS Global") is publishing the information contained in this document ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

IMS Global makes no warranty or representation regarding the accuracy or completeness of the Specification.

This material is provided on an "As Is" and "As Available" basis.

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

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

IMS Global would appreciate receiving your comments and suggestions.

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

Please refer to Document Name: IMS APIP Technical Specification Overview v1.0
Final Specification v1.0

Date: 31 March 2014

 



[1] This is an initial recommmended best practice.  These recommendations may be changed once there is sufficient adoption feedback to determine whether or not this approach of separation is useful.