1EdTech GLC Common Cartridge Profile: Implementation
Version 1.1 Final Specification
Date Issued: 10 January 2011
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: /imsipr_policyFinal.pdf.
Copyright © 2008-2011 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.
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 interoperability across platforms. The approach followed has centered on;
1) eliminating implementation options from the adopted base schemas;
2) removing unwanted extensibility;
3) focusing on commonly used features and eliminating those rarely used;
4) 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.1. Refer to Section 1.2 for titles of other documents which address overview material and what is different from v1.0, 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 Technology
Simplifications applied to the Common Cartridge format include:
• Meta-data is only mandated at the cartridge level by the CC profile (located in the root folder). Optionally, roles meta-data 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 meta-data only uses the 15 elements from DCMI v1.1 (Simple DC)
• Assessments have been simplified to just the six (6) most commonly used QTI question types:
• Multiple choice (single response)
• Multiple choice (multiple response)
• True/false
• Essay
• Simple fill in the blank
• Pattern match (optional)
However, the format has also been enriched with the addition of:
• Cartridge support for authorization data (also see the Authorization Web Service specification [CC, 08b]). Note: authorization support, as specified for Common Cartridge, does not represent a complete and coherent approach. Authorization in this context should be adopted with care and may best be left unimplemented until a future version of Common Cartridge addresses existing concerns.
• Addition of discussion forum initialization
• Addition of Basic Learning Tools Interoperability
1EdTech is developing Learning Tools Interoperability (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.
Basic 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. Basic 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 GLC Learning Tools Interoperability Basic LTI Implementation Guide for more specifics.
1.2 References
[AP, 05] 1EdTech Application Profile Guidelines, v1.0, 1EdTech GLC, October, 2005.
[BLTI, 10] 1EdTech Basic Learning Tools Interoperability (BLTI) v1.0, 1EdTech GLC, May, 2010.
[CC, 08b] 1EdTech Common Cartridge (CC) Authorization Web Service v1.0, 1EdTech GLC, October, 2008.
[CC,11a] 1EdTech Common Cartridge Profile: Overview v1.1, 1EdTech GLC, January 2011.
[CC,11b] 1EdTech Common Cartridge Profile: Use Cases v1.1, 1EdTech GLC, January 2011.
[CC,11c] 1EdTech Common Cartridge Profile: Conformance v1.1, 1EdTech GLC, January 2011.
[CC,11d] 1EdTech Common Cartridge Profile: Appendices v1.1, 1EdTech GLC, January 2011.
[CP, 07] 1EdTech Content Packaging (CP) v1.2, 1EdTech GLC, 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 GLC, March, 2003.
1.3 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. |
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. |
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. |
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 Basic LTI is part of Common Cartridge v1.1 and the package should have the extension “imscc”.
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 or syllabus. 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.1 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 – Basic Learning Tools Interoperability |
A Basic 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 Meta-data |
This is 1EdTech CC Package level specific meta-data that may include different elements covering licensing, accessibility, description, etc. |
Resource - Question Bank |
A question bank represents an instance of a QTI objectbank. Only one question bank can optionally be included in a cartridge. It can embed any of the question types supported by the CC v1.1 profile of QTI. Questions within a question bank cannot be referenced by any assessments contained in the cartridge. |
Common Cartridge v1.1 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’ and regular expressions. Note that support for pattern match is optional in those learning platforms that do not provide this type of question natively.
• Essay
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 Meta-data.
• 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;
§ BasicLTI – 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 meta-data 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. E.g. authorization or Basic LTI.
• Descriptive Meta-data. 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 meta-data) 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 1 |
Authorizations Data |
0 or 1 |
Discussion Topic |
0 or more. |
Web Links |
0 or more |
Basic LTI |
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.
Figure 4.3 CC profile of CP v1.2 – Organizations.
Figure 4.4 CC profile of CP v1.2 – Resource Types.
4.4 Content Packaging
4.4.1 Overview
The Common Cartridge builds upon a profile of Content Packaging. This profile is constructed using the CPv1.2 schema, but currently only harnesses those features previously available in CPv1.1.4. The following provides an overview of the basic usage of 1EdTech Content Packaging
4.4.1.1 Manifests
• In the Common Cartridge profile, all content will be captured in a single 1EdTech manifest. Children will not be used.
4.4.1.2 Meta-data
• LOM Metadata (restricted to DC elements for the cartridge level meta-data) will be used to capture meta-data.
4.4.1.3 Organization
• The Organization will be used to represent the Common Cartridge Folder content type. See the discussion on representing the Common Cartridge Folder Type for the additional profiling applied to this data.
4.4.1.4 Resources
• In general, all additional data required to describe a piece of content which is included in the cartridge, will be included as a separate file and referenced from a Resource object
• The Resource Type characteristic object will be used to identify the type of the external data. New resource types will be defined for each type of content included in the scope of CC. The format of these types should follow the guidelines defined in [CP, 07].
• Where a particular content instance requires multiple resource files of different types to describe itself, these should be included as separate resource elements with a <dependency> element linking them. Resources of different types should not be bundled together under a single <resource> element. E.g., the image files required by a QTI resource should not be directly referenced as <file> elements under the resource of type ‘imsqti_xmlv1p2/imscc_xmlv1p1/assessment’. They should be included under a separate web content resource element.
• The specifics of using the Resource object to represent different types of learning content are described below.
4.4.2 Manifest
• Manifest object may not contain child Manifest objects.
• The version characteristic object (i.e.,. version=‘1EdTech CP 1.2’) for the Manifest is prohibited in the Common Cartridge profile to avoid confusion with the Common Cartridge version number, which by implication, uniquely identifies the version of Content Packaging adopted.
4.4.3 Folder Content Type
• The folder content type described by the CC requirements represents a structural/presentation based approach to organizing content.
• The folder does not imply containment in the sense that a Windows file system folder implies containment (i.e., you delete the folder, you delete everything it contains).
• You cannot use the folder name within file path based semantics to reference content referenced by the folder.
• A distinct Learning Application Object can be referenced multiple times (both within a single folder and across folders). If a particular tool cannot support this multiple referencing it may choose to make a copy of the Learning Application Object.
The following describes how the folder content type is represented.
4.4.3.1 Usage of Organizations object
• The folder content type is represented by the 1EdTech Organizations container object type. A Common Cartridge may have a single Organization or no Organization.
• The Default characteristic of the Organizations object is prohibited as it has no meaning in Common Cartridge.
4.4.3.2 Usage of Organization object
• A Common Cartridge may have a single Organization or no Organization.
• The Organization object must contain a Structure characteristic object with the value “rooted-hierarchy”.
• An Organization object may contain a Title value object. This can be used at the discretion of the tool taking into account how the tool renders the organization. For example, if the tool renders the organization as a Learning Module then the Title of the organization could be used as the title of the module. If the tool renders the organization as a set of folders below the existing course, then the Title would probably not be used.
<organizations/>
Or
<organizations>
<organization identifier=”Org1” structure=”rooted-hierarchy”>
<title>Mathematics Volume III</title>
<item>… </item>
</organization>
</organizations>
4.4.3.3 Root Folder
A cartridge with a folder Organization should always be rooted on a single Item container object. It is not permissible to have two sibling Item containers below the Organization. The root Item container object just represents the root node of the Organization tree and has no other semantic or presentational meaning. It must not contain a Title value object, e.g., the following is valid:
<organization identifier=”Org1” structure=”rooted-hierarchy”>
<item>
<item>
…
</item>
</item>
</organization>
The following are not valid:
<organization>
<item>
…
</item>
<item>
…
</item>
</organization>
<organization>
<item>
<title>some text</title>
</item>
</organization>
4.4.3.4 Usage of Items
• An Item container object type either represents a folder or a link to a Learning Application Object resource from a folder.
• Parameters characteristic object of Item is not supported by CC.
• Every Item object with the exception of the root Item must contain a Title object.
4.4.3.5 Item Object Representing Folder
• An Item object which represents a folder is indicated by the absence of an IdentifierRef characteristic object.
• Folder Items support unlimited nesting of other folder Items and Learning Application Object link Items.
<item>
<item>
<title>Root folder</title>
<item>
<title>Subfolder 1</title>
</item>
<item>
<title>Subfolder 2</title>
<item>
<title>Subfolder 2 – Sub Folder 1</title>
</item>
</item>
</item>
</item>
4.4.3.6 Item Object representing Learning Application Object Link
• An Item object representing a link to a Learning Application Object must contain an IdentifierRef characteristic object which references the Resource object describing the linked content.
• Learning Application Object Item objects may be nested by folder Item object but may not nest other folder or Learning Application Object Item objects.
• It is valid for two Learning Application Object Item objects to reference the same Resource object. This is consistent with the idea of the folder references equating to usage rather than containment links.
4.4.4 Sample Manifest
<?xml version="1.0" encoding="UTF-8"?>
<manifest identifier="cctd0001"
xmlns="/xsd/imsccv1p1/imscp_v1p1"
xmlns:lom="http://ltsc.ieee.org/xsd/imsccv1p1/LOM/resource"
xmlns:lomimscc="http://ltsc.ieee.org/xsd/imsccv1p1/LOM/manifest"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
/xsd/imsccv1p1/imscp_v1p1 /profile/cc/ccv1p1/ccv1p1_imscp_v1p1_v1p0.xsd
http://ltsc.ieee.org/xsd/imsccv1p1/LOM/resource /profile/cc/ccv1p1/LOM/ccv1p1_lomresource_v1p0.xsd
http://ltsc.ieee.org/xsd/imsccv1p1/LOM/manifest /profile/cc/ccv1p1/LOM/ccv1p1_lommanifest_v1p0.xsd" >
<metadata>
<schema>1EdTech Common Cartridge</schema>
<schemaversion>1.1.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_xmlv1p2/imscc_xmlv1p1/assessment" >
<file href="I_00003_R/assessment.xml"/>
</resource>
<resourceidentifier="I_00004_R" type="imsqti_xmlv1p2/imscc_xmlv1p1/question-bank" >
<metadata>
<lom:lom>
<lom:educational>
<lom:intendedEndUserRole>
<lom:source>IMSGLC_CC_Rolesv1p1 </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_xmlv1p1">
<file href="I_00005_R/weblink1.xml"/>
</resource>
<resourceidentifier="I_00006_R" type="imsdt_xmlv1p1">
<file href="I_00006_R/discussion.xml"/>
<dependencyidentifierref="I_00006_Media"/>
<dependencyidentifierref="I_media_R"/>
</resource>
<resourceidentifier="I_00006_Media" type="associatedcontent/imscc_xmlv1p1/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” ‘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.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_xmlv1p1/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_xmlv1p1’.
• 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/imsccv1p1/imsdt_v1p1 schema (see below).
• The Resource object may contain Dependency objects which reference Resource objects with Type ‘webcontent’ and/or ‘associatedcontent/imscc_xmlv1p1/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_xmlv1p1’.
• 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/imsccv1p1/imswl_v1p1 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_xmlv1p2/imscc_xmlv1p1/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_xmlv1p1/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.
• Only one question bank 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_xmlv1p1/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_xmlv1p1/learning-application-resource’.
4.4.11 Common Cartridge Authorization
• Cartridges support authorization at two levels: either the whole cartridge can be protected or individual resources can be protected.
• Authorization information is specified at two levels within the cartridge information model.
• The overall authorization requirements are specified using the Authorizations object which is an extension to the Manifest object. If the authorizations object is not present, no authorization is required. If the authorizations object is present it must declare Common Cartridge Authorization first, possibly in addition to other authorization mechanisms.
• If authorization is applied to individual resources within the cartridge rather than the cartridge as a whole, this can be specified using the Protected characteristic, which is an extension characteristic applied to the Resource object.
• Import authorization is only applicable at the cartridge level.
• If import authorization is specified and it is not granted, then no part of the cartridge should be imported, including resources and files.
• Access authorization only applies to resources contained within a package.
• If access authorization is specified at the cartridge level it cascades down to the resources but not to any files contained within those resources.
• If access authorization is specified for a resource, it covers only access to the resource itself but does not cover access to files contained within the resource.
• When access authorization is specified for a resource, all non-management access points to that resource within a system need to check that authorization.
• Management of resources after a cartridge has been imported is beyond the scope of this authorization scheme, the authorization only applies to accessing the resource in the cartridge player.
• See below for further definition of the Authorization object information model.
• The Resource object may contain Dependency objects which reference Resource objects with Type ‘webcontent’ and/or ‘webcontent/imscc_xmlv1p1/learning-application-resource’.
4.4.12 Basic Learning Tools Interoperability (BLTI) Content Type
• A Basic LTI Link is a Learning Application Object that represents a self-contained LTI link.
• BLTI 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 BLTI Link descriptor XML file which conforms to the /xsd/imsbasiclti_v1p0 schema (see below).
• The Resource object must not contain Dependency child objects.
4.5 LOM Metadata
4.5.1 Cartridge Metadata
The Common Cartridge must be described at the manifest level using meta-data 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/imsccv1p1/LOM/manifest which differs from the IEEE LOM namespace by the insertion of imscc. In contrast, meta-data for resources (see below) need to use the original IEEE LOM namespace.
The meta-data 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.1.0</schemaversion>
… metadata according to Common Cartridge profile of IEEE LOM …
</metadata>
The usage of meta-data 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 meta-data 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.5.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 |
4.5.1.2 A Number of Elements of IEEE LOM are Unused and are Therefore Prohibited:
• No custom elements are allowed
• interactivityType unused
• interactivityLevel unused
• semanticDensity unused
• intendedEndUserRole unused
• typicalAgeRange unused
• difficulty unused
• typicalLearningTime unused
• description is unused in educational context
• language is unused in technical context, it is used only in general context
• structure is not used
• aggregationlevel is not used
• version is not used
• status is not used
• metaMetadata are not used
• annotation is not used
• No size information
• location not used
• requirements not used
• installationRemarks unused
• otherPlatformRequirements unused
• duration unused
4.5.2 Roles Meta-data
If meta-data 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/imsccv1p1/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” meta-data 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_Rolesv1p1
|
Learner |
Instructor |
Mentor |
CC version 1.0 |
? |
? |
|
CC version 1.1 |
? |
? |
? |
For example:
<lom:lom>
<lom:educational>
<lom:intendedEndUserRole>
<lom:source>IMSGLC_CC_Rolesv1p1</lom:source>
<lom:value>Learner</lom:value>
</lom:intendedEndUserRole>
<lom:intendedEndUserRole>
<lom:source>IMSGLC_CC_Rolesv1p1</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 Authorization
Note: Authorization support, as specified for Common Cartridge, does not represent a complete and coherent approach. Authorization in this context should be adopted with care and may best be left unimplemented until a future version of Common Cartridge addresses existing concerns.
The authorization components of the Common Cartridge are designed to support the requirements of the Authorization Web Service as described in 1EdTech Common Cartridge Authorization Web Service [CC, 08b].
However, they also need to contain sufficient information to support legacy authorization mechanisms as it is not expected that all tools and publishers will immediately move to using the Web Service, because their current business model is tied to the existing mechanisms.
The authorization model supports the following concepts:
1) Requiring authorization on cartridge import
2) Requiring authorization on cartridge usage
3) Requiring authorization on usage of specific resources in the cartridge
Concepts 2 and 3 are mutually exclusive, i.e., a cartridge can either specify that all resources in the cartridge are protected or just some resources in the cartridge are protected.
The mechanism by which the authorized access to particular resources is enforced by the tool is not defined by the profile. How the ‘challenge’ mechanism is integrated into the user experience will be determined by the implementation of the tool. For example, a tool could challenge for authorization when a user accesses a course that contains any protected resources. Or alternatively, a tool could just challenge when a user tries to access a protected resource in the context of a course. In some cases this is not easy to do. E.g., if an HTML page uses a protected image, it may not be easy to incorporate a challenge mechanism seamlessly into the display of the HTML page. A tool could employ some kind of redirection mechanism or return an image requesting the user to authorize etc.
4.6.1 Example Instance
<manifest>
<metadata/>
<organization/>
<resources/>
<cc:authorizations access="cartridge" import="false"
xmlns:cc="/xsd/imsccauth_v1p0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="/xsd/imsccauth_v1p0 imsccauth_v1p0.xsd">
<cc:authorization>
<cartridgeId>12345</cartridgeId>
<webservice>http://publisher.com/authme</webservice>
</cc:authorization>
</cc:authorizations>
</manifest>
• authorization - If not provided means cartridge usage requires no authorization.
• access - Determines whether authorization must be established when cartridge content is accessed by a learner. Valid values are ‘cartridge’ which means all cartridge resources are protected or ‘resource’ which means only resources which are specifically flagged as protected require authorization.
• import - Determines whether authorization must be established when cartridge is imported into a tool
• cartridgeId - Global unique identifier for this cartridge
• webservice - The address of the web service that supports the 1EdTech Common Cartridge Authorization Web Service [CC, 08b]. If authorization is required, then this element must be present and reference a valid authorization web service.
4.6.2 Protecting Individual Resources
If the cartridge access type is set to ‘resource’ then the individual resources which need to be protected are specified by adding the ‘Protected’ characteristic object to each resource.
<resource identifier=res001 type=webcontent cc:protected=true href=someFile.html>
<file href=someFile.html/>
</resource>
4.6.3 Schema
<xs:schema targetNamespace="/xsd/imsccauth_v1p0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="/xsd/imsccauth_v1p0"
xmlns:ims="/xsd/imscp_v1p1" elementFormDefault="unqualified">
<xs:import namespace="/xsd/imscp_v1p1" schemaLocation = "imscp_v1p1.xsd"/>
<xs:element name="authorizations" type="authorizationsType"/>
<xs:complexType name="authorizationsType">
<xs:sequence>
<xs:element name="authorization" type="authorizationType"/>
<xs:group ref = "ims:grp.any"/>
</xs:sequence>
<xs:attribute name="access" type="accessType" use="required"/>
<xs:attribute name="import" type="xs:boolean" default="false"/>
</xs:complexType>
<xs:complexType name="authorizationType">
<xs:sequence>
<xs:element name="cartridgeId" type="xs:string"/>
<xs:element name="webservice" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="accessType">
<xs:restriction base="xs:string">
<xs:enumeration value="cartridge"/>
<xs:enumeration value="resource"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="ResourceType">
<xs:complexContent>
<xs:extension base="ims:resourceType">
<xs:attribute name="protected" type="xs:boolean" default="false"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
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/imsccv1p1/imsdt_v1p1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="/xsd/imsccv1p1/imsdt_v1p1
/profile/cc/ccv1p1/ccv1p1_imsdt_v1p1.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? <br/> <img src="$1EdTech-CC-FILEBASE$../I_media_R/smiling_dog.jpg"/></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/imsccv1p1/imsdt_v1p1" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns=" /xsd/imsccv1p1/imsdt_v1p1 /profile/cc/ccv1p1/ccv1p1_imsdt_v1p1.xsd" elementFormDefault="unqualified">
<xs:element name="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/imsccv1p1/imswl_v1p1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
/xsd/imsccv1p1/imswl_v1p1
/profile/cc/ccv1p1/ccv1p1_imswl_v1p1.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
<?xml version="1.0"?>
<xs:schema targetNamespace="/xsd/imsccv1p1/imswl_v1p1" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns=" /xsd/imsccv1p1/imswl_v1p1
/profile/cc/ccv1p1/ccv1p1_imswl_v1p1.xsd" elementFormDefault="unqualified">
<xs:element name="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 Basic Learning Tools Interoperability
A Basic LTI link is a simplified and self-contained LTI link. The Basic LTI link is defined in the resource section of an 1EdTech Common Cartridge as follows:
<resource identifier="I_00010_R" type="imsbasiclti_xmlv1p0">
<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 Basic 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/ltiv1p0/imslticc_v1p0.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 basiclti launch URL</blti:launch_url>
<blti:secure_launch_url>secure url to the basiclti 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 Basic 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 Basic 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 Basic 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 Basic LTI resource entry in the manifest as shown below:
<resource identifier="I_00010_R" type="imsbasiclti_xmlv1p0">
<file href="I_00001_R/BasicLTI.xml"/>
<dependency identifierref="BLTI001_Icon"/>
</resource>
<resource identifier="BLTI001_Icon"
type="associatedcontent/imscc_xmlv1p1/learning-application-resource">
<file href="BLTI001_Media/learning_icon.gif"/>
</resource>
4.10 QTI
4.10.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 meta-data 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 and if used, only one question bank can be present in a cartridge.
<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.10.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 meta-data 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. Only one object bank can be included in a cartridge.
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.10.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: (question type, weight… )
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.10.4 Itemmetadata
An <itemmetadata> element can contain a <qtimetadata> element where CC specific meta-data elements are allowed within <qtimetadatafield> structures (as in Assessments vs. Object Banks section above) as follows:
fieldlabel |
fieldentry |
cc_profile |
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 meta-data to indicate the item is manually scored.) |
qmd_computerscored |
The computerscored for essay must be No. |
4.10.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.10.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.10.7 Feedback
4.10.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.10.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.10.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.10.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>
<setvar action="Set" varname="SCORE">100</setvar>
<displayfeedbackfeedbacktype=" Response" linkrefid=" correct_fb"/>
</respcondition>
The ident for the general correct feedback should be: correct_fb.
4.10.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.10.8 Hints
Hints are not profiled and therefore it is recommended not to include them in Items.
4.10.9 LID based Question Types: True/False, Multiple Choice and Multiple Response
4.10.9.1 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.10.9.2 Response Processing: Multiple Choice
The <conditionvar> is made of a single <varequal> element checking if the correct identifier was selected.
<respcondition continue="No">
<conditionvar>
<varequal respident="response_1">answer_4</varequal>
</conditionvar>
<setvar action="Set" varname="SCORE">100</setvar>
<displayfeedback feedbacktype="Response" linkrefid="correct_fb"/>
</respcondition>
4.10.9.3 Response Processing: True-False
True False uses the same <respcondition> than Multiple Choice questions.
4.10.9.4 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>
<setvar action="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>.
No nesting is allowed, a <not> should only contain a <varequal>.
4.10.9.5 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.10.10 FIB based questions: Fill-in-the-Blank and Pattern Matching
4.10.10.1 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.10.10.2 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.10.10.3 Response Processing: Pattern Match
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 we use the varsubstring condition, as follows:
<conditionvar>
<varsubstring respident="response_1" case="No">expected</varsubstring>
</conditionvar>
4.10.11 Essay Question
4.10.11.1 Presentation
Presentation is using the same construct as FIB question types.
4.10.11.2 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.10.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.11 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 meta-data 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 meta-data attributes which can carry additional delivery information about the assessment such as maximum attempts and time limit. These are defined in the profile.
4.11.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 all questions types other than Pattern Match are required for compliance. If the Pattern Match question type is supported natively in a product, it must be accommodate in a Common Cartridge; if the type is not supported natively, it can be omitted or unhandled in a Common Cartridge gracefully.
The profiles for each of these question types describe how they support:
• feedback
• sample solutions
• relative scoring
In addition, questions support a number of meta-data 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.11.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.
The behavior of an tool in handling question banks is undefined.
4.12 Vocabularies
Vocabularies refer to a set of string constants used to specify pre-defined values for meta-data elements. Typically these value sets are specified by the document that defines the meta-data element, such as the IEEE Learning Object Metadata or Dublin Core standards. Common Cartridge meta-data 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 meta-data 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-1.0 specification.
Common Cartridge vocabularies are fixed and may not be replaced, extended, or modified.
4.13 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 Meta-data
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.1. 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 Meta-data 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 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
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
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
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.
5.4 Future Development
The 1EdTech Content Packaging specification v1.2 is to be augmented with guidance on how to namespace in accessibility meta-data. It is intended that CC practice will follow the same approach, hence users wishing to implement support for accessibility should follow the CPv1.2 guidance.
The 1EdTech CC K12 group is currently compiling recommendations for additional features for CC required by the K12 community. These will be considered for inclusion in the next and subsequent releases of CC.
Another area of activity is support for Learning Standards annotation of resources using meta-data.
About This Document
Title: 1EdTech GLC Common Cartridge Profile: Implementation
Editor: Jeff Kahn (1EdTech GLC)
Version: 1.1
Version Date: 10 January 2011
Status: Final
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/ccv1p1/imscc_profilev1p1-Implementation.html
List of Contributors
The following individuals contributed to the development of this document:
Name |
Organization |
Thor Anderson |
Utah Valley University |
Brent Bailey |
Elsevier |
Warwick Bailey |
Icodeon |
Jeff Bradley |
Blackboard Inc. |
Ingo Dahn |
University of Koblenz-Landau |
Jeff Kahn (editor) |
1EdTech Consortium |
Lisa Mattson |
1EdTech Consortium |
Chris Moffatt |
Microsoft Inc. |
Mark O’Neil |
Blackboard Inc. |
Colin Smythe |
1EdTech Consortium |
Erik Unhjem |
Pearson Education |
Claude Vervoort |
Blackboard Inc. |
Jennifer Whiting |
Florida Virtual School |
Yong-Sang Cho |
KERIS |
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. |
|
|
|
1EdTech Consortium, Inc. ("1EdTech GLC") is publishing the information contained in this 1EdTech GLC Common Cartridge Profile: Implementation ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech GLC 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 GLC would appreciate receiving your comments and suggestions.
Please contact 1EdTech GLC through our website at /
Please refer to Document Name: 1EdTech GLC Common Cartridge Profile: Implementation
Revision: 10 January 2011
[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