1EdTech Final Release

1EdTech Common Cartridge Profile: Implementation

 

Version 1.3 Final Specification

Date Issued:            30 May 2014

Latest version:         /cc/index.html

 

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.

1EdTech 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 1EdTech’s procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: /sites/default/files/imsipr_policyFinal.pdf.

Copyright © 2008 - 2014 1EdTech Consortium. All Rights Reserved.

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: /license.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 1EdTech 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.

For comments and feedback, join the discussion at: /community/forum/categories.cfm?catid=58

 

 

© 2014 1EdTech Consortium, Inc.
All Rights Reserved.

The 1EdTech Logo, Learning Tools Interoperability (LTI), Question and Test Interoperability (QTI), and Accessible Portable Item Protocol (APIP) are trademarks of the 1EdTech Consortium, Inc. in the United States and/or other countries.
Document Name:  1EdTech Common Cartridge Profile: Implementation v1.3 Final Release – Date: 30 May 2014


 

1                  Introduction

The Common Cartridge defines an open format for the distribution of rich, web-based content. It is designed to ensure the correct installation and operation of content across any Common Cartridge conformant platforms and tools. The specification defines a profile for the use of the following specifications which are (in the versions adopted here), already widely implemented and in use across the community:

•        IEEE LOM encompassing:

•        ISO 15836:2003: Dublin Core Metadata Element Set (mapped to the corresponding elements in LOM) [DC, 03]

•        IEEE 1484.12.1-2002: Learning Object Metadata [IEEE LOM, 02]

•        IEEE 1484.12.3-2005: LOM Schema binding (loose binding) [IEEE LOM, 05]

•        1EdTech Content Packaging v1.2 [CP, 07]

•        1EdTech Question & Test Interoperability™ v1.2.1 [QTI, 03]

•        1EdTech Authorization Web Service v1.0 [CC, 08b]

•        1EdTech Basic Learning Tools Interoperability™ v1.0 [BLTI, 10]

The LOM, Content Packaging and Question & Test Interoperability specifications have each been profiled to simplify their use. Thus their scope has been constrained to those features commonly implemented and in use by the community. Experience suggests that interoperability problems that have arisen with implementations of these specifications are frequently the result of differing interpretations of the specs and options being taken that lead to divergence in behavior. A key goal of the Common Cartridge specification therefore has been to provide a tighter definition of their use thus eliminating this divergence. The resulting profile also lends itself to more effective conformance testing of implementations.

The profile has been developed in accordance with the 1EdTech Application Profile Guidelines v1.0 [AP, 05].

The driving motivation behind this work has been to communicate clearly and unambiguously how the above collection of specifications can be harnessed to distribute rich web content in a format that offers a high degree of interoperability across platforms. The approach followed has centered on:

·         eliminating implementation options from the adopted base schemas;

·         removing unwanted extensibility;

·         focusing on commonly used features and eliminating those rarely used;

·         further constraining permitted data in supported element (e.g., in terms of type, value ranges, vocabularies).

The resulting Common Cartridge profile should be easier for developers to implement and lends itself to more routine conformance testing of these implementations.

Note that this document is only one of several that form the specification for Common Cartridge v1.3.  Refer to Section 1.2 for titles of other documents, which address overview material and what is different from v1.1, use cases, and conformance.

Figure 1.1 Common Cartridge Focus.

•        The primary focus of the Common Cartridge specification is achieving error-free import of content into any conforming LMS platform (see Figure 1.1). No runtime model is expressed, but any conforming LMS must support (either directly, or via a call-out to a suitable external service) all of the functionality implied by the Common Cartridge schema set. 

1.1      A Note on Conformance and Allowing Exceptions

1EdTech Common Cartridge conformance enables interoperability of the packaging and delivery of content. As the use of Common Cartridge grows in use as a way to facilitate the exchange of educational content, the need to both broaden and narrow the scope of the specification's functionality has arisen. This is why the Common Cartridge Accredited Profile Management Group (CC AMPG) revises the specification to include new features, such as Learning Tools Interoperability in CC v1.1, Curriculum standards in CC v1.2, and inline descriptor-file XML in CC v1.3.

While the specification's original developers decided on what they believed to be a minimum set of criteria that would enable interoperability between systems and content, in actual use the set of criteria needed may be in fact, less than what was described.  As more vendors and individuals are seeing the benefit of using Common Cartridge to package and exchange data, new tools are being developed which wish to make use of the Common Cartridge structure, but these tools may not have all the Common Cartridge functionality inherent in their tools. 

In 1EdTech, our goal is to enable interoperability and allow the broadest use of our standards while still maintaining the integrity of the specification and the use of 1EdTech standards at the core of tools. 

The CC AMPG is responsible for defining the criteria needed to achieve Common Cartridge conformance.  Based on requests from vendors, the CC AMPG has revised the requirements for achieving CC v1.3 Conformance.

The table below shows the base features of Common Cartridge v1.3.

 

 

Table 1.1 Common Cartridge v1.3 Learning Platforms Allowable Exceptions List

Features

Details

Allowed as an exception Common Cartridge v1.3

1EdTech Manifest File

 

No

Export in Common Cartridge Format

 

Yes

Roles Meta-data

Instructor

No

 

Student

No

 

Mentor

Yes

.imscc file name

 

No

Inline Descriptor File XML

 

No

RESOURCE TYPES

 

 

LTI Links

 

Yes

Web Content

 

No

 

intended use attribute

Yes

Web Links

 

No

Associated Content

 

No

Question Types

 

 

 

1) Multiple-Choice (single Response)

No

 

2) Multiple - Choice (multiple Response)

Yes

 

3) True/False

No

 

4) Essay

Yes

 

5) Simple fill in the blank

No

 

6) Pattern Match

Yes

APIP File

 

Yes

IWB File

 

Yes

EPub3 File

 

Yes

Discussion Forum

 

Yes

Authorization

 

Yes

METADATA

 

 

Curriculum Standards

 

Yes

All LOM Fields

 

No

           

The new approach allows tools that do not inherently support functionality (such as discussion forums) the opportunity to gain Common Cartridge conformance.  All systems that do not support a feature of Common Cartridge must fail gracefully and indicate to the user that they do not support the feature. All systems must import cartridges to gain conformance, they may not fail at import regardless of the features contained in the cartridge.

1.2      Technology

Simplifications applied to the Common Cartridge format include:

•        Metadata is only mandated at the cartridge level by the CC profile (located in the root folder). Optionally, roles metadata can be applied within the manifest to define which categories of users have access to particular resources.

•        Inter-package links are not supported

•        Common Cartridge metadata prior to version 1.2 only uses the 15 elements from DCMI v1.1 (Simple DC).  The full LOM set is allowed in version 1.3.

•        Assessments have been simplified to just the six (6) most commonly used QTI question types:

•        Multiple choice (single response)

•        Multiple choice (multiple response) (allowed exception)

•        True/false

•        Essay (allowed exception)

•        Simple fill in the blank

•        Pattern match (allowed exception)

However, the format has also been enriched with the addition of:

•        Addition of discussion forum initialization

•        Addition of LTI

1EdTech is developing LTI to allow remote tools and content to be integrated into a Learning Management System (LMS).  Throughout this document, we use specific terminology to describe the two main pieces of software involved in LTI.   What we traditionally think of as the "Learning Management System" (LMS) is referred to as the "Tool Consumer" (TC) as it "consumes" the tool.  The external tool or content is called the "Tool Provider" (TP) as it "provides" the tool for use in the Tool Consumer.   Example Tool Providers might include an externally hosted testing system or a server that contains externally hosted premium content. 

