1EdTech GLC Common Cartridge Profile: Implementation
Version 1.2 Final Specification
Date Issued: 1 October 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: /sites/default/files/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 DOCUMENT IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS DOCUMENT 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 DOCUMENT.
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:
· eliminating implementation options from the adopted base schemas;
· removing unwanted extensibility;
· focusing on commonly used features and eliminating those rarely used;
· further constraining permitted data in supported element (e.g., in terms of type, value ranges, vocabularies).
The resulting Common Cartridge profile should be easier for developers to implement and lends itself to more routine conformance testing of these implementations.
Note that this document is only one of several that form the specification for Common Cartridge v1.2. Refer to Section 1.2 for titles of other documents, which address overview material and what is different from v1.1, use cases, and conformance.
Figure 1.1 Common Cartridge Focus.
• The primary focus of the Common Cartridge specification is achieving error-free import of content into any conforming LMS platform (see Figure 1.1). No runtime model is expressed, but any conforming LMS must support (either directly, or via a call-out to a suitable external service) all of the functionality implied by the Common Cartridge schema set.
1.1 A Note on Conformance and Allowing Exceptions
1EdTech Common Cartridge conformance enables interoperability of the packaging and delivery of content. As the use of Common Cartridge grows in use as a way to facilitate the exchange of educational content, the need to both broaden and narrow the scope of the specification's functionality has arisen. This is why the Common Cartridge Accredited Profile Management Group (CC AMPG) revises the specification to include new features, such as Basic Learning Tools Interoperability in CC v1.1 and Curriculum standards in CC v1.2.
While the specification's original developers decided on what they believed to be a minimum set of criteria that would enable interoperability between systems and content, in actual use the set of criteria needed may be in fact, less than what was described. As more vendors and individuals are seeing the benefit of using Common Cartridge to package and exchange data, new tools are being developed which wish to make use of the Common Cartridge structure, but these tools may not have all the Common Cartridge functionality inherent in their tools.
In 1EdTech, our goal is to enable interoperability and allow the broadest use of our standards while still maintaining the integrity of the specification and the use of 1EdTech standards at the core of tools.
The CC AMPG is responsible for defining the criteria needed to achieve Common Cartridge conformance. Based on requests from vendors, the CC AMPG has revised the requirements for achieving CC v1.2 Conformance.
The table below shows the base features of Common Cartridge v1.2.
Table 1.1 Common Cartridge v1.2 Learning Platforms Allowable Exceptions List
Features |
Details |
Allowed as an exception |
1EdTech Manifest File |
|
No |
Export in Common Cartridge Format |
|
Yes |
Roles Metadata |
Instructor |
No |
|
Student |
No |
|
Mentor |
Yes |
.imscc file name |
|
No |
RESOURCE TYPES |
|
|
Basic LTI Links |
|
Yes |
Web Content |
|
No |
|
intended use attribute |
Yes |
Web Links |
|
No |
Associated Content |
|
No |
Question Types |
|
|
|
1) Multiple-Choice (single Response) |
No |
|
2) Multiple - Choice (multiple Response) |
Yes |
|
3) True/False |
No |
|
4) Essay |
Yes |
|
5) Simple fill in the blank |
No |
|
6) Pattern Match |
Yes |
Discussion Forum |
|
Yes |
Authorization |
|
Yes |
The new approach allows tools that do not inherently support functionality (such as discussion forums) the opportunity to gain Common Cartridge conformance. All systems which do not support a feature of Common Cartridge must fail gracefully and indicate to the user that they do not support the feature. All systems must import cartridges to gain conformance, they may not fail at import regardless of the features contained in the cartridge.
1.2 Technology
Simplifications applied to the Common Cartridge format include:
• Metadata is only mandated at the cartridge level by the CC profile (located in the root folder). Optionally, roles metadata can be applied within the manifest to define which categories of users have access to particular resources.
• Inter-package links are not supported
• Common Cartridge metadata 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) (allowed exception)
• True/false
• Essay (allowed exception)
• Simple fill in the blank
• Pattern match (allowed exception)
However, the format has also been enriched with the addition of:
• 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. Implementers are encouraged to consider 1EdTech Learning Tools Interoperability (LTI) for authenticated access to content.
• Addition of discussion forum initialization
• Addition of Basic LTI
1EdTech is developing LTI to allow remote tools and content to be integrated into a Learning Management System (LMS). Throughout this document, we use specific terminology to describe the two main pieces of software involved in LTI. What we traditionally think of as the "Learning Management System" (LMS) is referred to as the "Tool Consumer" (TC) as it "consumes" the tool. The external tool or content is called the "Tool Provider" (TP) as it "provides" the tool for use in the Tool Consumer. Example Tool Providers might include an externally hosted testing system or a server that contains externally hosted premium content.
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 [BLTI, 10] for more specifics.
1.3 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.2, 1EdTech GLC, October 2011.
[CC,11b] 1EdTech Common Cartridge Profile: Use Cases v1.2, 1EdTech GLC, October 2011.
[CC,11c] 1EdTech Common Cartridge Profile: Conformance v1.2, 1EdTech GLC, October 2011.
[CC,11d] 1EdTech Common Cartridge Profile: Appendices v1.2, 1EdTech GLC, October 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.
[VDEX, 04] 1EdTech Vocabulary Definition Exchange (VDEX) v1.0, 1EdTech GLC, February 2004.
1.4 Definitions
Term |
Definition |
Access Code |
A code used to authorize user access to a protected resource, in this case a Common Cartridge or a discrete component thereof. |
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.2 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, syllabus, or assignment. A learning platform can elect to handle this content with such an intended use in mind.
HTML files may include references to other web content files that are contained within the cartridge or that are external to the cartridge. |
Resource – Web Link |
A Web Link is a Learning Application Object representation of a standard HTTP link. It extends a standard HTTP link by giving the link a title (which is independent of its usage in any particular folder location). It also includes attributes that describe which window the resource should be opened in and other window open features, such as the dimensions of the window. |
Resource – Discussion Topic |
A Discussion topic is a Learning Application Object that is used to initiate Discussion activity. This represents a placeholder for a discussion topic and does not represent a link to an existing discussion topic in an external system. The importing LMS is expected to generate a new discussion topic using only its internal tools. It contains the following attributes: title, description, file attachments. |
Resource – Assessment |
An assessment represents an instance of a QTI assessment. It can embed any of the question types supported by the CC v1.2 profile of QTI. An assessment can contain a number of attributes including number of attempts, time limit and whether late submission is allowed. |
Resource – Associated Content |
A collection of files used exclusively by an individual Learning Application Object |
Resource – 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 Metadata |
This is 1EdTech CC Package level specific metadata that may include different elements covering licensing, accessibility, description, etc. |
Resource – Question Bank |
A question bank represents an instance of a QTI objectbank. Only one question bank can optionally be included in a cartridge. It can embed any of the question types supported by the CC v1.2 profile of QTI. Questions within a question bank cannot be referenced by any assessments contained in the cartridge. |
Common Cartridge v1.2 supports profiled instances of the following question types:
• Multiple Choice – single response
• Multiple Response – like multiple choice but with multiple correct answers
• True/False
• Simple Fill in the Blanks – provides single answer box with single correct answer
• Fill in the Blanks Pattern Match – provides single answer box but supports ‘contains’.
• Essay
Note that support for multiple response, essay, and pattern match are optional; they are permitted exceptions for those learning platforms that do not provide these types of questions natively.
Questions can only be included in a cartridge either as components of an assessment resource or a question bank resource. Only one question bank can be included in a cartridge.
In general, a question consists of the following elements:
• Question Label/Title
• Question Text (may include HTML, Intra-Packages References, URLs, formatting)
• Question Answer Choices (may include HTML, Intra-Packages References, URLs, formatting, images, video, audio)
• Question Answer Choice Points
• Feedback (may include HTML, Intra-Packages References, URLs, formatting, images, video, audio)
• Question Answer Presentation Settings
• Question Settings (e.g., time, etc.)
• Question Metadata.
• Question Rubrics.
• Question Solutions.
3.3 Categories of Resource in a Common Cartridge
In addition to the imsmanifest.xml file, there are a further three basic categories of resource file in a Common Cartridge.
Table 3.2 Common Cartridge Resource Categories.
Resource Category |
Description |
imsmanifest.xml |
• This is the standard 1EdTech manifest file. |
Web Content Resources |
• These include the following resource types: web content, web link or intra-package reference (see table 3.1). • Web Content Resources must reside within the web content folder at the root of the cartridge. The Web Content Resources can here be organized into directories and subdirectories within the web content folder. • Web Content Resources within the web content folder can be referenced by other resources outside of the web content folder directory system. • Web Content Resources within the web content folder can be referenced by other resources also within the web content folder directory system. • Web Content Resources within the web content folder cannot reference other resources outside of the web content folder directory system. • The directory structure within the web content folder will be included in the importing LMS to ensure relative links between and to web content continue to work. • Generally, Web Content Resources do not require additional processing on import into the LMS, although how these are stored and rendered is LMS dependent. • Web Content Resources can have an intended use attribute. |
Learning Application Object Resources |
• A Learning Application Object is a directory structure used to group together all the files (or file references) that are used to deliver a single instance of one of the following resource types: web content, web link, discussion topic, assessment or intra-package reference (see table 3.1). • The files held within a Learning Application Object directory structure are described as Associated Content Resources. • Associated Content Resources cannot be referenced by other resources outside of the Learning Application Object folder directory system. • Associated Content Resources can reference other resources in subordinate folders of the Learning Application Object directory system. • The directory structure within the Learning Application Object folder will be included in the importing LMS to ensure relative links between and to web content continue to work. • These will generally be parsed on input and transformed into internal data structures in the LMS. |
Using Directories in Package Interchange File |
• File system directories can be used to organize content within the package interchange file. It is required that the resources specific to a given Learning Application Object are packaged in a distinct directory in the package interchange file. |
Associated Content resources include a collection of files used by a specific Learning Application Object. Each file referenced must exist in the directory containing the descriptor file of the Learning Application Object with which it is associated or any subdirectory thereof. Furthermore, each Associated Content resource must be associated with one and only one Learning Application Object. This association is indicated by use of a dependency reference on the Learning Application Object’s resource element.
A resource of the type “associatedcontent” must comply with the following restrictions:
1) It must contain a file element for each file that exists in the directory that contains the associated learning application object’s descriptor file or any of its subdirectories.
2) It must not contain any references to files above the directory containing the associated learning application object’s descriptor file.
3) It must not contain any dependency elements.
Web Content resources include any number of references to static web resources that are generally supported on the web such as HTML files, GIF images, JPEG images, PDF documents, etc. Resources of the type “webcontent” may reference any number of files. Additionally, “webcontent” resources may include dependencies on other “webcontent” resources. However, “webcontent” resources may never contain dependencies on any other resource types including Associated Content resources and Learning Application Object resources.
A resource of the type “webcontent” must comply with the following restrictions:
1) It may contain a file element for any file that exists in the package so long as the file is not in a learning application object directory or a subdirectory of any learning application object directory.
2) It may contain dependency elements that reference any other resources of type “webcontent”.
3) It must not contain any dependency elements to resources whose type is not “webcontent”.
Table 3.3 Restrictions on Resource Categories.
Dependency Resource Type |
Learning Application Resource |
Associated Content Resource |
Web Content Resource |
Web Content |
0-N |
0-N |
0-N |
Associated Content |
0-1[1] |
Prohibited |
Prohibited |
Learning Application |
Prohibited |
Prohibited |
Prohibited |
3.3.1 Cartridge Level Web Content
These are web content resources that may be shared between different Learning Application Objects within the cartridge.
References to files in this file system from Learning Application Object files must utilize relative paths e.g.:
“../filename”
3.3.2 Learning Application Object Directories
(<root>/learningApplicationResourceDirectory1… learningApplicationResourceDirectoryN)
These directories organize all the files that logically contribute to the delivery of a single instance of one of the content types supported by Common Cartridge.
The root of the directory should contain the descriptor file for the Learning Application Object such as the QTI file for an assessment Learning Application Object. This directory may also contain additional files and subdirectories that are used exclusively by the Learning Application Object (i.e., associated content).
The name of this directory is not defined by the specification. Care must be taken to ensure that collisions do not occur between this directory name and the names of directories used for other Learning Application Objects and those used for web content.
A cartridge that does not contain any additional Learning Application Objects (e.g., only cartridge level web content) may exclude these directories.
The following structure is valid since the learning application folder is at the root level of the cartridge and the descriptor XML file is at the root level of the folder:
imsmanifest.xml
content
image
picture.jpg
file1.html
discussion.xml
The following structure is invalid since the descriptor is not at the root of the learning application folder:
imsmanifest.xml
content
image
picture.jpg
discussion.xml
file1.html
3.3.3 Associated Content
Any web content which is logically tied to this Learning Application Object should be contained in the Learning Application Object resource directory.
All references to this content from Learning Application Object resource files e.g. QTI files should use a relative path.
It is the responsibility of the cartridge producer to ensure name collisions do not occur between end user created file/folder names (for web content) and system generated file/directory names (for resource descriptors).
3.3.4 Example Layout
An example of the layout described above could be:
imsmanifest.xml
course-logo.gif
course-overview.html
content1
content1/preTestQti.xml
content1/images/map.gif
content1//movie.swf
content1/background.html
content2
content2/discussionTopic1.xml
content2/overview.html
content2/images/image.gif
content3
content3/webLink1.xml
content4
content4/lessonplan.pdf
3.4 Pathnames for Web Content Resources
To facilitate management of web content resources, in particular utilizing standard html relative path referencing between resources when content is imported into a learning platform or Common Cartridge ‘runner’, web content resources are defined to live in two file systems – a folder for web content used by several resources and a folder for each Learning Application Object’s related content.
The diagram in Figure 3.3 shows how web content may be referenced across these different file systems using relative path semantics.
Figure 3.3 Content referencing using relative file paths.
3.4.1 Cartridge Web Content
A Cartridge Web Content folder may be included in a Common Cartridge. If present, the Cartridge Web Content folder must appear in the root folder of the cartridge. The name of this folder is not defined by the specification.
Web content included in the Cartridge Web Content folder can be referenced by any of the Learning Application Objects in the cartridge. Relative path referencing is permitted between files in this folder and its subfolders, but files in this folder are not permitted to reference files in a Learning Application Object folder or its associated content folders.
On import, a tool will usually import this content into a course level file system.
3.4.2 Learning Application Object Web Content
There can be 1 to n Learning Application Object web content folders in a Common Cartridge.
Each Learning Application Object in the cartridge has its own associated content file system folder. Files in this folder and its subfolders may reference other files in this associated content file system folder and files in the Cartridge Web Content folder using relative path semantics. However, they must not reference files in other Learning Application Object web content folders or their sub-folders. In addition, Learning Application Object resources (e.g., a QTI xml file) can contain references to files in the Learning Application Object’s associated content folder and its subfolders and the cartridge web content folder and its subfolders, but must not contain references to web content in the folders of other Learning Application Objects.
On import, a tool that only supports a single course level file system may import this web content into the course level file system. In this scenario, the web content in the cartridge represents one big file system scope.
A tool that supports both course level and Learning Application Object level file systems will import this content into a local file system space that can only be utilized by the associated Learning Application Object.
3.4.3 Format of Relative Path References within a web content file system
All html path linking (e.g. <img src=””>, <a href=””>) between content contained in a given file system (cartridge or Learning Application Object) should utilize relative path semantics restricted by the rules defined above. Here relative path is defined as relative to the file containing the reference regardless of whether that file is itself web content or some other resource e.g. a QTI file.
3.4.3.1 Referencing Web Content from other Web Content
Within a given file system, paths are relative to the location of the file, e.g., for the files:
content1/material/lesson.html
content1/images/icon.gif
An image reference to icon.gif from lesson.html would take the form:
<img src=”../images/icon.gif”/>
3.4.3.2 Referencing Web Content Directly from other Resources Using a Defined Linking Syntax
Where the linking syntax of a learning application object uses a URI, paths should be relative to the file containing the reference, e.g., for the files:
content1/question1Qti.xml
content1/images/icon.gif
A QTI mattext element would take the form:
<mattext texttype="text/html"><![CDATA[<img src= "$1EdTech-CC-FILEBASE$images/icon.gif" alt="" style="border: 0px solid rgb(0, 0, 0);">]]</mattext>
3.4.3.3 Referencing Web Content from Embedded Text in Another Resource
Where a Learning Application Object resource supports free-form text which may contain embedded HTML markup, paths should be relative to the file containing the reference and should in addition contain a special token to make finding and parsing these paths simpler for the importing system, e.g., for the files:
content1/question1Qti.xml
content1/images/icon.gif
A reference to the image icon embedded in the free format question text should take the form:
<img src=”$1EdTech-CC-FILEBASE$images/icon.gif”/>
Note: the token $1EdTech-CC-FILEBASE$ is just a flag to facilitate finding the paths. It does not represent a replacement token within the context of the cartridge. However, an importing tool may choose to store the referenced files in a different location and so is free to insert any path elements needed to make the path work in the tool.
The $1EdTech-CC-FILEBASE$ token can be used in resources with a descriptor file. The token always points to the base directory of the learning resource object i.e. the folder that contains the descriptor. The path following the token should be relative to the base directory of the resource within the cartridge. Since the dependent files that make up a quiz or forum may be reorganized in the LMS in a way that would break links embedded in the resource content, the LMS at import or later can replace this token with an alternate path. Additionally, since any supplemental images or html will also need to be contained within the cartridge, these items should be listed as dependencies.
3.4.4 Format of Relative Path References from Learning Application Object to Cartridge File System
All html path linking (e.g. <img src=””>, <a href=””>) by content contained in a Learning Application Object file system to content in the cartridge web content file system should use relative paths adhering to similar rules as those defined for references within a file system. Here relative path is defined as relative to the file containing the reference regardless of whether that file is itself web content or some other resource, e.g., a QTI file.
3.4.4.1 Referencing Cartridge Web Content from Learning Application Object Web Content
The key rule is that where a relative path within the Learning Application Object file system is directed above that file system root, this is assumed to be a reference into the cartridge web content file system, e.g., for the files:
images/icon.gif
content1/material/lesson.html
An image reference to icon.gif in the cartridge file system from lesson.html in a Learning Application Object file system would take the form:
<img src=”../../images/icon.gif”/>
3.4.4.2 Referencing Cartridge Web Content Directly from Learning Application Object Resources
Where the information model of another Learning Application Object resource is defined as a URI, paths should be relative to the file containing the reference, e.g., for the files:
content1/question1Qti.xml
3.4.5 Referencing Cartridge Web Content from Embedded Text in another Resource
Where a Learning Application Object resource supports free-form text which may contain embedded HTML markup, paths should be relative to the file containing the reference and should in addition contain a special token to make finding and parsing these paths simpler for the importing system, e.g., for the files:
content1/question1Qti.xml
A reference to the cartridge image icon embedded in the free format question text should take the form:
<img src=”$1EdTech-CC-FILEBASE$../images/icon.gif”/>
3.4.6 The ‘dependency’ Element
The 'dependency' element must only be used for resources of a particular type and for certain relationships between resource types. These rules are:
§ A Web Link - must not have a dependency;
§ A Discussion Topic - may have a dependency on Web Content and/or Associated Content;
§ Assessment - may have a dependency on Web Content and/or Associated Content;
§ Question Bank - may have a dependency on Web Content and/or Associated Content;
§ Web Content - may have a dependency on Web Content;
§ Associated Content- may have a dependency on Web Content;
§ 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 metadata that is integrated into an LMS learning context. At a high level, this may directly correspond to the notion of “course” in the target LMS. There is no guarantee of the cardinality of the relationship from “learning context” to “Common Cartridge”, i.e., the LMS may enforce an arbitrary 1-1 relationship. The data contained in the package breaks down into the following categories:
• “Learner Experience” Data. These are the resources presented directly to the learner, i.e., content resources.
• Supplemental Resources. These are resources that may be optionally integrated into the learning context by an instructor or other facilitator, e.g., question bank.
• Operational Data. Data used to control behavioral aspects of the LMS display/interaction with the cartridge, e.g., authorization or Basic LTI.
• Descriptive Metadata. This is the defined IEEE LOM data, and is represented via existing bindings.
A Common Cartridge is an 1EdTech Content Package conforming to the following basic structure.
• A Common Cartridge may define a single organization, or include no organization. Multiple organizations are not permitted and the default attribute for organizations is not therefore supported. The single organization is used on import to integrate with the learning context, and defines the basic navigation structure for the package. The organization assumes the predefined “rooted-hierarchy” structure.
• Only “Learner Experience” resources may be included in the <organization> hierarchy.
• Operational data (authorization, cartridge-level metadata) are defined via discrete resource types within the package.
• Supplemental resources must not appear in the organization. The LMS provides a way for the instructor/facilitator to inspect/deploy/utilize these resources as they see fit.
Common Cartridge resources must be identified with GUIDs, in order to facilitate proper integration in systems that execute “by reference” content usage.
4.2 Supported Resource Types
Table 4.1 Common Cartridge Supported Resource Types.
Resource Type |
Constraints |
Web Content |
0 or more |
Associated Content |
0 or more |
QTI Assessment (CC Profiles) |
0 or more |
QTI Question Bank (CC Profiles) |
0 or 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 Metadata
• LOM Metadata (restricted to DC elements for the cartridge level metadata) will be used to capture metadata.
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_xmlv1p2/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/imsccv1p2/imscp_v1p1"
xmlns:lom="http://ltsc.ieee.org/xsd/imsccv1p2/LOM/resource"
xmlns:lomimscc="http://ltsc.ieee.org/xsd/imsccv1p2/LOM/manifest"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
/xsd/imsccv1p2/imscp_v1p1 /profile/cc/ccv1p2/ccv1p2_imscp_v1p1_v1p0.xsd
http://ltsc.ieee.org/xsd/imsccv1p2/LOM/resource /profile/cc/ccv1p2/LOM/ccv1p2_lomresource_v1p0.xsd
http://ltsc.ieee.org/xsd/imsccv1p2/LOM/manifest /profile/cc/ccv1p2/LOM/ccv1p2_lommanifest_v1p0.xsd">
<metadata>
<schema>1EdTech Common Cartridge</schema>
<schemaversion>1.2.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>
<organization identifier="O_1" structure="rooted-hierarchy">
<item identifier="I_1">
<item identifier="I_00000">
<title>Psychology, Research, and You</title>
<item identifier="I_00001" identifierref="I_00001_R">
<title>Learning Objectives</title>
</item>
<item identifier="I_00002">
<title>Study Guide</title>
<item identifier="I_00003" identifierref="I_00003_R">
<title>Pretest</title>
</item>
</item>
<item identifier="I_00005" identifierref="I_00005_R">
<title>Wikipedia - Psychology</title>
</item>
<item identifier="I_00006" identifierref="I_00006_R">
<title>Psychology of Faces</title>
</item>
</item>
</item>
</organization>
</organizations>
<resources>
<resource href="I_00001_R/Learning_Objectives.html"
identifier="I_00001_R" type="webcontent">
<file href="I_00001_R/Learning_Objectives.html"/>
</resource>
<resource identifier="I_00003_R" type="imsqti_xmlv1p2/imscc_xmlv1p2/assessment">
<file href="I_00003_R/assessment.xml"/>
</resource>
<resource identifier="I_00004_R" type="imsqti_xmlv1p2/imscc_xmlv1p2/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>
<resource identifier="I_00005_R" type="imswl_xmlv1p2">
<file href="I_00005_R/weblink1.xml"/>
</resource>
<resource identifier="I_00006_R" type="imsdt_xmlv1p2">
<file href="I_00006_R/discussion.xml"/>
<dependency identifierref="I_00006_Media"/>
<dependency identifierref="I_media_R"/>
</resource>
<resource identifier="I_00006_Media" type="associatedcontent/imscc_xmlv1p2/learning-application-resource">
<file href="I_00006_Media/angry_person.jpg"/>
</resource>
<resource identifier="I_media_R" type="webcontent">
<file href="I_media_R/smiling_dog.jpg"/>
</resource>
</resources>
</manifest>
4.4.5 Cartridge Web Content Type
• Cartridge web content represents web content that may be referenced by any Learning Application Object in the cartridge.
• Cartridge web content is represented as a Resource object.
• It may be directly referenced from a folder Item object.
• The characteristic object Type must be the value ‘webcontent’.
• The characteristic object intendeduse is optional and must be one of the values: ‘assignment’, ‘lessonplan’, ‘syllabus’, or ‘unspecified’.
• If a cartridge web content resource is linked from a Learning Application Object link Item object it must have an Href characteristic object, which represents the launchable resource.
4.4.5.1 The Assignment IntendedUse
• When a hosting platform offers an assignment tool, it should create an assignment based on the web content rather than a plain web content link in the course. It is expected the instructor will then apply any additional changes to the delivery settings based on the course context (for example setting the number of attempts, or the possible grade if a graded assignment).
4.4.6 Associated Content Type
• Associated content represents web content that is scoped to a particular resource.
• Associated content is represented as a Resource object.
• It may be directly referenced from a folder Item object.
• The characteristic object Type must be the value ‘associatedcontent/imscc_xmlv1p2/learning-application-resource’
• If the associated content resource is linked from a Learning Application Object link Item object it must have an Href characteristic object, which represents the launchable resource.
• The Resource object may contain Dependency objects which reference Resource objects with Type ‘webcontent’.
4.4.7 Discussion Topic Content Type
• A Discussion Topic is a Learning Application Object that is used to initiate Discussion activity.
• Discussion topic content is represented as a Resource object.
• Expected default behavior:
• Upon import, the discussion topic content will be stored by the tool using its own internal representation.
• As the cartridge content is added to an actual course, an associated discussion topic will be created in the discussion forum used by the tool.
• The location of the discussion topic resource object in the cartridge organization dictates the point in the course at which the learner is directed to the item in the discussion forum.
• The discussion topic group would be the cohort of learners enrolled on the course and the instructor.
• If the cartridge were added to more than one course, then each course would have its own discussion topic created, each with its own group of enrolled learners.
• It may be directly referenced from a folder Item object.
• The characteristic object Type must be the value ‘imsdt_xmlv1p2’.
• 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/imsccv1p2/imsdt_v1p2 schema (see below).
• The Resource object may contain Dependency objects, which reference Resource objects with Type ‘webcontent’ and/or ‘associatedcontent/imscc_xmlv1p2/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_xmlv1p2’.
• 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/imsccv1p2/imswl_v1p2 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_xmlv1p2/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_xmlv1p2/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_xmlv1p2/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_xmlv1p2/learning-application-resource’.
4.4.11 Common Cartridge Authorization
Earlier versions of the Common Cartridge specification discussed authorization. At this point, 1EdTech no longer recommends the use of this feature and suggests implementers consider 1EdTech Basic LTI [BLTI, 10] for authenticated access to content.
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 metadata according to the Common Cartridge profile of the IEEE LOM (loose binding) [IEEE LOM, 05] which describes the range of a mapping from the core elements of the Dublin Core specification v1.1 [DC, 03] to IEEE LOM. This application profile is restrictive. It uses the namespace http://ltsc.ieee.org/xsd/imsccv1p2/LOM/manifest which differs from the IEEE LOM namespace by the insertion of imscc. In contrast, metadata for resources (see below) need to use the original IEEE LOM namespace.
The metadata element as well as its schema and schema version element are required at the manifest level. They must be expressed as follows.
<metadata>
<schema>1EdTech Common Cartridge</schema>
<schemaversion>1.2.0</schemaversion>
… metadata according to Common Cartridge profile of IEEE LOM …
</metadata>
The usage of metadata at other places in the common cartridge is not restricted. This may change in future versions of the specification.
Any media player, codec, browser plug-in or operating system requirements for the cartridge content must be declared in the cartridge-level metadata description. Each entry should include details of the tool/product name, version number, supplier name and the URL for their website. Such requirements must be entered in the description element for the cartridge as free text.
4.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 Metadata
If metadata is applied to resources, then it must be based on IEEE LOM. In particular, it must use the IEEE LOM namespace http://ltsc.ieee.org/xsd/imsccv1p2/LOM/resource.
There are situations where resources may need to be specified within the organization, but should not be made visible in player mode upon default import of the cartridge. One such situation is the inclusion of instructor manuals, lesson plans, instructor notes and solution files that should only be visible to instructors or perhaps instructors and mentors. In other situations, publishers may wish to provide additional, optional resources that may be selectively released to students or mentors and students, or mentors only, by the instructor at some later date. In each case, there is a need to indicate where the resources should appear within the organization even though the resources are not initially visible to learners in the cartridge player. These resources must be made visible in cartridge editors so that the settings may be modified when and if appropriate.
To meet these needs, the common cartridge applies optional “roles” metadata associated with the resource in the manifest file. If not present, then the default behavior is that the resource would be viewable by all users. If present, then it declares the roles for which the resource would be viewable.
The following supported roles are defined in the vocabulary:
IMS_GLC_CC_Rolesv1p2
|
Learner |
Instructor |
Mentor |
CC version 1.0 |
? |
? |
|
CC version 1.1 |
? |
? |
? |
CC version 1.2 |
? |
? |
? |
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_Rolesv1p2</lom:source>
<lom:value>Instructor</lom:value>
</lom:intendedEndUserRole>
</lom:educational>
</lom:lom>
Note: specifying a role is intended to have an effect on how a learning platform behaves. For example, content intended for an instructor should not be visible to a learner.
4.5.3 Curriculum Standards Metadata
Curriculum standards metadata is supported for the cartridge, resource, and question item. The design of this support allows for at least the following:
- Any curriculum standard can be used, as long as it supports unique identifiers. The provider of a specific standard is designated by the string-valued ‘provider’ element. In order to facilitate interoperability, 1EdTech will maintain a list of registered providers, but custom, i.e. unregistered providers, are permitted. Note that the provider can be accompanied by region and version string-valued attributes. These are intended to be for descriptive value only.
- Any cartridge, resource, or question item can be associated with 0 or more curriculum standards from 1 or more providers.
- The provider value and GUID should be sufficient to unambiguously identify a standard.
- An optional GUID label is supported as this should make standards more readily apparent when examining the cartridge.
Possible Applications:
- A content creator aligns cartridge, resource, or question item to specific standards.
- An instructor or student seeks a cartridge that has material aligned to a standard with which they need additional study. A discovery tool might locate a cartridge that matches a specific standard or a similar one. Such a tool might be able to navigate standards relationships programmatically to suggest more general or more detailed content.
- An instructor or administrator seeks to assess how students performed on a test, broken down by results per standard. A learning platform could use alignment metadata to produce such reports.
Curriculum Standards metadata can be applied at the cartridge, resources, or question item level. The approach for either the cartridge or non-assessment resources is identical and is illustrated below:
…
<resource identifier="RES001" type="webcontent">
<metadata>
<curriculumStandardsMetadataSet xmlns=/xsd/imscsmetadata_v1p0>
<curriculumStandardsMetadata providerId=”ASN" region=”Georgia” version=”2011”>
<setOfGUIDs>
<labelledGUID>
<label>ASN PURL for Florida on subject "..." and level "..".</label>
<GUID>http://purl_org/ims/cck12ls/usa_florida_LA_4_2_1_5</GUID>
</labelledGUID>
<labelledGUID>
<label>ASN PURL for Florida on subject "..." and level "..".</label>
<GUID>http://purl_org/ims/cck12ls/usa_florida_LA_4_4_1_6</GUID>
</labelledGUID>
</setOfGUIDs>
</curriculumStandardsMetadata>
</curriculumStandardsMetadataSet>
</metadata>
...
At the assessment resource level, the syntax required is slightly different. We can’t place metadata directly into the assessment description file (XML) and so we place it in the manifest and include the item’s identifier.
For the resource that holds the assessment, the curriculumStandardsMetadataSet metadata element must include the attribute resourceLabel=”QTI-Assessment”.
For item-level metadata, the element may include the attribute resourceLabel=”QTI-Assessment” and resourcePartId= the Id of the QTI item, i.e., ident attribute of item element. This mechanism associates the curriculum standards metadata, which resides in the imsnanifest.xml file with a specific item in the assessment file.
<resource identifier="RES_MOD4_LSN4_exam1" type="imsqti_xmlv1p2/imscc_xmlv1p2/assessment">
<metadata>
<curriculumStandardsMetadataSet resourceLabel="QTI-Assessment">
<curriculumStandardsMetadata providerId="ASN">
…
</curriculumStandardsMetadata>
</curriculumStandardsMetadataSet>
<curriculumStandardsMetadataSet resourceLabel="QTI-Item" resourcePartId="c10752c0-5a03-49c7-a1fd-8b7e08df80ec">
< curriculumStandardsMetadata domainId="ASN">
…
</curriculumStandardsMetadata>
</curriculumStandardsMetadataSet>
And in the referenced assessment file, the item ident attribute matches the resourcePartId in the manifest.
<assessment ident="18f098f1-e9a4-4799-8dbc-f4984d16a122" title="4_12ARegularSegmentOneExam">
…
<section ident="8b3a8b99-3919-498e-bcfe-cea2b0759e5e" title="4_12ARegularSegmentOneExam">
<item ident="c10752c0-5a03-49c7-a1fd-8b7e08df80ec" title="4_12ARegularSegmentOneExam">
<itemmetadata>
<qtimetadata>
…
4.6 Discussion Topics
Discussion topics are described in a descriptor file as follows:
4.6.1 Example Instance
<?xml version="1.0" encoding="UTF-8"?>
<topic xmlns="/xsd/imsccv1p2/imsdt_v2p1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="/xsd/imsccv1p2/imsdt_v1p2
/profile/cc/ccv1p2/ccv1p2_imsdt_v1p2.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>
<attachment href="../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.
• texttype values(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.6.2 Schema
<xs:schema targetNamespace=" /xsd/imsccv1p2/imsdt_v1p2" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns=" /xsd/imsccv1p2/imsdt_v1p2 /profile/cc/ccv1p2/ccv1p2_imsdt_v1p2.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.7 Web Links
Web links are described in a descriptor file as follows:
4.7.1 Example Instance
<?xml version="1.0" encoding="UTF-8"?>
<webLink xmlns="/xsd/imsccv1p2/imswl_v1p2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
/xsd/imsccv1p2/imswl_v1p2
/profile/cc/ccv1p2/ccv1p2_imswl_v1p2.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
• href URL 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.7.2 Schema
<xs:schema targetNamespace="/xsd/imsccv1p2/imswl_v1p2" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns=" /xsd/imsccv1p2/imswl_v1p2
/profile/cc/ccv1p2/ccv1p2_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.8 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 http://www.imsglobal.org/xsd/lti/ltiv1p0/imslticc_v1p0.xsd
/xsd/imsbasiclti_v1p0 http://www.imsglobal.org/xsd/lti/ltiv1p0/imsbasiclti_v1p0.xsd
/xsd/imslticm_v1p0 http://www.imsglobal.org/xsd/lti/ltiv1p0/imslticm_v1p0.xsd
/xsd/imslticp_v1p0 http://www.imsglobal.org/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_xmlv1p2/learning-application-resource">
<file href="BLTI001_Media/learning_icon.gif"/>
</resource>
4.9 QTI
4.9.1 Overview
A Common Cartridge may contain either/both of two Learning Object Resource types that are based on the CC QTI Profile: Assessments and Question Banks. Generally Assessments are meant to represent an ordered question set and may include optional attributes that apply to the set as a whole. A CC Question Bank refers to a QTI Object Bank, constrained to hold just those question types supported in the CC profile. Assessments should employ the <assessment> QTI element (see section Assessments vs. Object Banks directly below). Question Banks are meant to represent unordered sets of questions with no associated attributes applying to the set as a whole (though metadata is permitted). Question banks should use the <objectbank> QTI element. In addition, question banks should have no representation in the organizations section of the manifest 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.9.2 Assessments vs. Object Banks
Assessments are represented with a single <assessment> element with required ident and title attributes and optional language attribute. The <assessment> element may contain an optional <presentation_material> element to represent information to be displayed prior to a student launching the assessment.
A <qtimetadata> element can be present where CC specific metadata elements are allowed within <qtimetadatafield> structures as follows:
<qtimetadatafield>
<fieldlabel></fieldlabel>
<fieldentry></fieldentry>
<qtimetadatafield>
fieldlabel |
fieldentry |
cc_profile |
cc.exam.v0p1 |
qmd_assessmenttype |
The type of assessment role. The only supported value is 'Examination'. |
qmd_scoretype |
'Percentage' scoring is always used. |
qmd_feedbackpermitted |
If 'No' then students should not see any feedback for this assessment. Default is 'Yes'. |
qmd_hintspermitted |
If 'No' then students should not see any hints for this assessment. Default is 'Yes'. Note that hints are not profiled and their presence not recommended. |
qmd_solutionspermitted |
If 'No' then students should not see any feedback flagged as Solution for this assessment. Default is 'Yes'. |
qmd_timelimit |
Time limit is an integer value expressed in minutes. If unspecified there is no time limit. |
cc_allow_late_submission |
Indicates whether the time limit should be strictly enforced. Should only be provided if the qmd_timelimit was also specified. Allowed values are "Yes" and "No". The default is "Yes" |
cc_maxattempts |
Allows specifying the maximum allowed user attempts. Allowed values are 1, 2, 3, 4, 5 and "unlimited". The default is 1. |
language |
|
In addition to the optional <presentation_material> and <qtimetadatafield> elements the <assessment> element must contain exactly one <section> element with a required ident and an optional title attribute. The <section> element contains one or more <item> elements only.
Object banks are represented as a single <objectbank> element which can contain one or more <item> elements only. 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.9.3 Item Overview
<item> elements represent individual questions in assessments or object banks (i.e. question banks). An Item is built of different elements. The Common Cartridge profile imposes additional restrictions on how an item can be built on top of the QTI 1.2 specifications. Some of those restrictions are common to all question types while others are specific to a given one. However, regardless of the question type, a QTI Item should always follow the same structure:
item
1 itemmetadata: (which specifies the profile used for this item)
1 presentation
1 material/mattext: the question text
1 response: presenting the choices/input
0-1 resprocessing (mandatory except for Essay Question)
1 outcomes: declare the SCORE variable
0-1 respcondition: display general feedback
0-n respcondition: per-answer feedback (for LID based items, at most one per answer)
1 respcondition: setting the score to 100 if correct, display correct feedback
0-1 respcondition: display general incorrect feedback
0-n itemfeedback
(1 meaning one and only one, 0-1 at most one, 0-n any number)
4.9.4 Itemmetadata
The <itemmetadata> element contains a set of <qtimetadata> element where CC specific metadata elements are allowed within <qtimetadatafield> structures (as in Assessments vs. Object Banks section above) as follows:
fieldlabel |
fieldentry |
cc_profile |
At least this field is required. Corresponds to the six supported question types. Can be: cc.multiple_choice.v0p1, cc.multiple_response.v0p1, cc.true_false.v0p1, cc.fib.v0p1, cc.pattern_match.v0p1, or cc.essay.v0p1 |
cc_question_category |
A single keyword value |
cc_weighting |
cc_weighting specifies the preferred points value for the question. This is useful because the scoring variables are normalized to percentage-based values between 0 and 100. Additionally, this allows for points possible to be specified for manually graded items such as essay questions. Must be an integer value 0 - 99 if provided. Otherwise a default of 1 is assumed. |
qmd_scoringpermitted |
Yes (Because there is no automated scoring for essays, we use standard qmd metadata to indicate the item is manually scored.) |
qmd_computerscored |
The computerscored for essay must be No. |
4.9.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.9.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.9.7 Feedback
4.9.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.9.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.9.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.9.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>
<displayfeedback feedbacktype="Response" linkrefid="correct_fb"/>
</respcondition>
The ident for the general correct feedback should be: correct_fb.
4.9.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.9.8 Hints
Hints are not profiled and therefore it is recommended not to include them in Items.
4.9.9 LID based Question Types: True/False, Multiple Choice and Multiple Response
4.9.9.1 Overview and Profiles
LID (Logical Identifier) based questions are questions where the user must select one or multiple answers among a set of choices.
The profiles for LID based questions are:
- cc.mutliple_choice.v0p1 for multiple choice questions when a single answer can be selected
- cc.mutliple_response.v0p1 for multiple choice questions where multiple answers can be selected
- cc.true_false.v0p1 for true/false questions
4.9.9.2 Presentation
Multiple_choice, multiple_response, and true_false questions use a <response_lid> element to contain the individual answers. There is a required ident and an rcardinality attribute which should be set to Single for multiple choice and true false questions and Multiple for multiple_response questions.
The <response_lid> element contains a single <render_choice> element with a shuffle (Yes/No) attribute to indicate whether or not scrambling of answer choices is allowed.
The <render_choice> element contains one or more <response_label> elements with a required ident attribute. The < response_label > elements contain a single <material><mattext> structure holding the text of the individual answers. The text can either be plain text or HTML text, in which case it can refer to Web Content and Dependencies contained in the Cartridge (using the $1EdTech-CC-FILEBASE$ token).
Response.rshuffle is not supported here.
4.9.9.3 Response Processing: Multiple Choice
The <conditionvar> is made of a single <varequal> element checking if the correct identifier was selected.
<respcondition continue="No">
<conditionvar>
<varequal respident="response_1">answer_4</varequal>
</conditionvar>
<setvar action="Set" varname="SCORE">100</setvar>
<displayfeedback feedbacktype="Response" linkrefid="correct_fb"/>
</respcondition>
4.9.9.4 Response Processing: True-False
True False uses the same <respcondition> than Multiple Choice questions.
4.9.9.5 Response Processing: Multiple Answers
Only ‘All or Nothing’ grading is supported: a single combination is considered correct, all others are considered incorrect answers. The combination is expressed using a <and> containing a combination of <varequal> and <not><varequal> in the form:
<respcondition continue="No">
<conditionvar>
<and>
<not>
<varequal case="Yes" respident="response_1">answer_1</varequal>
</not>
<varequal case="Yes" respident="response_1">answer_2</varequal>
<varequal case="Yes" respident="response_1">answer_3</varequal>
<not>
<varequal case="Yes" respident="response_1">answer_4</varequal>
</not>
</and>
</conditionvar>
<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>.
Note that the specification also permits <or> as in, for example:
<respcondition continue="No">
<conditionvar>
<or>
<varequal case="No" respident="response_1">London</varequal>
<varequal case="No" respident="response_1">Londres</varequal>
</or>
</conditionvar>
<setvar action="Set" varname="SCORE">100</setvar>
</respcondition>
No nesting is allowed, a <not> should only contain a <varequal>.
4.9.9.6 Response Processing: Per-answer feedback
Combinatory Responses feedback is not defined (for example, a feedback if the answer 1 and 3 are selected). However per-answer feedback is supported. If present, it must be placed directly after the general item feedback <respcondition>. There can be at most one answer feedback per answer, so it is not required to have a feedback for each answer.
Each feedback answer is in its own <respcondition> with continue flag on for further processing:
<respcondition continue=”Yes”>
<conditionvar>
<varequal respident="response_1">Answer1</varequal>
</conditionvar>
<displayfeedback feedbacktype="Response" linkrefid="answer1_fb"/>
</respcondition>
<respcondition continue=”Yes”>
<conditionvar>
<varequal respident="response_1">Answer2</varequal>
</conditionvar>
<displayfeedback feedbacktype="Response" linkrefid="answer3_fb"/>
</respcondition>
For each feedback, there must be one and only one corresponding <itemfeedback> element.
The naming convention for answer feedback is: {answer ident}_fb.
4.9.10 FIB based Questions: Fill-in-the-Blank and Pattern Matching
4.9.10.1 Overview and Profiles
Fill in the Blank and Pattern Matching are similar question types which mostly differ in how they evaluate the correct answer, either based on equality (Fill in the Blank) or on a matching rule (Pattern Matching).
The profile for Fill in the Blank is cc.fib.v0p1, the profile for Pattern Match (Simple containement) is cc.pattern_match.v0p1. The support for Pattern Matching Question type is optional.
4.9.10.2 Presentation
Fill-in-the-blank questions use a single <response_str> element with a required Ident. The <response_str> element contains a single <render_fib> element. The rows attribute, if specified, must be set to 1. The columns attribute may be set any positive integer but may be ignored.
4.9.10.3 Response Processing: Fill-in-the-Blank
Fill-in-the-blank questions are not case sensitive on grading as indicated by setting the case attribute to "No" in the <varequal> element.
<respcondition continue="No">
<conditionvar>
<varequal case="No" respident="response_1">London</varequal>
</conditionvar>
<setvar action="Set" varname="SCORE">100</setvar>
</respcondition>
Multiple alternate answers are supported, but since the support of multiple possible answers is optional, the most relevant answer should be the 1st proposed choice and a consumer that can support only one valid answer should use the 1st one.
<respcondition continue="No">
<conditionvar>
<varequal case="No" respident="response_1">London</varequal>
<varequal case="No" respident="response_1">Londres</varequal>
</conditionvar>
<setvar action="Set" varname="SCORE">100</setvar>
</respcondition>
4.9.10.4 Response Processing: Simple Pattern Match
Simple Pattern Match is only checking for the inclusion of the answer into the response. Simple Pattern match questions may optionally be case sensitive by setting case="Yes", but the default is NOT case sensitive. To check if a string is contained anywhere in the response the varsubstring condition is used as follows:
<conditionvar>
<varsubstring respident="response_1" case="No">expected</varsubstring>
</conditionvar>
Alternate answers are not supported (only a single varsubstring is allowed).
4.9.11 Essay Question
4.9.11.1 Overview and Profile
Essay based questions are questions where the user answers with a free unbounded text. Essay question are not expected to be automatically graded. However a sample solution can be made available to help the grader in his evaluation.
The profile for essay question is: cc.essay.v0p1.
4.9.11.2 Presentation
Presentation is using the same construct as FIB question types.
4.9.11.3 Sample Solution
Essay questions are a bit apart from the other since they do not support automatic grading. In place they might offer a sample solution to help the grader evaluate the response.
Essay questions can indicate at most one sample answer as follows:
<itemfeedback ident="solution">
<solution>
<solutionmaterial>
<material>
<mattext texttype="text/html"><![CDATA[here is the sample solution]]></mattext>
</material>
</solutionmaterial>
</solution>
</itemfeedback>
If a Solution is provided there is no need to also include a <displayfeedback> element in the <resprocessing> section since the feedback is already in a <solution> element. A consumer is expected to understand that in the context of an essay question, the <solution> element, if present, represents the sample solution.
4.9.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.10 Assessment in Common Cartridge
Common Cartridge supports only one role of assessment which maps to the 1EdTech concept of ‘Examination’ (as defined by the QTI metadata attribute ‘qmd_assessmenttype’).
An assessment must contain exactly one section which contains all questions delivered by the assessment. Multiple sections and references to questions in an object bank are not supported.
An assessment does support the use of a number of metadata attributes which can carry additional delivery information about the assessment such as maximum attempts and time limit. These are defined in the profile.
4.10.1 Questions
The Common Cartridge supports profiles of the following question types:
• Multiple Choice (Single Response)
• Multiple Choice (Multiple Response)
• True/False
• Essay
• Simple Fill in the Blank – single response box with multiple correct answers that are processed as an exact match
• Pattern Match – single response box with multiple potential answers that support exact match and containment matching.
Note that support for multiple response, essay, and pattern match are optional; they are permitted exceptions for those learning platforms that do not provide these types of questions natively.
The profiles for each of these question types describe how they support:
• feedback
• sample solutions
• relative scoring
In addition, questions support a number of metadata attributes which describe:
• a suggested weighting for the question in the assessment
• a category for the question.
Instances of these questions may be included in an assessment or a question bank.
CC supports general feedback, general correct feedback, general incurred feedback, and per-answer feedback.
For full details refer to the profile descriptions.
4.10.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 a tool in handling question banks is undefined.
4.11 Vocabularies
Vocabularies refer to a set of string constants used to specify pre-defined values for metadata elements. Typically these value sets are specified by the document that defines the metadata element, such as the IEEE Learning Object Metadata or Dublin Core standards. Common Cartridge metadata elements may extend or replace vocabularies with new sets that describe the content included in the package.
For example, the lifeCycle.contributor.role element may be specified to include values from the following set:
• student
• instructor
• administrator
which might be expanded to include:
• designer
• reviewer
Where metadata vocabularies are extended or replaced for use in Common Cartridge descriptions, an 1EdTech Vocabulary Definition and Exchange (VDEX) document is required to define the new or extend vocabulary. See http://www.imsglobal.org/vdex/index.html for information on the 1EdTech VDEX v1.0 specification [VDEX, 04].
Common Cartridge vocabularies are fixed and may not be replaced, extended, or modified.
4.12 UML Diagrams
A complete set of UML diagrams for QTI are available for review in the 1EdTech CC Alliance. These diagrams are large and are easier to study as separate files that can be magnified as needed. As such, they are no longer reproduced in the printed specification.
5 Implementation Guidelines and Best Practices
5.1 General Best Practices
A convention could be utilized based on some form of UID to prevent collisions with user generated web content folder names. Additionally, a subdirectory may be created to contain all Learning Application Object directories to further reduce the risk of collisions between Learning Application Object directories and those in the web content.
5.1.1 Extensions to Resources Metadata
Compliant systems must at least tolerate any structure attached to extension points.
5.1.2 Accessibility
Extensions for accessibility supported in Content Packaging v1.2 have been incorporated into the schema for Common Cartridge v1.2. However, whilst these extensions are provided for use by those wishing to provide accessibility features, their use and implementation is not mandated for general use and they will not be addressed in any conformance tests developed.
For guidance on use of the accessibility extensions, see the Content Packaging v1.2 specification [CP, 07].
5.1.3 Metadata Rights Management
Copyright of a cartridge is defined as follows:
<rights>
<copyrightAndOtherRestrictions>
<value>yes</value>
</copyrightAndOtherRestrictions>
<description>
<string> 2006-2007 1EdTech Consortium Inc.</string>
</description>
</rights>
5.1.4 XML Descriptor Files
1EdTech recommends that all XML files be written using an XML editor. This will help ensure that the content of descriptor files is XML in proper form and will allow parsers to processes these files correctly.
1EdTech also recommends that XML file content use encoding for reserved characters such as ‘>’, ‘<’, ‘&’, ‘%’, etc.
5.1.5 Filenames
1EdTech recommends that filenames not contain spaces, although some systems allow this. Similarly, 1EdTech recommends that all filename references use either all lowercase or all uppercase and consistently.
5.2 Examples of Valid Common Cartridge File Structures
5.2.1 Sample 1 – Web Content and Learning Application Objects Both in Root
0001<root> 0002 Imsmanifest.xml 0003 -------------------- |
Resource 0001 (Web Content Resource) 0004 Page001.htm 0005 Images\ 0006 Image0001.gif |
Resource 0002 (Web Content Resource) 0007 Media\ 0008 Audio001.mp3 |
0009 --------------------- 0010 LO001\ |
Resource 0003 (Discussion Forum Resource) 0011 Welcome.forum |
Resource 0004 (Associated Content Resource for Resource 0003) 0012 Welcome.gif 0013 Attachments\ 0014 Gettingstarted.doc |
0015 LO002\ |
Resource 0005 (QTI Assessment Resource) 0016 Studymate.qti |
0017 LO003\ |
Resource 0006 (QTI Assessment Resource) 0018 Quiz1.qti |
Resource 0007 (Associated Content Resource for Resource 0006) 0019 Sample.doc 0020 Images\ 0021 Ques001.gif 0022 Ques002_a.gif |
|
Legend |
|
|
|
|
Web Content Resource |
|
|
|
Learning Application Object |
|
|
|
Associated Content Resource |
|
|
----- |
Empty Line |
5.2.2 Sample 2 – Web Content in Root and Learning Application Objects in Subdirectory
0001 <root> 0002 Imsmanifest.xml 0003 -------------------- |
Resource 0001 (Web Content Resource) 0004 Page001.htm 0005 Images\ 0006 Image0001.gif |
Resource 0002 (Web Content Resource) 0007 Media\ 0008 Audio001.mp3 |
0009 Data 0010 LO001\ |
Resource 0003 (Discussion Forum Resource) 0011 Welcome.forum |
Resource 0004 (Associated Content Resource for Resource 0003) 0012 Welcome.gif 0013 Attachments\ 0014 Gettingstarted.doc |
0015 LO002\ |
Resource 0005 (QTI Assessment Resource) 0016 Studymate.qti |
0017 LO003\ |
Resource 0006 (QTI Assessment Resource) 0018 Quiz1.qti |
Resource 0007 (Associated Content Resource for Resource 0006) 0019 Sample.doc 0020 Images\ 0021 Ques001.gif 0022 Ques002_a.gif |
|
Legend |
|
|
|
|
Web Content Resource |
|
|
|
Learning Application Object |
|
|
|
Associated Content Resource |
|
|
----- |
Empty Line |
5.2.3 Sample 3 – Web Content and Learning Application Objects Both in Subdirectories
0001 <root> 0002 Imsmanifest.xml 0003 Content |
Resource 0001 (Web Content Resource) 0004 Page001.htm 0005 Images\ 0006 Image0001.gif |
Resource 0002 (Web Content Resource) 0007 Media\ 0008 Audio001.mp3 |
0009 LO001\ |
Resource 0003 (Discussion Forum Resource) 0010 Welcome.forum |
Resource 0004 (Associated Content Resource for Resource 0003) 0011 Welcome.gif 0012 Attachments\ 0013 Gettingstarted.doc |
0014 LO002\ |
Resource 0005 (QTI Resource) 0015 Studymate.qti |
0016 LO003\ |
Resource 0006 (QTI Assessment Resource) 0017 Quiz1.qti |
Resource 0007 (Associated Content Resource for Resource 0006) 0018 Sample.doc 0019 Images\ 0020 Ques001.gif 0021 Ques002_a.gif |
|
Legend |
|
|
|
|
Web Content Resource |
|
|
|
Learning Application Object |
|
|
|
Associated Content Resource |
|
|
----- |
Empty Line |
5.2.4 Relative Paths
The following table illustrates all valid relative file reference scenarios for each resource
5.2.4.1 Valid Relative File References
Resource |
Valid Relative References |
Resource 0001 |
Resource 0001, Resource 0002 |
Resource 0002 |
Resource 0001, Resource 0002 |
Resource 0003 |
Resource 0001, Resource 0002, Resource 0004 |
Resource 0004 |
Resource 0001, Resource 0002, Resource 0004 |
Resource 0005 |
Resource 0001, Resource 0002 |
Resource 0006 |
Resource 0001, Resource 0002, Resource 0007 |
Resource 0007 |
Resource 0001, Resource 0002, Resource 0007 |
The following three tables illustrate the required relative path to access another file in the root directory of another resourceAn X in a box indicates that a relative reference to files in that resource are not allowed.
5.2.4.2 Relative Paths for Sample 1
Table 5.1 Relative path to file in root of resource#. |
|||||||
Resource |
0001 |
0002 |
0003 |
0004 |
0005 |
0006 |
0007 |
0001 |
./ |
./ |
X |
X |
X |
X |
X |
0002 |
./ |
./ |
X |
X |
X |
X |
X |
0003 |
../ |
../ |
X |
./ |
X |
X |
X |
0004 |
../ |
../ |
X |
./ |
X |
X |
X |
0005 |
../ |
../ |
X |
X |
X |
X |
X |
0006 |
../ |
../ |
X |
X |
X |
X |
X |
0007 |
../ |
../ |
X |
X |
X |
./ |
./ |
5.2.4.3 Relative Paths for Sample 2
Table 5.2 Relative path to file in root of resource#. |
|||||||
Resource |
0001 |
0002 |
0003 |
0004 |
0005 |
0006 |
0007 |
0001 |
./ |
./ |
X |
X |
X |
X |
X |
0002 |
./ |
./ |
X |
X |
X |
X |
X |
0003 |
../../ |
../ |
X |
./ |
X |
X |
X |
0004 |
../../ |
../../ |
X |
./ |
X |
X |
X |
0005 |
../../ |
../../ |
X |
X |
X |
X |
X |
0006 |
../../ |
../../ |
X |
X |
X |
X |
X |
0007 |
../../ |
../../ |
X |
X |
X |
./ |
./ |
5.2.4.4 Relative Paths for Sample 3
Table 5.3 Relative path to file in root of resource#. |
|||||||
Resource |
0001 |
0002 |
0003 |
0004 |
0005 |
0006 |
0007 |
0001 |
./ |
./ |
X |
X |
X |
X |
X |
0002 |
./ |
./ |
X |
X |
X |
X |
X |
0003 |
../../content/ |
../../content/ |
X |
./ |
X |
X |
X |
0004 |
../../content/ |
../../content/ |
X |
./ |
X |
X |
X |
0005 |
../../content/ |
../../content/ |
X |
X |
X |
X |
X |
0006 |
../../content/ |
../../content/ |
X |
X |
X |
X |
X |
0007 |
../../content/ |
../../content/ |
X |
X |
X |
./ |
./ |
5.3 Content & Assessment Issues
5.3.1 Course Essentials
Provide comprehensive information about the course and its content, including, but not limited to:
• Full book title (including edition). If there is no corresponding book, provide the course title.
• Author(s)
• ISBN
• Publisher/Imprint/Business Unit/Discipline.
• Appropriate contact information, including editorial/author/support (email, phone number, etc.).
• Full URLs of any associated websites, along with appropriate access information if protected.
• A list of any special plug-ins or enabling technologies required for satisfactory use.
• Whenever possible, develop content for the broadest base of browser versions and operating systems in current use. Keep in mind that not everyone has the latest and greatest.
• Provide details for content (file types, how it is presented, etc.)
• Provide appropriate copyright information, including any restrictions on the content’s use.
5.3.2 Course Design
5.3.2.1 Keep it Simple!
Specialized coding, such as custom JavaScript modules, may work beautifully in one LMS/CMS environment, but may not work at all in another. Avoid it.
Use consistent file naming, with shorter file names wherever possible.
Avoid the use of glyphs, such as curly or typographer's quotation marks, which may not render properly in some platforms. Unfortunately, curly quotes is a default setting in MS Word. When this feature is active, straight quotation marks are automatically changed to curly quotes while typing. Disable it when authoring content for the Common Cartridge.
5.3.2.2 Keep it Small!
Always keep course size in mind when designing and building a course. If any modules or features are repeated throughout the course, place them in a section that can hold these common elements. Doing this can dramatically cut down on the size of the cartridge. Optimally, a course should not be larger than 100 MB. Better yet, whenever possible, put larger, commonly-used files on a server, external to the course, and link to them there.
5.3.2.3 Use External Servers for Large and Commonly Used Files
Large files (such as PPT, Word/Excel, PDFs, movies and other media) generally should not be included within a course. Anything loaded within the course will tend to enlarge the course size and this will increase the time to download a course. When multiple instances of a course are installed on a server to support multiple sections, significant server space may be needlessly consumed with redundant content. Content stored on external servers will need to be made available to course users, though. For publishers, this will likely mean hosting content on a server that is globally accessible from the Internet. For a locally-produced university course, this may mean hosting content on a server accessible by the intended users – wherever they are, inside or outside of the university firewall.
5.3.2.4 Avoid “Platform-Specific” Language/Icons
Sometimes "platform-specific" language appears in assessments and or other pages of a course. This could be anything from instructions on how to submit a quiz for grading to module-specific information. Avoid such platform-specific language and/or icons in your course content.
5.3.2.5 Plan for Change
An instructor can alter the look/feel of a course within minutes of installing it on a server, so the design of course material should be kept clean and simple. Provide a simple yet professional banner and icon set for the course content. It may be possible to use a generic set of icons for all courses.
5.3.2.6 Make it Compatible
Some platforms support multiple correct answers, while others may not. Some CMS support tutorial mode – where questions are presented one at a time – while others may not. Some systems may re-order questions. Some systems may support feedback, but that feedback is generally for right or wrong answers and rarely support individualized feedback for each specific answer. Develop questions that will work on all platforms.
Develop assessments that the Common Cartridge currently supports:
• Multiple choice, single response
• Multiple choice, multiple response
• True/false
• Essay
• Fill-in-the-blank
• Pattern match (optional)
See the Common Cartridge specifications for more information about the individual question types.
An assessment may include a reading, image, hyperlink to another website, or a set of instructions at the top of the quiz that are needed for the student to answer the questions. Decide how to handle these questions. The information can be included in each question, or the question can include a link to it.
Try to keep the quizzes in a course to a reasonable number. Otherwise, an instructor may encounter problems when using the course gradebook.
5.3.2.7 Check it
Proofread and QA the course content against the original source materials, ensure that all course elements function properly, and all external resources are appropriately available.
5.4 Future Development
The 1EdTech Content Packaging specification v1.2 is to be augmented with guidance on how to namespace in accessibility metadata. 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.
About This Document
Title: 1EdTech GLC Common Cartridge Profile: Implementation
Editor: Jeff Kahn (1EdTech GLC)
Version: 1.2
Version Date: 1 October 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: http://www.imsglobal.org/cc/
List of Contributors
The following individuals contributed to the development of this document:
Name |
Organization |
Thor Anderson |
Utah Valley University |
David Gappa |
Safari Montage |
Jeff Kahn |
1EdTech Consortium |
Lisa Mattson |
1EdTech Consortium |
Chris Moffatt |
Microsoft Inc. |
Colin Smythe |
1EdTech Consortium |
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. |
Final v1.2 |
1 October 2011 |
The Final CC v1.2 specification. |
|
|
|
|
|
|
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 http://www.imsglobal.org
Please refer to Document Name: 1EdTech GLC Common Cartridge Profile: Implementation
Date: 1 October 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