LTI exposes a single destination in the Tool Provider system. The procedure for establishing a link to this single destination is simple, but limited. There is no provision for accessing Full LTI run-time services in the Tool Consumer and only one security policy is supported. LTI uses the OAuth protocol (http://www.oauth.net) to secure its message interactions between the TC and TP.  OAuth requires a key and shared secret to sign messages.  The key is transmitted with each message, as well as an OAuth-generated signature based on the key.  The TP looks up the secret based on the provided key and re-computes the signature and compares the recomputed signature with the transmitted signature to verify the sender's credentials.

Refer to Version 1.0 Final of the 1EdTech Learning Tools Interoperability Basic LTI Implementation Guide [BLTI, 10] for more specifics.

1.3      References

[AP, 05]                                 1EdTech Application Profile Guidelines, v1.0, 1EdTech, October, 2005.

[BLTI, 10]                             1EdTech Basic Learning Tools Interoperability (BLTI) v1.0, 1EdTech, May, 2010.

[CC, 08b]                              1EdTech Common Cartridge (CC) Authorization Web Service v1.0, 1EdTech, October, 2008.

[CC,11a]                               1EdTech Common Cartridge Profile: Overview v1.3, 1EdTech, July 2013.

[CC,11b]                               1EdTech Common Cartridge Profile: Use Cases v1.3, 1EdTech, July 2013.

[CC,11c]                                1EdTech Common Cartridge Profile: Conformance v1.3, 1EdTech, July 2013.

[CC,11d]                               1EdTech Common Cartridge Profile: Appendices v1.3, 1EdTech, July 2013.

[CP, 07]                                 1EdTech Content Packaging (CP) v1.2, 1EdTech, 2007.

[DC, 03]                                 Dublin Core Metadata Element Set, Version 1.1 (ISO 15836:2003).

[IEEE LOM, 02]                  IEEE Learning Object Metadata (1484.12.1-2002).

[IEEE LOM, 05]                  IEEE LOM Schema Binding (1484.12.3-2005).

[QTI, 03]                               1EdTech Question & Test Interoperability (QTI) v1.2.1, 1EdTech, March, 2003.

[VDEX, 04]                           1EdTech Vocabulary Definition Exchange (VDEX) v1.0, 1EdTech, February 2004.

 

 

1.4      Definitions

 

Term

Definition

Access Code

A code used to authorize user access to a protected resource, in this case a Common Cartridge or a discrete component thereof.

APIP

The Accessible Portable Item Protocol (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 an Item accessible for students with a variety of disabilities and special needs.

Associated Content

A resource type that includes a collection of files used by a specific Learning Application Object. Each file referenced must exist in the directory containing the descriptor file of the Learning Application Object with which it is associated or any subdirectory thereof.

A resource of the type “associatedcontent” must comply with the following restrictions:

1.  It must contain a file element for each file that exists in the directory that contains the associated Learning Application Object’s descriptor file or any of its subdirectories.

2.  It must not contain any references to files above the directory containing the associated Learning Application Object’s descriptor file.

3.  It must not contain any dependency elements.

Common Cartridge

A content packaging profile agreed between content providers and LMS providers, offering a common format for the distribution of both open and access protected content. The profile harnesses Content Packaging, LOM Metadata, and QTI, augmented with a specification for simple access control.

Content Elements

Discrete content elements within a Learning Activity aggregate as part of a Learning Application Object or module (lesson).

Course Content Package

A term for any current proprietary LMS specific, publisher developed and sourced, content package that is made commercially available via the publisher or LMS vendor to its customer base. Examples of such cartridges are the WebCT ePack, Blackboard Course Cartridge etc.

Deployment Context

Any one of the LMS deployment and learning contexts made available for online access to learning activity via learning modules, Learning Application Objects and content element interaction.

Descriptor File

The file that serves as the entry point for accessing the information about a Learning Application Object required to import the Learning Application Object into the target system. Generally an XML file meeting an appropriate file specification based on the type of Learning Application Object. However, in some cases, the file may be a zip archive or some other structured file format. The descriptor file is not intended to be displayed within the target system. Rather, it is intended to be processed by the target system upon import of the cartridge. The descriptor file is associated with a Learning Application Object by means of a “file” element.

Directory

A physical folder in a content package archive.

EPub3

A document format specification (http://idpf.org/epub/30).

IWB

The Interactive WhiteBoard/Common File Format (IWB/CFF) specification defines a file format to hold content primarily designed to be viewed on a large display. Much of this content will be designed to be interactive, so objects can move around the page.

The primary goal of this format is to establish a format that can be opened, edited, saved and used across many whiteboard applications so that teaching content can be exchanged between establishments. To this goal the format must be simple but extendible in a restricted way to ensure compatibility.

Resource Extension

As of CC v1.3, a resource type defined outside this specification and registered with 1EdTech.

Learning Activity

A general term for describing an online learning experience and interaction with learning modules, Learning Application Objects and content elements typically composed to deliver a particular outcome or experience for the Student.

Learning Application Object

Any one of a number of resource types that require additional processing and interpretation before they can be imported and subsequently represented within the target system. Physically, a Learning Application Object consists of a directory in the content package containing a descriptor file and optionally additional files and subdirectories used exclusively by that Learning Application Object.

Each Learning Application Object must have a corresponding resource element in the manifest. Examples of Learning Application Objects include QTI assessments, Discussion Forums, etc. The type attribute of the resource element is prescribed by the type of Learning Application Object being represented. If additional files beyond the Learning Application Object’s descriptor file exist in the Learning Application Object’s directory or any of its subdirectories, these files must be represented in a resource element of type “associatedcontent” which is list as a dependency within the Learning Application Object’s resource element.

A resource that represents a Learning Application Object has the following general restrictions:

1.  It must contain a file element that points to the Learning Application Object’s descriptor file.

2.  It must not contain any other file elements.

3.  If additional files exist in the directory containing the Learning Application Object’s descriptor file, or any of its subdirectories, the resource must contain a dependency element that references the resource of type “associatedcontent” which contains the references to these files.

4.  It must not contain any other dependency elements of type “associatedcontent”.

5.  It may contain any number of dependency elements that reference resources of type “webcontent”.

Learning Management System

A Learning Management System (LMS) is a computer application that enables the assignment of content to learners, learning, and the reporting of learning outcomes. This is used interchangeably with Course Management System, Managed Learning Environment and a host of other terms.

Learning Module

An aggregate of content and/or application functionality that represents or is part of a learning activity.

Learning Tools Interoperability

A specification (a.k.a Basic LTI or simply LTI) which defines the roles of Tool Consumer (typically an LMS) and Tool Provider (typically a remote application or tool) and the format and description of parameters passed in calls between Consumer and Provider.

Target System

A Learning Management System (LMS) or similar system into which a package is to be imported.

Webcontent

The standard resource type for content packages. Static web resource that is generally supported on the web such as HTML files, GIF images, JPEG images, PDF documents, etc. Resource of type “webcontent” may have their intended use signaled through use of the optional attribute, “intendeduse”.  Resources of the type “webcontent” may reference any number of files. Additionally, “webcontent” resources may include dependencies on other “webcontent” resources.

A resource of the type “webcontent” must comply with the following restrictions:

1.  It may contain a file element for any file that exists in the package so long as the file is not in a Learning Application Object directory or a subdirectory of any Learning Application Object directory.

2.  It may contain dependency elements that reference any other resources of type “webcontent”.

It must not contain any dependency elements to resources whose type is not “webcontent”.

2                  Architecture and Approach

2.1      1EdTech Common Cartridge Run-Time Functional Model

Common Cartridge focuses primarily on how information should be physically arranged in a package and how learning platforms should construct specific native objects such as external links, discussion topics, BLTI links, assessments, and question banks.  Common Cartridge also specifies how conforming learning platforms must behave when processing packages. 

 

Figure 2.1 Common Cartridge Run-time Model.

3                  Content

3.1      Common Cartridge Package Interchange File Structure

The diagram in Figure 3.1 shows the overall layout of the cartridge package interchange file.  Note that LTI is part of Common Cartridge v1.3 and the package should have the extension “imscc”.

Starting with CC v1.3, additional resources for APIP (Accessible Portable Item Protocol™), EPub3, and IWB (interactive whiteboard) as well as extensions are supported.

Figure 3.1 Common Cartridge package interchange file.

3.2      Content Types

 

 

Figure 3.2 Common Cartridge Content Types.

 

Table 3.1 Common Cartridge Content Types.

Entity

Description

Item – Folder

A folder represents a unit of organization. A folder is simple collection of items and subfolders that are placed in a specific order (1st, 2nd, 3rd, etc.). Folders can contain other Folders (n-level nesting). A folder represents a content presentation paradigm and can be used to define how the content should be organized and presented to the learner.

Resource – Web Content

Web Content files include any files that are widely supported for delivery over the web. These could include HTML files, images, audio, video, MS Office, PDF, Flash etc.  Web Content can be marked with an intended use such as a lesson plan,  syllabus, or assignment.  A learning platform can elect to handle this content with such an intended use in mind.

 

HTML files may include references to other web content files that are contained within the cartridge or that are external to the cartridge.

Resource – Web Link

A Web Link is a Learning Application Object representation of a standard HTTP link. It extends a standard HTTP link by giving the link a title (which is independent of its usage in any particular folder location). It also includes attributes that describe which window the resource should be opened in and other window open features, such as the dimensions of the window.

Resource – Discussion Topic

A Discussion topic is a Learning Application Object that is used to initiate Discussion activity. This represents a placeholder for a discussion topic and does not represent a link to an existing discussion topic in an external system. The importing LMS is expected to generate a new discussion topic using only its internal tools. It contains the following attributes: title, description, file attachments.

Resource – Assessment

An assessment represents an instance of a QTI assessment. It can embed any of the question types supported by the CC v1.2 profile of QTI.

An assessment can contain a number of attributes including number of attempts, time limit and whether late submission is allowed.

Resource – Associated Content

A collection of files used exclusively by an individual Learning Application Object

Resource –Learning Tools Interoperability

An LTI resource represents a simplified and self-contained LTI link. This resource refers to an XML file that contains the information needed to create in a Tool Consumer (an LMS or learning platform) a link or similar.  When activated by the user, passes the user to a Tool Provider along with contextual information about the user and Consumer.

Intra-Package Reference

Intra-Package References allow Learning Application Objects or files in the package to reference other files within the package.

1EdTech CC Package Metadata

This is 1EdTech CC Package level specific metadata that may include different elements covering licensing, accessibility, description, etc.

Resource – Question Bank   

A question bank represents an instance of a QTI objectbank.  Multiple question bank can optionally be included in a cartridge. It can embed any of the question types supported by the CC v1.2 profile of QTI. Questions within a question bank cannot be referenced by any assessments contained in the cartridge.

Resource - IWB

An interactive whiteboard (IWB) file contains content that is primarily designed to be viewed on a large display.

Resource – APIP

An Accessible Portable Item Protocol file contains assessment items, tests and results data with accessibility options.

Resource – Epub

An EPUB file contains epub packaged file, such as an ebook.

Resource - Extension

An extension resource is a resource that provides additional functionality but is outside this specification , but registered with 1EdTech


Common Cartridge v1.3 supports profiled instances of the following question types:

•        Multiple Choice – single response

•        Multiple Response – like multiple choice but with multiple correct answers

•        True/False

•        Simple Fill in the Blanks – provides single answer box with single correct answer

•        Fill in the Blanks Pattern Match – provides single answer box but supports ‘contains’. 

•        Essay

Note that support for multiple response, essay, and pattern match are optional; they are permitted exceptions for those learning platforms that do not provide these types of questions natively.

Questions can only be included in a cartridge either as components of an assessment resource or a question bank resource.  Only one question bank can be included in a cartridge.

In general, a question consists of the following elements:

•        Question Label/Title

•        Question Text (may include HTML, Intra-Packages References, URLs, formatting)

•        Question Answer Choices (may include HTML, Intra-Packages References, URLs, formatting, images, video, audio)

•        Question Answer Choice Points

•        Feedback (may include HTML, Intra-Packages References, URLs, formatting, images, video, audio)

•        Question Answer Presentation Settings

•        Question Settings (e.g., time, etc.)

•        Question Metadata.

•        Question Rubrics.

•        Question Solutions.

3.3      Categories of Resource in a Common Cartridge

In addition to the imsmanifest.xml file, there are a further three basic categories of resource file in a Common Cartridge.

Table 3.2 Common Cartridge Resource Categories.

Resource Category

Description

imsmanifest.xml

•        This is the standard 1EdTech manifest file.

Web Content Resources

•        These include the following resource types: web content, web link or intra-package reference (see table 3.1).

•        Web Content Resources must reside within the web content folder at the root of the cartridge. The Web Content Resources can here be organized into directories and subdirectories within the web content folder.

•        Web Content Resources within the web content folder can be referenced by other resources outside of the web content folder directory system.

•        Web Content Resources within the web content folder can be referenced by other resources also within the web content folder directory system.

•        Web Content Resources within the web content folder cannot reference other resources outside of the web content folder directory system.

•        The directory structure within the web content folder will be included in the importing LMS to ensure relative links between and to web content continue to work.

•        Generally, Web Content Resources do not require additional processing on import into the LMS, although how these are stored and rendered is LMS dependent.

•        Web Content Resources can have an intended use attribute.

Learning Application Object Resources

•        A Learning Application Object is a directory structure used to group together all the files (or file references) that are used to deliver a single instance of one of the following resource types: web content, web link, discussion topic, assessment or intra-package reference (see table 3.1).

•        The files held within a Learning Application Object directory structure are described as Associated Content Resources.

•        Associated Content Resources cannot be referenced by other resources outside of the Learning Application Object folder directory system.

•        Associated Content Resources can reference other resources in subordinate folders of the Learning Application Object directory system.

•        The directory structure within the Learning Application Object folder will be included in the importing LMS to ensure relative links between and to web content continue to work.

•        These will generally be parsed on input and transformed into internal data structures in the LMS.

Using Directories in Package Interchange File

•        File system directories can be used to organize content within the package interchange file. It is required that the resources specific to a given Learning Application Object are packaged in a distinct directory in the package interchange file.

 

Associated Content resources include a collection of files used by a specific Learning Application Object. Each file referenced must exist in the directory containing the descriptor file of the Learning Application Object with which it is associated or any subdirectory thereof. Furthermore, each Associated Content resource must be associated with one and only one Learning Application Object. This association is indicated by use of a dependency reference on the Learning Application Object’s resource element.

A resource of the type “associatedcontent” must comply with the following restrictions:

1)        It must contain a file element for each file that exists in the directory that contains the associated learning application object’s descriptor file or any of its subdirectories.

2)        It must not contain any references to files above the directory containing the associated learning application object’s descriptor file.

3)        It must not contain any dependency elements.

Web Content resources include any number of references to static web resources that are generally supported on the web such as HTML files, GIF images, JPEG images, PDF documents, etc. Resources of the type “webcontent” may reference any number of files. Additionally, “webcontent” resources may include dependencies on other “webcontent” resources. However, “webcontent” resources may never contain dependencies on any other resource types including Associated Content resources and Learning Application Object resources.

A resource of the type “webcontent” must comply with the following restrictions:

1)        It may contain a file element for any file that exists in the package so long as the file is not in a learning application object directory or a subdirectory of any learning application object directory.

2)        It may contain dependency elements that reference any other resources of type “webcontent”.

3)        It must not contain any dependency elements to resources whose type is not “webcontent”.

Table 3.3 Restrictions on Resource Categories.

Dependency Resource Type

Learning Application Resource

Associated Content Resource

Web Content Resource

Web Content

0-N

0-N

0-N

Associated Content

0-1 [1]

Prohibited

Prohibited

Learning Application

Prohibited

Prohibited

Prohibited

 

3.3.1           Cartridge Level Web Content

These are web content resources that may be shared between different Learning Application Objects within the cartridge.

References to files in this file system from Learning Application Object files must utilize relative paths e.g.:

“../filename”

3.3.2           Learning Application Object Directories

(<root>/learningApplicationResourceDirectory1… learningApplicationResourceDirectoryN)

These directories organize all the files that logically contribute to the delivery of a single instance of one of the content types supported by Common Cartridge.

The root of the directory should contain the descriptor file for the Learning Application Object such as the QTI file for an assessment Learning Application Object. This directory may also contain additional files and subdirectories that are used exclusively by the Learning Application Object (i.e., associated content).

The name of this directory is not defined by the specification. Care must be taken to ensure that collisions do not occur between this directory name and the names of directories used for other Learning Application Objects and those used for web content.

A cartridge that does not contain any additional Learning Application Objects (e.g., only cartridge level web content) may exclude these directories.

The following structure is valid since the learning application folder is at the root level of the cartridge and the descriptor XML file is at the root level of the folder:

imsmanifest.xml

content

     image

         picture.jpg

     file1.html

     discussion.xml

The following structure is invalid since the descriptor is not at the root of the learning application folder:

imsmanifest.xml

content

    image

        picture.jpg

        discussion.xml

    file1.html

3.3.3           Associated Content

Any web content which is logically tied to this Learning Application Object should be contained in the Learning Application Object resource directory.

All references to this content from Learning Application Object resource files e.g. QTI files should use a relative path.

It is the responsibility of the cartridge producer to ensure name collisions do not occur between end user created file/folder names (for web content) and system generated file/directory names (for resource descriptors).

3.3.4           Example Layout

An example of the layout described above could be:

imsmanifest.xml

course-logo.gif

course-overview.html

content1

        content1/preTestQti.xml

        content1/images/map.gif

        content1//movie.swf

        content1/background.html

content2  

        content2/discussionTopic1.xml

        content2/overview.html

        content2/images/image.gif

content3

        content3/webLink1.xml

content4

        content4/lessonplan.pdf

3.4      Pathnames for Web Content Resources

To facilitate management of web content resources, in particular utilizing standard html relative path referencing between resources when content is imported into a learning platform or Common Cartridge ‘runner’, web content resources are defined to live in two file systems – a folder for web content used by several resources and a folder for each Learning Application Object’s related content.

The diagram in Figure 3.3 shows how web content may be referenced across these different file systems using relative path semantics.

Figure 3.3 Content referencing using relative file paths.

3.4.1           Cartridge Web Content

A Cartridge Web Content folder may be included in a Common Cartridge. If present, the Cartridge Web Content folder must appear in the root folder of the cartridge. The name of this folder is not defined by the specification.

Web content included in the Cartridge Web Content folder can be referenced by any of the Learning Application Objects in the cartridge. Relative path referencing is permitted between files in this folder and its subfolders, but files in this folder are not permitted to reference files in a Learning Application Object folder or its associated content folders.

On import, a tool will usually import this content into a course level file system.

3.4.2           Learning Application Object Web Content

There can be 1 to n Learning Application Object web content folders in a Common Cartridge.

Each Learning Application Object in the cartridge has its own associated content file system folder. Files in this folder and its subfolders may reference other files in this associated content file system folder and files in the Cartridge Web Content folder using relative path semantics. However, they must not reference files in other Learning Application Object web content folders or their sub-folders. In addition, Learning Application Object resources (e.g., a QTI xml file) can contain references to files in the Learning Application Object’s associated content folder and its subfolders and the cartridge web content folder and its subfolders, but must not contain references to web content in the folders of other Learning Application Objects.

On import, a tool that only supports a single course level file system may import this web content into the course level file system. In this scenario, the web content in the cartridge represents one big file system scope.

A tool that supports both course level and Learning Application Object level file systems will import this content into a local file system space that can only be utilized by the associated Learning Application Object.

3.4.3           Format of Relative Path References within a web content file system

All html path linking (e.g. <img src=””>, <a href=””>) between content contained in a given file system (cartridge or Learning Application Object) should utilize relative path semantics restricted by the rules defined above. Here relative path is defined as relative to the file containing the reference regardless of whether that file is itself web content or some other resource e.g. a QTI file.

3.4.3.1       Referencing Web Content from other Web Content

Within a given file system, paths are relative to the location of the file, e.g., for the files:

content1/material/lesson.html

content1/images/icon.gif

An image reference to icon.gif from lesson.html would take the form:

<img src=”../images/icon.gif”/>

3.4.3.2       Referencing Web Content Directly from other Resources Using a Defined Linking Syntax

Where the linking syntax of a learning application object uses a URI, paths should be relative to the file containing the reference, e.g., for the files:

content1/question1Qti.xml

content1/images/icon.gif

A QTI mattext element would take the form:

<mattext texttype="text/html"><![CDATA[ <img src= "$1EdTech-CC-FILEBASE$images/icon.gif" alt="" style="border: 0px solid rgb(0, 0, 0);">]]</mattext>

3.4.3.3       Referencing Web Content from Embedded Text in Another Resource

Where a Learning Application Object resource supports free-form text which may contain embedded HTML markup, paths should be relative to the file containing the reference and should in addition contain a special token to make finding and parsing these paths simpler for the importing system, e.g., for the files:

content1/question1Qti.xml

content1/images/icon.gif

A reference to the image icon embedded in the free format question text should take the form:

<img src=”$1EdTech-CC-FILEBASE$images/icon.gif”/>

Note: the token $1EdTech-CC-FILEBASE$ is just a flag to facilitate finding the paths. It does not represent a replacement token within the context of the cartridge. However, an importing tool  may choose to store the referenced files in a different location and so is free to insert any path elements needed to make the path work in the tool.

The $1EdTech-CC-FILEBASE$ token can be used in resources with a descriptor file.  The token always points to the base directory of the learning resource object i.e. the folder that contains the descriptor. The path following the token should be relative to the base directory of the resource within the cartridge.  Since the dependent files that make up a quiz or forum may be reorganized in the LMS in a way that would break links embedded in the resource content, the LMS at import or later can replace this token with an alternate path. Additionally, since any supplemental images or html will also need to be contained within the cartridge, these items should be listed as dependencies.

3.4.4           Format of Relative Path References from Learning Application Object to Cartridge File System

All html path linking (e.g. <img src=””>, <a href=””>) by content contained in a Learning Application Object file system to content in the cartridge web content file system should use relative paths adhering to similar rules as those defined for references within a file system. Here relative path is defined as relative to the file containing the reference regardless of whether that file is itself web content or some other resource, e.g., a QTI file.

3.4.4.1       Referencing Cartridge Web Content from Learning Application Object Web Content

The key rule is that where a relative path within the Learning Application Object file system is directed above that file system root, this is assumed to be a reference into the cartridge web content file system, e.g., for the files:

images/icon.gif

content1/material/lesson.html

An image reference to icon.gif in the cartridge file system from lesson.html in a Learning Application Object file system would take the form:

<img src=”../../images/icon.gif”/>

3.4.4.2       Referencing Cartridge Web Content Directly from Learning Application Object Resources

Where the information model of another Learning Application Object resource is defined as a URI, paths should be relative to the file containing the reference, e.g., for the files:

content1/question1Qti.xml

 

3.4.5           Referencing Cartridge Web Content from Embedded Text in another Resource

Where a Learning Application Object resource supports free-form text which may contain embedded HTML markup, paths should be relative to the file containing the reference and should in addition contain a special token to make finding and parsing these paths simpler for the importing system, e.g., for the files:

content1/question1Qti.xml

A reference to the cartridge image icon embedded in the free format question text should take the form:

<img src=”$1EdTech-CC-FILEBASE$../images/icon.gif”/>

 

3.4.6           The ‘dependency’ Element

The 'dependency' element must only be used for resources of a particular type and for certain relationships between resource types.  These rules are:

§  A Web Link - must not have a dependency;

§  A Discussion Topic - may have a dependency on Web Content and/or Associated Content;

§  Assessment  - may have a dependency on Web Content and/or Associated Content;

§  Question Bank - may have a dependency on Web Content and/or Associated Content;

§  Web Content - may have a dependency on Web Content;

§  Associated Content- may have a dependency on Web Content;

§  LTI - may have a dependency solely for an image icon.

From this list we can see that Discussion Topic, Web Link, Assessment and Question Bank resources MUST NOT be identified by a dependency.

Furthermore, a 'dependency' MUST NOT refer to its own parent 'resource' element and each dependency for a resource should point to a unique resource, i.e., the dependency child elements should not be duplicated for a parent resource.

4                  Common Cartridge Information Model Profiles

4.1      The Conceptual Model

The intent of this section is to provide a high-level description of a Common Cartridge. While conceptually similar to “cartridge-like” features found in existing commercial vendor solutions, several of the features of the Common Cartridge are included.

Conceptually, a Common Cartridge is a package of content and metadata that is integrated into an LMS learning context. At a high level, this may directly correspond to the notion of “course” in the target LMS. There is no guarantee of the cardinality of the relationship from “learning context” to “Common Cartridge”, i.e., the LMS may enforce an arbitrary 1-1 relationship. The data contained in the package breaks down into the following categories:

•        “Learner Experience” Data. These are the resources presented directly to the learner, i.e., content resources.

•        Supplemental Resources. These are resources that may be optionally integrated into the learning context by an instructor or other facilitator, e.g., question bank.

•        Operational Data. Data used to control behavioral aspects of the LMS display/interaction with the cartridge such as with LTI.

•        Descriptive Metadata. This is the defined IEEE LOM data, and is represented via existing bindings.

A Common Cartridge is an 1EdTech Content Package conforming to the following basic structure.

•        A Common Cartridge may define a single organization, or include no organization. Multiple organizations are not permitted and the default attribute for organizations is not therefore supported. The single organization is used on import to integrate with the learning context, and defines the basic navigation structure for the package. The organization assumes the predefined “rooted-hierarchy” structure.

•        Only “Learner Experience” resources may be included in the <organization> hierarchy.

•        Operational data (authorization, cartridge-level metadata) are defined via discrete resource types within the package.

•        Supplemental resources must not appear in the organization. The LMS provides a way for the instructor/facilitator to inspect/deploy/utilize these resources as they see fit.

Common Cartridge resources must be identified with GUIDs, in order to facilitate proper integration in systems that execute “by reference” content usage.

4.2      Supported Resource Types

Table 4.1 Common Cartridge Supported Resource Types.

Resource Type

Constraints

Web Content

0 or more

Associated Content

0 or more

QTI Assessment (CC Profiles)

0 or more

QTI Question Bank (CC Profiles)

0 or more

Authorizations Data

0 or 1

Discussion Topic

0 or more

Web Links

0 or more

APIP File

0 or more

EPub3 File

0 or more

IWB File

0 or more

LTI Link

0 or more

4.3      Common Cartridge Information Model

Figure 4.1 CC profile of CP v1.2- Root.

Figure 4.2 CC profile of CP v1.2 - Resources.

  /xsd/imsccv1p3/imscp_v1p1 /profile/cc/ccv1p3/ccv1p3_imscp_v1p1_v1p0.xsd
  http://ltsc.ieee.org/xsd/imsccv1p3/LOM/resource /profile/cc/ccv1p3/LOM/ccv1p3_lomresource_v1p0.xsd
  http://ltsc.ieee.org/xsd/imsccv1p3/LOM/manifest /profile/cc/ccv1p2/LOM/ccv1p3_lommanifest_v1p0.xsd" >
  <metadata>
    <schema>1EdTech Common Cartridge</schema>
    <schemaversion>1.3.0</schemaversion>
    <lomimscc:lom>
      <lomimscc:general>
        <lomimscc:title>
          <lomimscc:string language="en-US">Common Cartridge Test Data Set - Validation Cartridge 1</lomimscc:string>
        </lomimscc:title>
        <lomimscc:description>
          <lomimscc:string language="en-US">Sample materials to test a variety of Common Cartridge content types</lomimscc:string>
        </lomimscc:description>
        <lomimscc:keyword>
          <lomimscc:string language="en-US">Sample</lomimscc:string>
        </lomimscc:keyword>
      </lomimscc:general>
    </lomimscc:lom>
  </metadata>
  <organizations>
    <organizationidentifier="O_1" structure="rooted-hierarchy">
      <item identifier="I_1">
        <itemidentifier="I_00000">
          <title>Psychology, Research, and You</title>
          <itemidentifier="I_00001" identifierref="I_00001_R">
            <title>Learning Objectives</title>
          </item>
          <itemidentifier="I_00002">
            <title>Study Guide</title>
            <itemidentifier="I_00003" identifierref="I_00003_R">
              <title>Pretest</title>
            </item>
          </item>
          <itemidentifier="I_00005" identifierref="I_00005_R">
            <title>Wikipedia - Psychology</title>
          </item>
          <itemidentifier="I_00006" identifierref="I_00006_R">
            <title>Psychology of Faces</title>
          </item>
        </item>
      </item>
    </organization>
  </organizations>
  <resources>
    <resourcehref="I_00001_R/Learning_Objectives.html"
      identifier="I_00001_R" type="webcontent">
      <file href="I_00001_R/Learning_Objectives.html" />
    </resource>
    <resourceidentifier="I_00003_R" type="imsqti_xmlv1p3/imscc_xmlv1p3/assessment" >
      <file href="I_00003_R/assessment.xml"/>
    </resource>
    <resourceidentifier="I_00004_R" type="imsqti_xmlv1p3/imscc_xmlv1p3/question-bank" >
      <metadata>
        <lom:lom>
          <lom:educational>
            <lom:intendedEndUserRole>
              <lom:source>IMSGLC_CC_Rolesv1p2 </lom:source>
              <lom:value>Instructor</lom:value>
            </lom:intendedEndUserRole>
          </lom:educational>
        </lom:lom>
      </metadata>
      <file href="I_00004_R/assessment.xml"/>
    </resource>
    <resourceidentifier="I_00005_R" type="imswl_xmlv1p3">
      <file href="I_00005_R/weblink1.xml"/>
    </resource>
    <resourceidentifier="I_00006_R" type="imsdt_xmlv1p3">
      <file href="I_00006_R/discussion.xml"/>
      <dependencyidentifierref="I_00006_Media"/>
      <dependencyidentifierref="I_media_R"/>
    </resource>
    <resourceidentifier="I_00006_Media" type="associatedcontent/imscc_xmlv1p3/learning-application-resource" >
      <file href="I_00006_Media/angry_person.jpg" />
    </resource>
    <resourceidentifier="I_media_R" type="webcontent">
      <file href="I_media_R/smiling_dog.jpg"/>
    </resource>
  </resources>
</manifest>
 

4.4.5           Cartridge Web Content Type

•        Cartridge web content represents web content that may be referenced by any Learning Application Object in the cartridge.

•        Cartridge web content is represented as a Resource object.

•        It may be directly referenced from a folder Item object.

•        The characteristic object Type must be the value ‘webcontent’.

•        The characteristic object intendeduse is optional and must be one of the values: ‘assignment’, ‘lessonplan’, ‘syllabus’, or ‘unspecified’.

•        If a cartridge web content resource is linked from a Learning Application Object link Item object it must have an Href characteristic object, which represents the launchable resource.

4.4.5.1      The Assignment IntendedUse

•        When a hosting platform offers an assignment tool, it should create an assignment based on the web content rather than a plain web content link in the course. It is expected the instructor will then apply any additional changes to the delivery settings based on the course context (for example setting the number of attempts, or the possible grade if a graded assignment).

4.4.6           Associated Content Type

•        Associated content represents web content that is scoped to a particular resource.

•        Associated content is represented as a Resource object.

•        It may be directly referenced from a folder Item object.

•        The characteristic object Type must be the value ‘associatedcontent/imscc_xmlv1p2/learning-application-resource’

•        If the associated content resource is linked from a Learning Application Object link Item object it must have an Href characteristic object, which represents the launchable resource.

•        The Resource object may contain Dependency objects which reference Resource objects with Type ‘webcontent’.

4.4.7           Discussion Topic Content Type

•        A Discussion Topic is a Learning Application Object that is used to initiate Discussion activity.

•        Discussion topic content is represented as a Resource object.

•        Expected default behavior:

•        Upon import, the discussion topic content will be stored by the tool using its own internal representation.

•        As the cartridge content is added to an actual course, an associated discussion topic will be created in the discussion forum used by the tool.

•        The location of the discussion topic resource object in the cartridge organization dictates the point in the course at which the learner is directed to the item in the discussion forum.

•        The discussion topic group would be the cohort of learners enrolled on the course and the instructor.

•        If the cartridge were added to more than one course, then each course would have its own discussion topic created, each with its own group of enrolled learners.

•        It may be directly referenced from a folder Item object.

•        The characteristic object Type must be the value ‘imsdt_xmlv1p3’.

•        The Resource object Href characteristic object is prohibited.

•        The Resource object must contain a single File object, which references the Discussion Topic descriptor XML file which conforms to the /xsd/imsccv1p3/imsdt_v1p3 schema (see below).

•        The Resource object may contain Dependency objects, which reference Resource objects with Type ‘webcontent’ and/or ‘associatedcontent/imscc_xmlv1p3/learning-application-resource’.

4.4.8           Web Link (URL) Content Type

•        A Web Link is a Learning Application Object that represents a URL.

•        Web Link content is represented as a Resource object.

•        It may be directly referenced from a folder Item object.

•        The characteristic object Type must be the value ‘imswl_xmlv1p3’.

•        The Resource object Href characteristic object is prohibited.

•        The Resource object must contain a single File object, which references the Web Link descriptor XML file which conforms to the /xsd/imsccv1p3/imswl_v1p3 schema (see below).

•        The Resource object must not contain Dependency child objects.

4.4.9           Assessment Content Type

•        Represented as a Resource object.

•        It may be directly referenced from a folder Item object.

•        The characteristic object Type must be ‘imsqti_xmlv1p3/imscc_xmlv1p3/assessment’.

•        The Resource object Href characteristic object is prohibited.

•        The Resource object must contain a single File object, which references the QTI XML file. This file must conform to the 1EdTech CC profile of the QTI 1.2.1 schema, which is /xsd/ims_qtiasiv1p2.

•        The Resource object may contain Dependency objects, which reference Resource objects with Type ‘webcontent’ and/or ‘associatedcontent/imscc_xmlv1p3/learning-application-resource’.

4.4.10       Question Bank Content Type

•        Represented as a Resource object.

•        It must not be directly referenced from a folder Item object.

•        If a question bank is included in a cartridge, then it appears as a resource in the imsmanifest, but it is not included in the organization and reference to the question bank or its question items by any Learning Application Object is prohibited.

•        Zero or more question banks can be included in a cartridge.

•        Access to the question bank is restricted to the instructor, to whom it is provided as a resource for constructing customized assessments.

•        How the tool makes the question bank available to an instructor is undefined.

•        The characteristic object Type must be ‘imsqti_xmlv1p2/imscc_xmlv1p3/question-bank’.

•        The Resource object Href characteristic object is prohibited.

•        The Resource object must contain a single File object, which references the QTI XML file. This file must conform to the 1EdTech CC profile of the QTI 1.2.1 schema which is /xsd/ims_qtiasiv1p2.

•        The Resource object may contain Dependency objects, which reference Resource objects with Type ‘webcontent’ and/or ‘webcontent/imscc_xmlv1p3/learning-application-resource’.

4.4.11       APIP, EPub3, and IWB Resource Types

·         While a Common Cartridge can contain any application files, special support has been added for these file types.  Adding this support allows the 1EdTech Common Cartridge Validator to detect and validate these files as well.  Currently, the validator can check APIP and IWB files, which are 1EdTech specifications.  EPub3 file checking may be added to the validator in the future.

·         Addition of new resource types: ‘IWB’ for interactive whiteboard files, ‘EPUB3’ for EPub 3 files, and ‘APIP’ for Accessible Portable Item Profile.

4.4.12       Learning Tools Interoperability (LTI) Content Type

•        A nLTI Link is a Learning Application Object that represents a self-contained LTI link.

•        LTI Link content is represented as a Resource object.

•        It may be directly referenced from a folder Item object.

•        The characteristic object Type must be the value ‘imsbasiclti_xmlv1p0’.

•        The Resource object Href characteristic object is prohibited.

•        The Resource object must contain a single File object, which references the LTI Link descriptor XML file, which conforms to the /xsd/imsbasiclti_v1p0 schema (see below).

•        The Resource object must not contain Dependency child objects.

4.4.13 Resource Type Extensions

The 1EdTech members recognize that there may be additional resource types that parties to an integration wish to exchange in a Common Cartridge.  Prior to CC v1.3, there was no mechanism to extend the list of resource types without updating the specification XSDs.  With CC v1.3, this constraint is lifted. 

The manifest file can contain resource of type extension, which will also specify a schema and version.  A list of these extensions (in a VDEX file) will be accessible programmatically to the 1EdTech CC Validator and other applications. Anyone wishing to create such a type will register it with 1EdTech (see the 1EdTech CC/LTI Alliance for details on the registration process) and the type will be added to the list of known extensions.  Once an extension is approved and its status is finalized, a named extension type will be added.  A sample manifest resource entry of this type is:

An example of the standards metadata is:

 

<resource identifier="extensionresource1" type="assignment_xmlv1p0" href="Extension_R/assignment.xml">

<metadata>

<schema>assignment</schema>

<schemaversion>1.0</schemaversion>

<lom:lom>

<lom:educational>

<lom:intendedEndUserRole>

<lom:source>IMSGLC_CC_Rolesv1p2</lom:source>

<lom:value>Learner</lom:value>

</lom:intendedEndUserRole>

</lom:educational>

<lom:educational>

<lom:intendedEndUserRole>

<lom:source>IMSGLC_CC_Rolesv1p2</lom:source>

<lom:value>Instructor</lom:value>

</lom:intendedEndUserRole>

</lom:educational>

</lom:lom>

</metadata>

<file href="Extension_R/assignment.xml"/>

<!-- Variant definition -->

<cpx:variant identifier="extensionresource1_variant" identifierref="extensionresource1_variant1">

<cpx:metadata>

<!-- SOME FORM OF METADATA ADDED -->

</cpx:metadata>

</cpx:variant>

<!-- -->

</resource>

<!-- New variant resource *************************************************** -->

<resource identifier="extensionresource1_variant1" type="webcontent">

<file href="Extension_R/Variant1.html"/>

</resource>

<!-- ************************************************************************* -->

</resources>


 

4.5      Use of Inline Descriptor File XML

Previous versions of Common Cartridge placed resource descriptions for the following types in XML files with a specific structure:

•        Assessment

•        Discussion

•        LTI Link

•        Question Bank

•        Web Link

Each of these resources now can be described either in a stand-alone XML file or directly in the manifest.  The motivation for this change is to allow for the case of a cartridge being described wholly in a single XML file.  This file could be offered as the response to a web-service call, easing the movement of cartridges.

Here is an example of an inline discussion topic and web link description.  The same approach can be used with the other resource types.

 

<resource identifier="Resource14"type="imsdt_xmlv1p3">
    <topicxmlns="/xsd/imsccv1p3/imsdt_v1p3"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="/xsd/imsccv1p3/imsdt_v1p3
        /profile/cc/ccv1p3/ccv1p3_imsdt_v1p3.xsd" >
        <title>Unit Reviews</title>
        <texttexttype="text/html">Welcome to Unit reviews where you can post constructive
            comments on this unit for the benefit of other learners and educators.</text>
    </topic>
</resource>
<resourceidentifier="Resource16" type="imswl_xmlv1p3">
    <filehref="WebLink1/link1.xml"/>
</resource>
<resourceidentifier="Resource17" type="imswl_xmlv1p3">
    <filehref="WebLink2/link2.xml"/>
</resource>
<resourceidentifier="Resource18" type="imswl_xmlv1p3">
    <webLinkxmlns="/xsd/imsccv1p3/imswl_v1p3"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="/xsd/imsccv1p3/imswl_v1p3
        /profile/cc/ccv1p3/ccv1p3_imswl_v1p3.xsd" >
        <title>Open2.net: Science and Nature</title>
        <urlhref="http://www.open2.net/sciencetechnologynature/" />
    </webLink>
</resource>

4.6      LOM Metadata

4.6.1           Cartridge Metadata

The Common Cartridge must be described at the manifest level using metadata according to the Common Cartridge profile of the IEEE LOM (loose binding) [IEEE LOM, 05], which describes the range of a mapping from the core elements of the Dublin Core specification v1.1 [DC, 03] to IEEE LOM. This application profile is restrictive. It uses the namespace http://ltsc.ieee.org/xsd/imsccv1p3/LOM/manifest which differs from the IEEE LOM namespace by the insertion of imscc. In contrast, metadata for resources (see below) need to use the original IEEE LOM namespace.

The metadata element as well as its schema and schema version element are required at the manifest level. They must be expressed as follows.

<metadata>

    <schema>1EdTech Common Cartridge</schema>

    <schemaversion>1.3.0</schemaversion>

     … metadata according to Common Cartridge profile of IEEE LOM …

</metadata>

The usage of metadata at other places in the common cartridge is not restricted. This may change in future versions of the specification.

Any media player, codec, browser plug-in or operating system requirements for the cartridge content must be declared in the cartridge-level metadata description. Each entry should include details of the tool/product name, version number, supplier name and the URL for their website. Such requirements must be entered in the description element for the cartridge as free text.

 

4.6.1.1       Mapping of Dublin Core Elements to LOM Metadata Elements

Table 4.2 Mapping of Dublin Core to IEEE LOM.

Dublin Core Element

IEEE LOM Element

Value Type (see documentation of IEEE LOM)

dc:audience

educational.context

One of ‘higher education’, ‘school’, ‘training’, ‘other’. Specifying the educational context is for information only and is not intended to effect learning platform behavior.

dc:contributor, dc:creator, dc:publisher

lifeCycle.contribute.entity with appropriate value of lifeCycle.contribute.role

The value held by the Entity element shall be a character string literal that is the canonical lexical

representation of a valid vCard as defined in IETF RFC 2426:1998.

dc:coverage

general.coverage

LangString

dc:date

lifeCycle.contribute.date

YYYY[-MM[-DD[Thh[:mm[:ss[.s[TZD]]]]]]]

dc:description

general.description

LangString

dc:format

technical.format

— A literal that is the canonical lexical representation of a Multipurpose Internet Mail Extension

(MIME) type value from RFC 2048

— The token non-digital

dc:identifier

general.identifier

Consists of catalog set to e.g. ‘ISBN’ and entry containing the actual ISBN number

dc:language

general.language

Language identifier (as defined in ISO 639-1, ISO 639-2, and ISO 3166-1)

Or the token none

dc:relation

Relation

This is a structure consisting of kind and resource

dc:rights

Rights

Structure containing optional cost, copyrightAndOtherRestrictions and description

dc:source

Not mapped

---

dc:subject

general.keyword (see also classification.keyword)

in general.keyword LangString, in classification.keyword choice of purpose, taxonPath, description, and LangString

dc:title

general.title

LangString

dc:type

Educational.learningResourceType

Set to
“1EdTech Common Cartridge”

4.6.2           Roles Metadata

If metadata is applied to resources, then it must be based on IEEE LOM. In particular, it must use the IEEE LOM namespace http://ltsc.ieee.org/xsd/imsccv1p3/LOM/resource.

There are situations where resources may need to be specified within the organization, but should not be made visible in player mode upon default import of the cartridge. One such situation is the inclusion of instructor manuals, lesson plans, instructor notes and solution files that should only be visible to instructors or perhaps instructors and mentors. In other situations, publishers may wish to provide additional, optional resources that may be selectively released to students or mentors and students, or mentors only, by the instructor at some later date. In each case, there is a need to indicate where the resources should appear within the organization even though the resources are not initially visible to learners in the cartridge player. These resources must be made visible in cartridge editors so that the settings may be modified when and if appropriate.

To meet these needs, the common cartridge applies optional “roles” metadata associated with the resource in the manifest file. If not present, then the default behavior is that the resource would be viewable by all users. If present, then it declares the roles for which the resource would be viewable. 

The following supported roles are defined in the vocabulary: 

IMS_GLC_CC_Rolesv1p2

 

 

Learner

Instructor

Mentor

CC version 1.0

X

X

 

CC version 1.1

X

X

X

CC version 1.2

X

X

X

CC version 1.3

X

X

X

For example:

<lom:lom>

   <lom:educational>

      <lom:intendedEndUserRole>

         <lom:source>IMSGLC_CC_Rolesv1p2</lom:source>

         <lom:value>Learner</lom:value>

      </lom:intendedEndUserRole>

        <lom:intendedEndUserRole>

         <lom:source>IMSGLC_CC_Rolesv1p2</lom:source>

         <lom:value>Instructor</lom:value>

      </lom:intendedEndUserRole>

   </lom:educational>

</lom:lom>

Note: specifying a role is intended to have an effect on how a learning platform behaves.  For example, content intended for an instructor should not be visible to a learner.

4.6.3           Curriculum Standards Metadata

Curriculum standards metadata is supported for the cartridge, resource, and question item.  The design of this support allows for at least the following:

  • Any curriculum standard can be used, as long as it supports unique identifiers.  The provider of a specific standard is designated by the string-valued ‘provider’ element.  In order to facilitate interoperability, 1EdTech will maintain a list of registered providers, but custom, i.e. unregistered providers, are permitted.  Note that the provider can be accompanied by region and version string-valued attributes.  These are intended to be for descriptive value only.
  • Any cartridge, resource, or question item can be associated with 0 or more curriculum standards from 1 or more providers.
  • The provider value and GUID should be sufficient to unambiguously identify a standard.
  • An optional GUID label is supported, since this should make standards more readily apparent when examining the cartridge.

Possible Applications:

  • A content creator aligns cartridge, resource, or question item to specific standards.
  • An instructor or student seeks a cartridge that has material aligned to a standard with which they need additional study.  A discovery tool might locate a cartridge that matches a specific standard or a similar one.  Such a tool might be able to navigate standards relationships programmatically to suggest more general or more detailed content.
  • An instructor or administrator seeks to assess how students performed on a test, broken down by results per standard.  A learning platform could use alignment metadata to produce such reports.

Curriculum Standards metadata can be applied at the cartridge, resources, or question item level.  The approach for either the cartridge or non-assessment resources is identical and is illustrated below:

<resource identifier="RES001" type="webcontent">
   <metadata>
      <curriculumStandardsMetadataSet xmlns=/xsd/imscsmetadata_v1p0>

        <curriculumStandardsMetadata providerId=”ASN" region=”Georgia” version=”2011”>
           <setOfGUIDs>
              <labelledGUID>
               <label>ASN PURL for Florida on subject "..." and level "..".</label>
                  <GUID>http://purl_org/ims/cck12ls/usa_florida_LA_4_2_1_5 </GUID>
              </labelledGUID>
              <labelledGUID>
               <label>ASN PURL for Florida on subject "..." and level "..".</label>
                  <GUID>http://purl_org/ims/cck12ls/usa_florida_LA_4_4_1_6 </GUID>
              </labelledGUID>
           </setOfGUIDs>
        </curriculumStandardsMetadata>             
      </curriculumStandardsMetadataSet>             
   </metadata>
...

At the assessment resource level, the syntax required is slightly different.  We can’t place metadata directly into the assessment description file (XML) and so we place it in the manifest and include the item’s identifier.

For the resource that holds the assessment, the curriculumStandardsMetadataSet metadata element must include the attribute resourceLabel=”QTI-Assessment”.

For item-level metadata, the element may include the attribute resourceLabel=”QTI-Assessment” and resourcePartId=the Id of the QTI item, i.e., ident attribute of item element. This mechanism associates the curriculum standards metadata, which resides in the imsnanifest.xml file with a specific item in the assessment file.

 

<resource identifier="RES_MOD4_LSN4_exam1" type="imsqti_xmlv1p2/imscc_xmlv1p3/assessment" >
    <metadata>
        <curriculumStandardsMetadataSet resourceLabel="QTI-Assessment">
            <curriculumStandardsMetadata providerId="ASN">
                …
            </curriculumStandardsMetadata>
        </curriculumStandardsMetadataSet>
        <curriculumStandardsMetadataSet resourceLabel="QTI-Item"resourcePartId="c10752c0-5a03-49c7-a1fd-8b7e08df80ec" >
            <curriculumStandardsMetadata domainId="ASN">
            …
            </curriculumStandardsMetadata>
        </curriculumStandardsMetadataSet>
 

And in the referenced assessment file, the item ident attribute matches the resourcePartId in the manifest.

 

<assessment ident="18f098f1-e9a4-4799-8dbc-f4984d16a122" title="4_12ARegularSegmentOneExam">
    …
    <sectionident="8b3a8b99-3919-498e-bcfe-cea2b0759e5e" title="4_12ARegularSegmentOneExam">
        <itemident="c10752c0-5a03-49c7-a1fd-8b7e08df80ec" title="4_12ARegularSegmentOneExam">
            <itemmetadata>
                <qtimetadata>
    …
 

4.7      Discussion Topics

Discussion topics are described in a descriptor file as follows:

4.7.1            Example Instance

<?xml version="1.0" encoding="UTF-8"?>
<topic xmlns="/xsd/imsccv1p3/imsdt_v1p3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="/xsd/imsccv1p3/imsdt_v1p3 

  /profile/cc/ccv1p2/ccv1p3_imsdt_v1p3.xsd" >
  <title>The Psychology of Faces</title>
  <text texttype="text/html">Is recognition of human emotional states learned or innate? Might there be a culture in the world that expresses joy through scowling and fear through laughter? Does your dog smile when he's happy? &lt;br/&gt; &lt;img src="$1EdTech-CC-FILEBASE$../I_media_R/smiling_dog.jpg"/&gt;</text>
  <attachments>
    <attachmenthref="../I_00006_Media/angry_person.jpg" />
  </attachments>
</topic>

 

•        topic root element

•        title Title of this topic

•        text  Text for this topic – if text/html can contain markup and references to both cartridge and Learning Application Object web content.

•        texttypevalues(TEXT/HTML or TEXT/PLAIN)

•        attachments contains one to many attachment objects

•        attachment Specifies an attachment

•        href Specifies the relative path of the attachment file – must be to a Learning Application Object web content resource.

4.7.2           Schema

<xs:schema targetNamespace=" /xsd/imsccv1p3/imsdt_v1p3" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns=" /xsd/imsccv1p3/imsdt_v1p3  /profile/cc/ccv1p3/ccv1p3_imsdt_v1p3.xsd" elementFormDefault="unqualified">
    <xs:elementname="topic" type="topicType"/>
    <xs:complexType name="topicType">
        <xs:sequence>
            <xs:element name="title" type="xs:string"/>
            <xs:element name="text">
                <xs:complexType>
                    <xs:simpleContent>
                        <xs:extension base="xs:string">
                            <xs:attribute name="texttype"type="textTypeType" default="text/plain"/>
                        </xs:extension>
                    </xs:simpleContent>
                </xs:complexType>
            </xs:element>
            <xs:element name="attachments"minOccurs="0">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="attachment"minOccurs="1" maxOccurs="unbounded">
                            <xs:complexType>
                                <xs:attribute name="href" type="xs:string" use="required"/>
                            </xs:complexType>
                        </xs:element>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
        </xs:sequence>
    </xs:complexType>
    <xs:simpleType name="textTypeType">
        <xs:restriction base="xs:string">
            <xs:enumeration value="text/html"/>
            <xs:enumeration value="text/plain"/>
        </xs:restriction>
    </xs:simpleType>
</xs:schema>
 

4.8      Web Links

Web links are described in a descriptor file as follows:

4.8.1            Example Instance

<?xml version="1.0" encoding="UTF-8"?>
<webLink xmlns="/xsd/imsccv1p3/imswl_v1p3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="
  /xsd/imsccv1p3/imswl_v1p3

   /profile/cc/ccv1p3/ccv1p3_imswl_v1p3.xsd" >
  <title>Wikipedia - Psychology</title>
  <url href="http://en.wikipedia.org/wiki/Psychology" target="_self" windowFeatures="width=100, height=100"/>
</webLink>

 

•        webLink  root element

•        title Title of this web link

•        url  URL which the web link represents

•        hrefURL value

•        target any valid value for the HTML <a> tag target attribute

•        windowFeatures – an optional string that can be used as the feature parameter for the standard javascript window open function

4.8.2           Schema

<xs:schema targetNamespace="/xsd/imsccv1p3/imswl_v1p3" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns=" /xsd/imsccv1p3/imswl_v1p3
    /profile/cc/ccv1p3/ccv1p3_imswl_v1p3.xsd" elementFormDefault="unqualified">
    <xs:elementname="webLink" type="webLinkType"/>
    <xs:complexType name="webLinkType">
        <xs:sequence>
            <xs:element name="title" type="xs:string"/>
            <xs:element name="url">
                <xs:complexType>
                    <xs:attribute name="href" type="xs:string" use="required"/>
                    <xs:attribute name="target"type="xs:string" />
                    <xs:attribute name="windowFeatures"type="xs:string" />
                </xs:complexType>
            </xs:element>
        </xs:sequence>
    </xs:complexType>
</xs:schema>

 

4.9      APIP, EPUB3, and IWF File Resources

These files may be included in the Common Cartridge file, in which case they must also be included in the imsmanifest.xml file.  The 1EdTech Common Cartridge Validator will attempt to check APIP and IWB files.  Platforms supporting Common Cartridge may also choose to give these files special handling.  The following is an example of the relevant sections of the manifest:

 

   <resource identifier="I_00003_R"type="imsapip_zipv1p0">
      <filehref="I_00003_R/apipv1p0_CoreTest_VC_IP_01.zip" />
    </resource>
    <resourceidentifier="I_00006_R" type="imsiwb_iwbv1p0">
      <filehref="I_00006_R/validtest1.iwb"/>
    </resource>
    <resourceidentifier="I_00007_R" type="idpfepub_epubv3p0">
      <filehref="I_00007_R/moby-dick-mo-20120206.epub" />
    </resource>
 

4.10 Learning Tools Interoperability

Note that for historical reasons, LTI is referred to in some areas of this document as Basic LTI.

An LTI link is a simplified and self-contained LTI link. The LTI link is defined in the resource section of an 1EdTech Common Cartridge as follows:

<resource identifier="I_00010_R" type="imsbasiclti_xmlv1p3">

   <file href="I_00001_R/BasicLTI.xml"/>

</resource>

The href in the resource entry refers to a file path in the cartridge that contains an XML description of the LTI link.

<?xml version="1.0" encoding="UTF-8"?>
<cartridge_basiclti_link xmlns="/xsd/imslticc_v1p0"
    xmlns:blti = "/xsd/imsbasiclti_v1p0"
    xmlns:lticm ="/xsd/imslticm_v1p0"
    xmlns:lticp ="/xsd/imslticp_v1p0"
    xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation = "/xsd/imslticc_v1p0 /xsd/lti/ltiv1p3/imslticc_v1p3.xsd
    /xsd/imsbasiclti_v1p0 /xsd/lti/ltiv1p0/imsbasiclti_v1p0.xsd
    /xsd/imslticm_v1p0 /xsd/lti/ltiv1p0/imslticm_v1p0.xsd
    /xsd/imslticp_v1p0 /xsd/lti/ltiv1p0/imslticp_v1p0.xsd" >
    <blti:title>Grade Book</blti:title>
    <blti:description>Grade Book with many column types</blti:description>
    <blti:custom>
        <lticm:property name="keyname">value</lticm:property>
    </blti:custom>
    <blti:extensions platform="my.lms.com">
        <lticm:property name="keyname">value</lticm:property>
    </blti:extensions>
    <blti:launch_url>url to the LTI launch URL</blti:launch_url>
    <blti:secure_launch_url>secure url to the LTI launch URL</blti:secure_launch_url>
    <blti:icon>url to an icon for this tool (optional)</blti:icon>
    <blti:secure_icon>secure url to an icon for this tool (optional)></blti:secure_icon>
    <blti:vendor>
        <lticp:code>vendor.com</lticp:code>
        <lticp:name>vendor.name</lticp:name>
        <lticp:description>This is a vendor of learning tools.</lticp:description>
        <lticp:url>http://www.vendor.com/ </lticp:url>
        <lticp:contact>
            <lticp:email>support@vendor.com </lticp:email>
        </lticp:contact>
    </blti:vendor>
    <cartridge_bundle identifierref="BLTI001_Bundle"/>
    <cartridge_icon identifierref="BLTI001_Icon"/>
</cartridge_basiclti_link>
 

The launch_url contains the URL to which the LTI Launch is to be sent.   The secure_launch_url is the URL to use if secure http is required.  One of either the launch_url or the secure_launch_url must be specified. It is acceptable to specify both and if both are specified, the Tool Consumer (TC) decides which to use. Typically, the TC will use a secure_launch_url when embedding the Tool in a secure page and the launch_url when embedding the tool in a non-secure page. So, it’s important that the Tool Provider (TP) provides the same functionality whether the launch_url or secure_launch_url is used.

The icon and secure_icon are both optional and indicate a URL to be used for an icon to the tool.

Once the LTI link is defined in the resources section of the cartridge manifest, it can be referenced in the organization section of the manifest as needed:

<item identifier="BasicLTI1" identifierref="I_00010_R">

   <title>Homework Problems</title>

</item>

 The TC will generally display the title in the item entry in the user interface rather than title in the basic_lti_link entry.

The optional custom section can contain a set of key value pairs that were placed in the link in the system that originally authored the link.  For example if the link were a section in an eTextbook, there might be a setting like:

<parameter key="section">1.2.7</parameter>

 

These parameters are sent back to the external tool when the tool is launched.  If LTI link is imported and then exported the custom should be maintained across the import/export process unless the intent is to re-author the link.

The extensions section allows the hosting TC to add its own key/value pairs to the link. The TC may use extensions to store information that the TC or authoring environment might use across an export-import cycle.  In order to allow multiple sets of extensions to be contained in the same LTI descriptor, authoring environments should add the platform attribute and include an identifier that identifies the authoring environment.

It is possible to include the icon for the link in the cartridge instead of including it as a URL using the cartridge_icon entry in the descriptor.  The identifierref attribute points to a link that includes the icon image and a dependency is added to the resource section of the LTI resource entry in the manifest as shown below:

<resource identifier="I_00010_R"type="imsbasiclti_xmlv1p3">
    <filehref="I_00001_R/BasicLTI.xml"/>
    <dependencyidentifierref="BLTI001_Icon"/>
</resource>

<resourceidentifier="BLTI001_Icon"
    type="associatedcontent/imscc_xmlv1p2/learning-application-resource" >
    <filehref="BLTI001_Media/learning_icon.gif" />
</resource>
 

4.11 QTI

 

4.11.1       Overview

A Common Cartridge may contain either/both of two Learning Object Resource types that are based on the CC QTI Profile: Assessments and Question Banks. Generally Assessments are meant to represent an ordered question set and may include optional attributes that apply to the set as a whole. A CC Question Bank refers to a QTI Object Bank, constrained to hold just those question types supported in the CC profile. Assessments should employ the <assessment> QTI element (see section Assessments vs. Object Banks directly below). Question Banks are meant to represent unordered sets of questions with no associated attributes applying to the set as a whole (though metadata is permitted). Question banks should use the <objectbank> QTI element. In addition, question banks should have no representation in the organizations section of the manifest.

<questestinterop> is the root element for all CC QTI documents. Directly inside this will be either an <assessment><section> or <objectbank> structure as described in the next section.

The $1EdTech-CC-FILEBASE$ token may be used in any portion of questions, answers or feedback. It is intended to help identify paths that reference media files that are required by the assessment and are included in the common cartridge. If the files are not moved after extraction, the path following the token should be the same directory that contains the QTI file itself. The token should ALWAYS be included when making relative references to other files so that import engines can correctly handle any required path translations. Elements or multi-element constructs other than those covered explicitly below are prohibited.

4.11.2        Assessments vs. Object Banks

Assessments are represented with a single <assessment> element with required ident and title attributes and optional language attribute. The <assessment> element may contain an optional <presentation_material> element to represent information to be displayed prior to a student launching the assessment.

A <qtimetadata> element can be present where CC specific metadata elements are allowed within <qtimetadatafield> structures as follows:

<qtimetadatafield>

   <fieldlabel></fieldlabel>

   <fieldentry></fieldentry>

<qtimetadatafield>

 

fieldlabel

Fieldentry

cc_profile

cc.exam.v0p1

qmd_assessmenttype

The type of assessment role. The only supported value is 'Examination'. 

qmd_scoretype

'Percentage' scoring is always used.

qmd_feedbackpermitted

If 'No' then students should not see any feedback for this assessment. Default is 'Yes'.

qmd_hintspermitted

If 'No' then students should not see any hints for this assessment. Default is 'Yes'. Note that hints are not profiled and their presence not recommended.

qmd_solutionspermitted

If 'No' then students should not see any feedback flagged as Solution for this assessment. Default is 'Yes'.

qmd_timelimit

Time limit is an integer value expressed in minutes. If unspecified there is no time limit.

cc_allow_late_submission

Indicates whether the time limit should be strictly enforced. Should only be provided if the qmd_timelimit was also specified. Allowed values are "Yes" and "No". The default is "Yes"

cc_maxattempts

Allows specifying the maximum allowed user attempts. Allowed values are 1, 2, 3, 4, 5 and "unlimited". The default is 1.

language

 

In addition to the optional <presentation_material> and <qtimetadatafield> elements the <assessment> element must contain exactly one <section> element with a required ident and an optional title attribute. The <section> element contains one or more <item> elements only.

Object banks are represented as a single <objectbank> element, which can contain one or more <item> elements only.

The 'rubric' element has been returned to the Assessment object  (it is still prohibited in the Section and Item objects).  Multiple 'rubric' entries are permitted and each 'rubric' has 'material as its sole child.  The 'rubric' field is used to supply provide instructions relevant to the Assessment.

4.11.3        Item Overview

<item> elements represent individual questions in assessments or object banks (i.e. question banks). An Item is built of different elements. The Common Cartridge profile imposes additional restrictions on how an item can be built on top of the QTI 1.2 specifications. Some of those restrictions are common to all question types while others are specific to a given one. However, regardless of the question type, a QTI Item should always follow the same structure:

item

  1 itemmetadata: (which specifies the profile used for this item)

  1 presentation

    1 material/mattext: the question text

    1 response: presenting the choices/input

  0-1 resprocessing (mandatory except for Essay Question)

     1 outcomes: declare the SCORE variable

      0-1 respcondition: display general feedback

      0-n respcondition: per-answer feedback (for LID based items, at most one per answer)

      1   respcondition: setting the score to 100 if correct, display correct feedback

      0-1 respcondition: display general incorrect feedback

  0-n itemfeedback

 (1 meaning one and only one, 0-1 at most one, 0-n any number)

4.11.4       Itemmetadata

The <itemmetadata> element contains a set of <qtimetadata> element where CC specific metadata elements are allowed within <qtimetadatafield> structures (as in Assessments vs. Object Banks section above) as follows:

fieldlabel

fieldentry

cc_profile

At least this field is required.  Corresponds to the six supported question types. Can be: cc.multiple_choice.v0p1, cc.multiple_response.v0p1, cc.true_false.v0p1, cc.fib.v0p1, cc.pattern_match.v0p1, or cc.essay.v0p1

cc_question_category

A single keyword value

cc_weighting

cc_weighting specifies the preferred points value for the question. This is useful because the scoring variables are normalized to percentage-based values between 0 and 100. Additionally, this allows for points possible to be specified for manually graded items such as essay questions.

Must be an integer value 0 - 99 if provided. Otherwise a default of 1 is assumed.

qmd_scoringpermitted

Yes (Because there is no automated scoring for essays, we use standard qmd metadata to indicate the item is manually scored.)

qmd_computerscored

The computerscored for essay must be No.

 

4.11.5       Question Text

The Question Text is represented with a single <material><mattext> structure directly inside the <presentation>.  The question text may be presented in either plain text or html format. If the html format is used, the mattext element must have a texttype attribute with a value of “text/html”. If plain text is used, the texttype value of “text/plain” is optional as this is the default.

While the usage of elements such as varimage are prohibited, it is possible to add references to any web content or dependency contained in the cartridge by using HTML markup:

<presentation>

  <material>

    <mattext texttype="text/html"><![CDATA[ Identify to which city belongs this monument:<img src= "$1EdTech-CC-FILEBASE$../images/bigben.jpg" alt="" style="border: 0px solid rgb(0, 0, 0);">

    ]]</mattext>

  </material>

  <response_str ident="QUE__2869_1_RS" rcardinality="Single">

    <render_fib>

      <response_label ident="QUE__2869_1_ANS" rshuffle="No"/>

    </render_fib>

  </response_str>

</presentation>

 

4.11.6       Automatic Scoring

The Scoring Variable is declared in the <outcomes> section of the <resprocessing>:

<outcomes>

   <decvar minvalue="0" maxvalue="100" varname="SCORE" vartype="Decimal"/>

</outcomes>

For all question types outside of the Essay question, scoring is done in a single <respcondition> with a continue flag set to No. The outcome is always a variable named SCORE which value must be set to 100 in case of correct answer. Partial scores (not 0 or 100) are not supported.

The <conditionvar> depends on the question type, but the structure is always the same:

<respcondition continue="No">

  <conditionvar><!-- will vary per question type --></conditionvar>

  <setvar action="Set" varname="SCORE">100</setvar>

  <displayfeedback feedbacktype="Response" linkrefid="correct_fb"/>

 </respcondition>

Note that the <displayfeedback> is optional, see below.

4.11.7       Feedback

4.11.7.1  Overview

Feedback support is optional. One should not expect a consumer to support all feedback types, or even any of them. Feedbacks are declared using 2 elements:

In a <respcondition> a <displayfeedback> element points to an <itemfeedback>. The <respcondition> defines the context when the feedback should be displayed:

<displayfeedback feedbacktype="Response" linkrefid="correct_fb"/>

Then for each <displayfeedback> there should be one and only one <itemfeedback>. The <itemfeedback> contains the actual feedback text. It is recommended to be in a single <material><mattext> structure. The text can either be plain text or HTML. If HTML, it is possible to add references to any web content or dependency contained in the cartridge.

<itemfeedback ident="correct_fb">

  <material>

    <mattext texttype="text/html">Good</mattext>

  </material>

 </itemfeedback>

4.11.7.2  Feedback Ident Naming Convention

Feedback should follow the naming convention for their ident based on their feedback type. See each feedback type for the naming to use.

4.11.7.3  General Feedback

General feedback is given as an unconditional feedback with continue flag on for further processing:

<respcondition continue="Yes">

   <conditionvar><other/></conditionvar>

   <displayfeedback feedbacktype="Response" linkrefid="general_fb" />

</respcondition>

If General Feedback is given, it should be the first <respcondition> element in the <resprocessing> section of the Item since it should always be evaluated.

The ident for the general feedback should be: general_fb

4.11.7.4  General Correct Feedback

General Correct Feedback, if present, is set in the same <respcondition> element that sets the Score to 100.

<respcondition continue="No">
    <conditionvar><!-- will vary per question type --></conditionvar>
    <setvaraction="Set" varname="SCORE">100</setvar>
    <displayfeedbackfeedbacktype="Response"linkrefid="correct_fb"/>
</respcondition>
 

The ident for the general correct feedback should be: correct_fb.

4.11.7.5  General Incorrect Feedback

General incorrect feedback, if present, is the last <respcondition> element in the <resprocessing> element, right after the <respcondition> in charge of setting the score. Since the <respcondition> for setting the score has continue flag set to No, this last <respcondition> will only be evaluated if the user did not answer the correct response.

Since it relies on the presence of an automatic grading, General Incorrect Feedback is not supported for Essay questions.

<respcondition>
    <conditionvar><other/></conditionvar>
    <displayfeedback feedbacktype="Response"linkrefid="general_incorrect_fb" />
</respcondition>
 

The ident for the general incorrect feedback should be: general_incorrect_fb

4.11.8       Hints

Hints are not profiled and therefore it is recommended not to include them in Items.

 

4.11.9       LID based Question Types: True/False, Multiple Choice and Multiple Response

4.11.9.1  Overview and Profiles

LID (Logical Identifier) based questions are questions where the user must select one or multiple answers among a set of choices.

The profiles for LID based questions are:

  • cc.mutliple_choice.v0p1 for multiple choice questions when a single answer can be selected
  • cc.mutliple_response.v0p1 for multiple choice questions where multiple answers can be selected
  • cc.true_false.v0p1 for true/false questions

4.11.9.2  Presentation

Multiple_choice, multiple_response, and true_false questions use a <response_lid> element to contain the individual answers. There is a required ident and an rcardinality attribute which should be set to Single for multiple choice and true false questions and Multiple for multiple_response questions.

The <response_lid> element contains a single <render_choice> element with a shuffle (Yes/No) attribute to indicate whether or not scrambling of answer choices is allowed.

The <render_choice> element contains one or more <response_label> elements with a required ident attribute. The < response_label > elements contain a single <material><mattext> structure holding the text of the individual answers. The text can either be plain text or HTML text, in which case it can refer to Web Content and Dependencies contained in the Cartridge (using the $1EdTech-CC-FILEBASE$ token).

 Response.rshuffle is not supported here.

4.11.9.3  Response Processing: Multiple Choice

The <conditionvar> is made of a single <varequal> element checking if the correct identifier was selected.

<respcondition continue="No">
    <conditionvar>
        <varequalrespident="response_1">answer_4</varequal>
    </conditionvar>
    <setvaraction="Set" varname="SCORE">100</setvar>
    <displayfeedback feedbacktype="Response"linkrefid="correct_fb"/>
</respcondition>
 

4.11.9.4  Response Processing: True-False

True False uses the same <respcondition> than Multiple Choice questions.

4.11.9.5  Response Processing: Multiple Answers

Only ‘All or Nothing’ grading is supported: a single combination is considered correct, all others are considered incorrect answers. The combination is expressed using a <and> containing a combination of <varequal> and <not><varequal> in the form:

<respcondition continue="No">
    <conditionvar>
        <and>
            <not>
                <varequal case="Yes"respident="response_1">answer_1</varequal>
            </not>
            <varequal case="Yes"respident="response_1">answer_2</varequal>
            <varequal case="Yes"respident="response_1">answer_3</varequal>
            <not>
                <varequal case="Yes"respident="response_1">answer_4</varequal>
            </not>
        </and>
    </conditionvar>
    <setvaraction="Set" varname="SCORE">100</setvar>
    <displayfeedback feedbacktype="Response"linkrefid="correct_fb"/>
</respcondition>
 

As per QTI 1.2 specifications, <conditionvar> is already an implicit <and>, and so the <and> in the example above could be omitted. A consumer should support constructs with or without the <and>.

Note that the specification also permits <or> as in, for example:

<respcondition continue ="No" >
    <conditionvar>
        <or>
            <varequal case ="No" respident ="response_1" >London </varequal>
            <varequal case ="No" respident ="response_1" >Londres </varequal>
        </or>
    </conditionvar>
    <setvar action ="Set" varname ="SCORE" >100 </setvar>
</respcondition>
 

No nesting is allowed, a <not> should only contain a <varequal>.

4.11.9.6  Response Processing: Per-answer feedback

Combinatory Responses feedback is not defined (for example, a feedback if the answer 1 and 3 are selected). However per-answer feedback is supported. If present, it must be placed directly after the general item feedback <respcondition>. There can be at most one answer feedback per answer, so it is not required to have a feedback for each answer.

Each feedback answer is in its own <respcondition> with continue flag on for further processing:

<respcondition continue=”Yes”>

  <conditionvar>

    <varequal respident="response_1">Answer1</varequal>

  </conditionvar>

  <displayfeedback feedbacktype="Response" linkrefid="answer1_fb"/>

</respcondition>

<respcondition continue=”Yes”>

  <conditionvar>

    <varequal respident="response_1">Answer2</varequal>

  </conditionvar>

  <displayfeedback feedbacktype="Response" linkrefid="answer3_fb"/>

</respcondition>

 

For each feedback, there must be one and only one corresponding <itemfeedback> element.

The naming convention for answer feedback is: {answer ident}_fb.

4.11.10    FIB based Questions: Fill-in-the-Blank and Pattern Matching

4.11.10.1                       Overview and Profiles

Fill in the Blank and Pattern Matching are similar question types which mostly differ in how they evaluate the correct answer, either based on equality (Fill in the Blank) or on a matching rule (Pattern Matching).

The profile for Fill in the Blank is cc.fib.v0p1, the profile for Pattern Match (Simple containement) is cc.pattern_match.v0p1. The support for Pattern Matching Question type is optional.

4.11.10.2                       Presentation

Fill-in-the-blank questions use a single <response_str> element with a required Ident. The <response_str> element contains a single <render_fib> element. The rows attribute, if specified, must be set to 1. The columns attribute may be set any positive integer but may be ignored.

4.11.10.3                       Response Processing: Fill-in-the-Blank

Fill-in-the-blank questions are not case sensitive on grading as indicated by setting the case attribute to "No" in the <varequal> element.

<respcondition continue="No">

  <conditionvar>

    <varequal case="No" respident="response_1">London</varequal>

  </conditionvar>

  <setvar action="Set" varname="SCORE">100</setvar>

</respcondition>

Multiple alternate answers are supported, but since the support of multiple possible answers is optional, the most relevant answer should be the 1st proposed choice and a consumer that can support only one valid answer should use the 1st one.

<respcondition continue="No">

  <conditionvar>

     <varequal case="No" respident="response_1">London</varequal>

     <varequal case="No" respident="response_1">Londres</varequal>

  </conditionvar>

  <setvar action="Set" varname="SCORE">100</setvar>

</respcondition>

4.11.10.4                       Response Processing: Simple Pattern Match

Simple Pattern Match is only checking for the inclusion of the answer into the response. Simple Pattern match questions may optionally be case sensitive by setting case="Yes", but the default is NOT case sensitive. To check if a string is contained anywhere in the response the varsubstring condition is used as follows:

<conditionvar>

   <varsubstring respident="response_1" case="No">expected</varsubstring>

</conditionvar>

Alternate answers are not supported (only a single varsubstring is allowed).

 

4.11.11    Essay Question

4.11.11.1                       Overview and Profile

Essay based questions are questions where the user answers with a free unbounded text. Essay question are not expected to be automatically graded. However a sample solution can be made available to help the grader in his evaluation.

The profile for essay question is: cc.essay.v0p1 .

4.11.11.2                       Presentation

Presentation is using the same construct as FIB question types.

4.11.11.3                       Sample Solution

Essay questions are a bit apart from the other since they do not support automatic grading. In place they might offer a sample solution to help the grader evaluate the response.

Essay questions can indicate at most one sample answer as follows:

<itemfeedback ident="solution">

  <solution>

    <solutionmaterial>

     <material>

        <mattext texttype="text/html"><![CDATA[here is the sample solution]]></mattext>

     </material>

    </solutionmaterial>

  </solution>

</itemfeedback>

If a Solution is provided there is no need to also include a <displayfeedback> element in the <resprocessing> section since the feedback is already in a <solution> element. A consumer is expected to understand that in the context of an essay question, the <solution> element, if present, represents the sample solution.

 

4.11.12    Further Element/Attribute Restrictions for Common Cartridge

The setvar element supports an action attribute with values of Add, Set, and Subtract. In Common Cartridge, only Set is allowed.

The MaterialSelection selection should only allow the mattext element. In addition the texttype attribute should only allow values of text/html and text/plain and the element text must be wrapper in CDATA. Additional attributes are not allowed.

The rcardinality attribute on the response_lid and response_str elements only allow values of Single and Multiple. The value Ordered is not supported.

The rtiming attribute on the response_lid and response_str elements is not supported.

The render_fib element allows many attributes.

1.  encoding – “The coding to be used for the text. The default value of UTF-8 is assumed. This attribute is not allowed.

2.  charset – “The character set that is to be used to represent the text string. Default value is ascii-us. This attribute is not allowed.

3.  rows – The number of rows available for the data entry is optional.

4.  columns – The number of columns available for the data entry is optional.

5.  maxchars – The maximum number of characters available for the data entry is optional.

6.  Prompt – “The type of prompt presented to the participant in which the FIB data is to be entered. This is an enumeration with values of Box, Dashline, Asterisk, and Underline. Default value is Box. This attribute is not allowed as the display format is determined by the tool.

7.  fibtype – “The type of data expected. This is an enumeration with values of String, Integer, Decimal, Scientific, and Boolean. This is restricted to the default value of String. All other values are prohibited.

8.  minnumber – “The minimum number of responses that must be supplied by the participant. This attribute is prohibited. Only one response is allowed.

9.  maxnumber – “The maximum number of responses that can be supplied by the participant. This attribute is prohibited. Only one response is allowed.

The render_fib element is prohibited from having any children.

The flow element is not allowed.

4.12 Assessment in Common Cartridge

Common Cartridge supports only one role of assessment, which maps to the 1EdTech concept of ‘Examination’ (as defined by the QTI metadata attribute ‘qmd_assessmenttype’).

An assessment must contain exactly one section, which contains all questions delivered by the assessment. Multiple sections and references to questions in an object bank are not supported.

An assessment does support the use of a number of metadata attributes, which can carry additional delivery information about the assessment such as maximum attempts and time limit. These are defined in the profile.

4.12.1       Questions

The Common Cartridge supports profiles of the following question types:

•        Multiple Choice (Single Response)

•        Multiple Choice (Multiple Response)

•        True/False

•        Essay

•        Simple Fill in the Blank – single response box with multiple correct answers that are processed as an exact match

•        Pattern Match – single response box with multiple potential answers that support exact match and containment matching.

Note that support for multiple response, essay, and pattern match are optional; they are permitted exceptions for those learning platforms that do not provide these types of questions natively.

 

The profiles for each of these question types describe how they support:

•        feedback

•        sample solutions

•        relative scoring

In addition, questions support a number of metadata attributes, which describe:

•        a suggested weighting for the question in the assessment

•        a category for the question.

Instances of these questions may be included in an assessment or a question bank.

CC supports general feedback, general correct feedback, general incurred feedback, and per-answer feedback.

For full details refer to the profile descriptions.

4.12.2       Question Bank

The CC question bank profiles the use of the QTI object bank. A question bank represents a collection of questions that are associated with a particular learning context, but not used within it.  The question bank allows for the exchange of questions to a target tool.  Both the representation of a question bank, and how questions are utilized once the cartridge has been imported into the tool are tool specific.  Assessments within a package cannot reference questions contained within the question bank. Multiple question banks are allowed.

The behavior of a tool in handling question banks is undefined.

4.13 Vocabularies

Vocabularies refer to a set of string constants used to specify pre-defined values for metadata elements. Typically these value sets are specified by the document that defines the metadata element, such as the IEEE Learning Object Metadata or Dublin Core standards. Common Cartridge metadata elements may extend or replace vocabularies with new sets that describe the content included in the package.

For example, the lifeCycle.contributor.role element may be specified to include values from the following set:

•        student

•        instructor

•        administrator

which might be expanded to include:

•        designer

•        reviewer

Where metadata vocabularies are extended or replaced for use in Common Cartridge descriptions, an 1EdTech Vocabulary Definition and Exchange (VDEX) document is required to define the new or extend vocabulary. See /vdex/index.html for information on the 1EdTech VDEX v1.0 specification [VDEX, 04].

Common Cartridge vocabularies are fixed and may not be replaced, extended, or modified.

4.14 UML Diagrams

A complete set of UML diagrams for QTI are available for review in the 1EdTech CC Alliance. These diagrams are large and are easier to study as separate files that can be magnified as needed.  As such, they are no longer reproduced in the printed specification.

 

5                  Implementation Guidelines and Best Practices

5.1      General Best Practices

A convention could be utilized based on some form of UID to prevent collisions with user generated web content folder names. Additionally, a subdirectory may be created to contain all Learning Application Object directories to further reduce the risk of collisions between Learning Application Object directories and those in the web content.

5.1.1           Extensions to Resources Metadata

Compliant systems must at least tolerate any structure attached to extension points.

5.1.2           Accessibility

Extensions for accessibility supported in Content Packaging v1.2 have been incorporated into the schema for Common Cartridge v1.2. However, whilst these extensions are provided for use by those wishing to provide accessibility features, their use and implementation is not mandated for general use and they will not be addressed in any conformance tests developed.

For guidance on use of the accessibility extensions, see the Content Packaging v1.2 specification [CP, 07].

5.1.3           Metadata Rights Management

Copyright of a cartridge is defined as follows:

<rights>
<copyrightAndOtherRestrictions>
<value>yes</value>
</copyrightAndOtherRestrictions>
<description>
<string> 2006-2007 1EdTech Consortium Inc.</string>
</description>
</rights>

 

5.1.4           XML Descriptor Files

1EdTech recommends that all XML files be written using an XML editor.  This will help ensure that the content of descriptor files is XML in proper form and will allow parsers to processes these files correctly. 

1EdTech also recommends that XML file content use encoding for reserved characters such as ‘>’, ‘<’, ‘&’, ‘%’, etc.

5.1.5           Filenames

1EdTech recommends that filenames not contain spaces, although some systems allow this.  Similarly, 1EdTech recommends that all filename references use either all lowercase or all uppercase and consistently.

5.2      Examples of Valid Common Cartridge File Structures

5.2.1           Sample 1 – Web Content and Learning Application Objects Both in Root

0001<root>

0002           Imsmanifest.xml

0003           --------------------

Resource 0001 (Web Content Resource)

0004           Page001.htm

0005           Images\

0006                  Image0001.gif

Resource 0002 (Web Content Resource)

0007           Media\

0008                  Audio001.mp3

0009           ---------------------

0010           LO001\

Resource 0003 (Discussion Forum Resource)

0011                  Welcome.forum

Resource 0004 (Associated Content Resource for Resource 0003)

0012                  Welcome.gif

0013                  Attachments\

0014                        Gettingstarted.doc

0015           LO002\

Resource 0005 (QTI Assessment Resource)

0016                  Studymate.qti

0017           LO003\

Resource 0006 (QTI Assessment Resource)

0018                  Quiz1.qti

Resource 0007 (Associated Content Resource for Resource 0006)

0019                  Sample.doc                   

0020                  Images\

0021                        Ques001.gif

0022                        Ques002_a.gif

 

 

Legend

 

 

 

Web Content Resource

 

 

 

Learning Application Object

 

 

 

Associated Content Resource

 

 

-----

Empty Line

 

5.2.2           Sample 2 – Web Content in Root and Learning Application Objects in Subdirectory

0001     <root>

0002           Imsmanifest.xml

0003           --------------------

Resource 0001 (Web Content Resource)

0004           Page001.htm

0005           Images\

0006                  Image0001.gif

Resource 0002 (Web Content Resource)

0007           Media\

0008                  Audio001.mp3

0009           Data

0010           LO001\

Resource 0003 (Discussion Forum Resource)

0011                  Welcome.forum

Resource 0004 (Associated Content Resource for Resource 0003)

0012                        Welcome.gif

0013                        Attachments\

0014                              Gettingstarted.doc

0015           LO002\

Resource 0005 (QTI Assessment Resource)

0016                  Studymate.qti

0017           LO003\

Resource 0006 (QTI Assessment Resource)

0018                  Quiz1.qti

Resource 0007 (Associated Content Resource for Resource 0006)

0019                  Sample.doc

0020                  Images\

0021                        Ques001.gif

0022                        Ques002_a.gif

 

 

 

Legend

 

 

 

Web Content Resource

 

 

 

Learning Application Object

 

 

 

Associated Content Resource

 

 

-----

Empty Line

 

5.2.3           Sample 3 – Web Content and Learning Application Objects Both in Subdirectories

0001     <root>

0002           Imsmanifest.xml

0003           Content

Resource 0001 (Web Content Resource)

0004           Page001.htm

0005           Images\

0006                  Image0001.gif

Resource 0002 (Web Content Resource)

0007           Media\

0008                  Audio001.mp3

0009           LO001\

Resource 0003 (Discussion Forum Resource)

0010                  Welcome.forum

Resource 0004 (Associated Content Resource for Resource 0003)

0011                  Welcome.gif

0012                  Attachments\

0013                        Gettingstarted.doc

0014           LO002\

Resource 0005 (QTI Resource)

0015                  Studymate.qti

0016           LO003\

Resource 0006 (QTI Assessment Resource)

0017                  Quiz1.qti

Resource 0007 (Associated Content Resource for Resource 0006)

0018                  Sample.doc

0019                  Images\

0020                        Ques001.gif

0021                        Ques002_a.gif

 

 

Legend

 

 

 

Web Content Resource

 

 

 

Learning Application Object

 

 

 

Associated Content Resource

 

 

-----

Empty Line

 

5.2.4           Relative Paths

The following table illustrates all valid relative file reference scenarios for each resource

5.2.4.1      Valid Relative File References

Resource

Valid Relative References

Resource 0001

Resource 0001, Resource 0002

Resource 0002

Resource 0001, Resource 0002

Resource 0003

Resource 0001, Resource 0002, Resource 0004

Resource 0004

Resource 0001, Resource 0002, Resource 0004

Resource 0005

Resource 0001, Resource 0002

Resource 0006

Resource 0001, Resource 0002, Resource 0007

Resource 0007

Resource 0001, Resource 0002, Resource 0007

 

The following three tables illustrate the required relative path to access another file in the root directory of another resourceAn X in a box indicates that a relative reference to files in that resource are not allowed.

5.2.4.2      Relative Paths for Sample 1

Table 5.1 Relative path to file in root of resource#.

Resource

0001

0002

0003

0004

0005

0006

0007

0001

./

./

X

X

X

X

X

0002

./

./

X

X

X

X

X

0003

../

../

X

./

X

X

X

0004

../

../

X

./

X

X

X

0005

../

../

X

X

X

X

X

0006

../

../

X

X

X

X

X

0007

../

../

X

X

X

./

./

 

 

5.2.4.3      Relative Paths for Sample 2

Table 5.2 Relative path to file in root of resource#.

Resource

0001

0002

0003

0004

0005

0006

0007

0001

./

./

X

X

X

X

X

0002

./

./

X

X

X

X

X

0003

../../

../

X

./

X

X

X

0004

../../

../../

X

./

X

X

X

0005

../../

../../

X

X

X

X

X

0006

../../

../../

X

X

X

X

X

0007

../../

../../

X

X

X

./

./

 

5.2.4.4      Relative Paths for Sample 3

Table 5.3 Relative path to file in root of resource#.

Resource

0001

0002

0003

0004

0005

0006

0007

0001

./

./

X

X

X

X

X

0002

./

./

X

X

X

X

X

0003

../../content/

../../content/

X

./

X

X

X

0004

../../content/

../../content/

X

./

X

X

X

0005

../../content/

../../content/

X

X

X

X

X

0006

../../content/

../../content/

X

X

X

X

X

0007

../../content/

../../content/

X

X

X

./

./

 

5.3      Content & Assessment Issues

5.3.1           Course Essentials

Provide comprehensive information about the course and its content, including, but not limited to:

•        Full book title (including edition). If there is no corresponding book, provide the course title.

•        Author(s)

•        ISBN

•        Publisher/Imprint/Business Unit/Discipline.

•        Appropriate contact information, including editorial/author/support (email, phone number, etc.).

•        Full URLs of any associated websites, along with appropriate access information if protected.

•        A list of any special plug-ins or enabling technologies required for satisfactory use.

•        Whenever possible, develop content for the broadest base of browser versions and operating systems in current use. Keep in mind that not everyone has the latest and greatest.

•        Provide details for content (file types, how it is presented, etc.)

•        Provide appropriate copyright information, including any restrictions on the content’s use.

5.3.2           Course Design

5.3.2.1       Keep it Simple!

Specialized coding, such as custom JavaScript modules, may work beautifully in one LMS/CMS environment, but may not work at all in another. Avoid it.

Use consistent file naming, with shorter file names wherever possible.

Avoid the use of glyphs, such as curly or typographer's quotation marks, which may not render properly in some platforms. Unfortunately, curly quotes is a default setting in MS Word. When this feature is active, straight quotation marks are automatically changed to curly quotes while typing. Disable it when authoring content for the Common Cartridge.

5.3.2.2       Keep it Small!

Always keep course size in mind when designing and building a course. If any modules or features are repeated throughout the course, place them in a section that can hold these common elements. Doing this can dramatically cut down on the size of the cartridge. Optimally, a course should not be larger than 100 MB. Better yet, whenever possible, put larger, commonly-used files on a server, external to the course, and link to them there.

5.3.2.3       Use External Servers for Large and Commonly Used Files

Large files (such as PPT, Word/Excel, PDFs, movies and other media) generally should not be included within a course. Anything loaded within the course will tend to enlarge the course size and this will increase the time to download a course. When multiple instances of a course are installed on a server to support multiple sections, significant server space may be needlessly consumed with redundant content. Content stored on external servers will need to be made available to course users, though. For publishers, this will likely mean hosting content on a server that is globally accessible from the Internet. For a locally-produced university course, this may mean hosting content on a server accessible by the intended users – wherever they are, inside or outside of the university firewall.

5.3.2.4       Avoid “Platform-Specific” Language/Icons

Sometimes "platform-specific" language appears in assessments and or other pages of a course. This could be anything from instructions on how to submit a quiz for grading to module-specific information. Avoid such platform-specific language and/or icons in your course content.

5.3.2.5       Plan for Change

An instructor can alter the look/feel of a course within minutes of installing it on a server, so the design of course material should be kept clean and simple. Provide a simple yet professional banner and icon set for the course content. It may be possible to use a generic set of icons for all courses.

5.3.2.6       Make it Compatible

Some platforms support multiple correct answers, while others may not. Some CMS support tutorial mode – where questions are presented one at a time – while others may not. Some systems may re-order questions. Some systems may support feedback, but that feedback is generally for right or wrong answers and rarely support individualized feedback for each specific answer. Develop questions that will work on all platforms.

Develop assessments that the Common Cartridge currently supports:

•        Multiple choice, single response

•        Multiple choice, multiple response

•        True/false

•        Essay

•        Fill-in-the-blank

•        Pattern match (optional)

See the Common Cartridge specifications for more information about the individual question types.

An assessment may include a reading, image, hyperlink to another website, or a set of instructions at the top of the quiz that are needed for the student to answer the questions. Decide how to handle these questions. The information can be included in each question, or the question can include a link to it.

Try to keep the quizzes in a course to a reasonable number. Otherwise, an instructor may encounter problems when using the course gradebook.

5.3.2.7       Check it

Proofread and QA the course content against the original source materials, ensure that all course elements function properly, and all external resources are appropriately available.

 

About This Document

 

Title:                                                      1EdTech Common Cartridge Profile: Implementation

Editor:                                                  Lisa Mattson (1EdTech)

Version:                                                1.3

Version Date:                                      30 May 2014

Status:                                                   Final Specification

Summary:                                            This document contains the profile information for Common Cartridge, an open format for the distribution of rich, web-based content.

Purpose:                                               This document has been approved by the 1EdTech Common Cartridge Accredited Profile Management Group and is made available for pubic adoption.

Document Location:                          /cc/

 

 

 

List of Contributors

The following individuals contributed to the development of this document:

Name

Organization

Thor Anderson

Utah Valley University

David Gappa

Safari Montage

Jeff Kahn

1EdTech Consortium

Lisa Mattson

1EdTech Consortium

Bracken Mosbacker

Instructure

Bill Richardson

Blackboard Inc.

Colin Smythe

1EdTech Consortium

Claude Vervoort

Cengage

Jennifer Whiting

Florida Virtual School

 

 

 

Revision History

 

Version No.

Release Date

Comments

Final v1.0

29 January 2009

The first formal release of the CC specification.

Public Draft v1.1

9 November 2010

The Public Draft of the CC v1.1 specification.

Revised Draft v1.1

6 December 2010

Revised Public Draft of the CC v1.1 specification.

Revised Draft v1.1

24 December 2010

Folded in architecture content and removed conformance.

Final v1.1

18 April 2011

The Final CC v1.1 specification.

Correction made to the path locations of the schema files.

Final v1.2

1 October 2011

The Final CC v1.2 specification.

Final v1.3

15 July 2013

The Final CC v1.3 specification.

Final v1.3 update

30 May 2014

Errant section 4.6.1.1 on LOM metadata was removed.

 

 

 

 

 

1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this 1EdTech Common Cartridge Profile: Implementation ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech 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.
1EdTech would appreciate receiving your comments and suggestions.
Please contact 1EdTech through our website at /
Please refer to Document Name: 1EdTech Common Cartridge Profile: Implementation  
Date: 30 May 2014



[1] a. NB: The files listed in the associated content resource must be in the same directory as the learning application resource file or a subordinate director