1EdTech Thin Common Cartridge® Profile: Implementation Guide (for CC v1.2 & v1.3)
Version 1.0 Final Specification
Date Issued: 1 May 2015
Latest version: http://www.imsglobal.org/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: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © 2008 - 2015 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: http://www.imsglobal.org/license.html.
Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.
The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
For comments and feedback, join the discussion at: http://www.imsglobal.org/community/forum/categories.cfm?catid=58
© 2015 1EdTech Consortium, Inc.
All Rights Reserved.
Trademark Information: http://www.imsglobal.org/copyright.html
Document Name: 1EdTech Thin Common Cartridge Profile: Implementation Guide (for CC v1.2 & v1.3) v1.0 Final Release
Revision: 1 May 2015
Table of Contents
1.1 Thin Common Cartridge (CC) Overview
1.2 A Note on Conformance and Exceptions
3.1 Common Cartridge Package Interchange File Structure
4 Thin Common Cartridge Information Model Profiles
4.3.4 Web Link (URL) Content Type
4.3.5 Learning Tools Interoperability (LTI) Content Type
4.4 Inline XML and External File XML Approaches
4.5.3 Curriculum Standards Metadata
5 Implementation Guidelines and Best Practices
5.1 Organizing the Package File Structures
5.2.3 Curriculum Standards Metadata
5.3 Minimalist Thin Cartridges [Only for Thin CC V1.3]
1 Introduction
1.1 Thin Common Cartridge® (CC®) Overview
1EdTech “Thin Common Cartridge” enables content interoperability using Learning Tools Interoperability® (LTI®) enabled links and Web Links only. The “Thin Common Cartridge” addresses the use case where content users, such as school districts, have a need for access to publisher content bundled in a way that can support search within a Learning Object Repository or Learning Management System for learning objects from a wide range of publishers. The lightweight structure of a Thin Common Cartridge (Thin CC) supports rapid development and deployment of publisher content to district systems without the need for massive data exchange. It is designed to ensure the correct installation and operation of content metadata across any Thin Common Cartridge conformant platforms and tools. The Thin CC profile is a greatly reduced subset of the Full Common Cartridge Specification [CC, 12a], [CC, 12b], [CC, 12c], [CC, 13a], [CC, 13b], [CC, 13c] and as such is simpler for developers to implement. By definition, any system that has Full CC v1.2 or Full CC v1.3 import certification will have corresponding Thin CC v1.2 or Thin CC v1.3 certification. The Thin CC specification must be understood within the context of the Full CC specification.
Figure 1.1 Thin CC focus.
The primary focus of the Thin CC specification is achieving error-free import of content metadata, LTI and Web Links 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 Thin CC schema set.
1.2 A Note on Conformance and Exceptions
1EdTech Thin CC conformance enables interoperability of the packaging and delivery of content metadata and links. As is the case with the Full CC, the Common Cartridge Accredited Profile Management Group (CC AMPG) approved support for LTI v1.x, Curriculum Standards Metadata (CSM) in CC v1.2, and inline descriptor-file XML in CC v1.3.
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 Thin Common Cartridge conformance. All systems that do not support a feature of Thin CC 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. The only conformance exceptions permitted for learning platforms that support Thin CC are:
· Support for exporting in Thin CC format is not required;
· Support for inline XML resource definitions is not required;
· Support for the ‘mentor’ term in the ‘role’ metadata vocabulary is not required;
· Support for ALL of the LOM fields (at manifest and resource levels) is not required;
· Support for Curriculum Standards Metadata (at manifest and resource levels) is not required.
1.3 References
[BLTI, 10] 1EdTech Basic Learning Tools Interoperability (BLTI) v1.0, 1EdTech, May 2010.
[CC, 13a] 1EdTech Common Cartridge Profile: Overview v1.3, 1EdTech, July 2013.
[CC, 13b] 1EdTech Common Cartridge Profile: Use Cases v1.3, 1EdTech, July 2013.
[CC, 13c] 1EdTech Common Cartridge Profile: Conformance v1.3, 1EdTech, July 2013.
[CC, 13d] 1EdTech Common Cartridge Profile: Appendices v1.3, 1EdTech, July 2013.
[CC, 12a] 1EdTech Common Cartridge Profile: Overview v1.2, 1EdTech, October 2011.
[CC, 12b] 1EdTech Common Cartridge Profile: Use Cases v1.2, 1EdTech, October 2011.
[CC, 12c] 1EdTech Common Cartridge Profile: Conformance v1.2, 1EdTech, October 2011.
[CC, 12d] 1EdTech Common Cartridge Profile: Appendices v1.2, 1EdTech, October 2011.
[CP, 07] 1EdTech Content Packaging (CP) v1.2, 1EdTech, 2007.
[LOM, 02] IEEE Learning Object Metadata (1484.12.1-2002).
[LOM, 05] IEEE LOM Schema Binding (1484.12.3-2005).
[VDEX, 04] 1EdTech Vocabulary Definition Exchange (VDEX) v1.0, 1EdTech, February 2004.
2 Architecture
Thin CC focuses primarily on how information should be physically arranged in a package and how learning platforms should construct specific native objects of Web Links and LTI links. Thin CC also specifies how conforming learning platforms must behave when processing packages. The corresponding runtime model is shown in Figure 2.1.
Figure 2.1 Thin CC runtime model.
3 Content
3.1 Common Cartridge Package Interchange File Structure
Figure 3.1 shows the overall layout of the cartridge package interchange file. Note that the package must have the extension “imscc”.
Figure 3.1 Thin CC package interchange file.
3.2 Content Types
The permitted set of content types in a Thin CC is shown schematically in Figure 3.2 and summarised in Table 3.1.
Figure 3.2 Thin CC content types.
Table 3.1 Thin Common Cartridge Content Types.
|
Entity |
Description |
|
Item |
The logical structuring of the learning experience. An Item can contain any combination of other items and/or folders. There must be a single root 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 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 –Learning Tools Interoperability |
An LTI resource represents a simplified and self-contained LTI link. This resource refers to an XML file that contains the information needed to create in a Tool Consumer (an LMS or learning platform) a link or similar. When activated by the user, passes the user to a Tool Provider along with contextual information about the user and Consumer. |
|
1EdTech CC Package Metadata |
This is 1EdTech CC Package level specific metadata that may include different elements covering licensing, accessibility, description, etc. (encoded using IEEE LOM). This includes optional Curriculum Standards Metadata. |
|
Resource Metadata |
This is the resource level specific metadata that may include different elements covering licensing, accessibility, description, etc. (encoded using IEEE LOM). This includes optional Curriculum Standards Metadata. |
4 Thin Common Cartridge Information Model Profiles
4.1 The Conceptual Model
Conceptually, a Thin CC is a content package of content metadata, LTI and web links that is integrated into an LMS learning context. There is no guarantee of the cardinality of the relationship from “learning context” to “Thin CC”, 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 – the resources presented directly to the learner i.e. content resources;
· Operational Data – data used to control behavioral aspects of the LMS display/interaction with the cartridge such as with LTI;
· Descriptive Metadata – this is the defined IEEE LOM data and is represented via existing bindings.
A Thin CC is an 1EdTech Content Package conforming to the following basic structure.
· It 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 referenced in the <organization> hierarchy;
· Operational data (cartridge-level metadata) are defined via discrete resource types within the package.
Thin CC 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
The only permitted resources in a Thin CC are summarised in Figure 4.1.
Table 4.1 Thin CC supported resource types.
|
Resource Type |
Constraints |
|
Web Links |
0 or more |
|
LTI Link |
0 or more |
4.3 Content Packaging
4.3.1 Overview
The Thin CC 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:
· Manifests – in the Thin CC profile all content will be captured in a single 1EdTech manifest. Children will not be used;
· Metadata – LOM Metadata will be used to express all manifest and resource level metadata;
· Organization – the Organization will be used to represent the Common Cartridge Folder content type. See the discussion on representing the Thin CC Folder Type for the additional profiling applied to this data.
· Resources – each resource (LTI Link or Web Link) is defined using either inline XML or reference to a single separate XML instance file. The <dependency> element is not permitted. Inline XML is only permitted in Thin CC v1.3 and higher.
4.3.2 Manifest
The manifest object may not contain child Manifest objects. The version attribute for the Manifest is prohibited in the Thin CC profile to avoid confusion with the Thin CC version number, which by implication, uniquely identifies the version of Content Packaging adopted (instead, for Thin CC the value of the ‘xs:version’ attribute is either ‘1EdTech THIN CC 1.2 CP 1.2’ or ‘1EdTech THIN CC 1.3 CP 1.2’ depending on whether the Thin CC is based on CCv1.2 or CCv1.3 respectively).
4.3.3 Organization
The structure of the content is represented by the <organizations> container object type. A Thin CC may have a single <organization> or no <organization>. The ‘default’ XML attribute of the <organizations> object is prohibited. The <organization> object must contain a ‘structure’ XML attribute 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. The permitted forms of the <organizations> is either:
|
000 001 002 |
<organizations /> |
or
|
000 001 002 003 004 005 006 007 008 009 |
<organizations> <organization identifier=”Org1” structure=”rooted-hierarchy”> <title>Mathematics Volume III</title> <item> … </item> </organization> </organizations>
|
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:
|
000 001 002 003 004 005 006 007 008 009 |
<organization identifier=”Org1” structure=”rooted-hierarchy”> <title>Mathematics Volume III</title> <item> <item> … </item> </item> </organization> |
The following are NOT valid:
|
000 001 002 003 004 005 006 007 008 009 010 |
<organization identifier=”Org1” structure=”rooted-hierarchy”> <title>Mathematics Volume III</title> <item> … </item> <item> … </item> </organization> |
|
000 001 002 003 004 005 006 007 |
<organization identifier=”Org1” structure=”rooted-hierarchy”> <title>Mathematics Volume III</title> <item> <title>Some text</title> </item> </organization> |
An <item> container object type either represents a folder or a link to a resource. The ‘parameters’ XML attribute’ object of Item is not supported by Thin CC. Every <item> object with the exception of the root Item must contain a <title> object. An <item> object which represents a folder is indicated by the absence of an ‘identifierRef’ XML attribute. Folder Items support unlimited nesting of other folder Items and Learning Application Object link Items. For example:
|
000 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 |
<organization identifier=”Org1” structure=”rooted-hierarchy”> <title>Mathematics Volume III</title> <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> </organization> |
An Item object representing a link to a resource must contain an ‘identifierRef’ characteristic object which references the <resource> object describing the linked content. Link <item> objects may be nested by folder <item> object but may not nest other folder or link <item> objects. It is valid for two link <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.3.4 Web Link (URL) Content Type
Web Link content is represented as a Resource object. It may be directly referenced from a folder Item object. The format rules are:
· The XML attribute ‘type’ must be the value ‘imswl_xmlv1p2’ or ‘imswl_xmlv1p3’ depending on hether this is for Thin CC based on CCv1.2 or CCv1.3 respectively;
· The <resource> object ‘href’ XML attribute is prohibited;
· The <resource> object must contain a single <file> object, which references the Web Link descriptor XML file which conforms to the http://www.imsglobal.org/xsd/imsccv1p2/imswl_v1p2.xsd or http://www.imsglobal.org/xsd/imsccv1p3/imswl_v1p3.xsd schema (see below);
· The Resource object must not contain Dependency child objects.
4.3.5 Learning Tools Interoperability (LTI) Content Type
An LTI Link content is represented as a Resource object. It may be directly referenced from a folder Item object. The format rules are:
· The characteristic object ‘type’ must be the value ‘imsbasiclti_xmlv1p0’;
· The <resource> object ‘href’ characteristic object is prohibited;
· The <resource> object must contain a single File object, which references the LTI Link descriptor XML file, which conforms to the http://www.imsglobal.org/xsd/imsbasiclti_v1p0 schema.
· The <resource> object must not contain Dependency child objects;
· References to other information, for example an icon file, must not require that file to be included in the package (this wold require another resource tye to be used). All such references must be to some externally hosted end-point.
4.4 Inline XML and External File XML Approaches
In Thin CC 1.3 ONLY, each of the resources can be described either in a stand-alone XML file or directly in the manifest. The motivation for this change is to allow for the case of a cartridge being described wholly in a single XML file. This file could be offered as the response to a web-service call, easing the movement of cartridges. An example with three resources, on inline and two stand-alone, is given below (the prefix ‘wl’ is used to denote that for the Web Link XML namespace).
|
000 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 |
<resources> <resource identifier="Resource16" type="imswl_xmlv1p3"> </resources> |
4.5 Metadata & Vocabularies
4.5.1 Manifest-level Metadata
The recommended manifest-level metadata is described in Table 4.1. The columns in Table 4.1 and Table 4.2 denote:
· Name – the name of the field. The term enclosed in the accompanying square brackets denote the equivalent Dublin Core term;
· Type –the data type for the field;
· Occurrence – defines if the field is recommended (‘R’) or optional (‘O’);
· Multiplicity – defines the number of occurrences of the field. This is enumerated as single (’1’) or many (‘*’);
· Description – a short description of how the field is to be used.
Table 4.1 – The set of metadata fields to be supported at the manifest-level.
|
Name |
Type |
Occurrence |
Multiplicity |
Description |
|
GUID [ identifier ] |
String. |
R |
1 |
This field is the globally unique identifier of the object from the originator. This will be used to determine if the object already exists in the system in order to avoid duplicates. It will allow the owner of the object to update the metadata or URL when necessary. Systems can also allow direct access to the object within their system by allowing the field to be searched. |
|
Title [ title ] |
String. |
R |
1 |
This field contains the metadata title of the cartridge. |
|
Description [ description ] |
String. |
R |
1 |
This field contains the metadata description of the cartridge. |
|
Keywords [ subject ] |
String (space delimited). |
O |
1 |
This field contains the single words separated by spaces related to the object. This helps organize the object within the system for easier searching and identification. |
|
Copyright [ date ] |
Year (4 digit string). |
O |
1 |
This field contains the year in which the cartridge was created. It represents when the copyright of the object was first introduced. |
|
Mapping to Curriculum Standards |
List of GUIDs (strings). |
O |
* |
This field (set of fields) contains each state standard or common core standard reference for the object. Along with provider /originator information. In this case the term GUID is used in the sense of any globally unique identifier form e.g. number, URI, etc. |
|
Extension |
N/A |
O |
* |
Support for an extension mechanism. |
4.5.2 Resource-level Metadata
The recommended resource-level metadata is described in Table 4.2.
Table 4.2 – The set of metadata fields to be supported at the resource-level.
|
Name |
Type |
Occurrence |
Multiplicity |
Description |
|
GUID [ identifier ] |
String. |
R |
1 |
This field is the globally unique identifier of the object from the originator. This will be used to determine if the object already exists in the system in order to avoid duplicates. It will allow the owner of the object to update the metadata or URL when necessary. Systems can also allow direct access to the object within their system by allowing the field to be searched. |
|
Role |
Enumeration: { Learner | Instructor | |
R |
* |
Declares the roles for which the resource would be viewable. |
|
LTI URL |
String (URL). |
O |
1 |
This field is the LTI launch URL to access the tool within the tool provider. It contains either the direct URL to the tool or the authorization service of LTI while the actual tool or resource is at the Resource URL location. |
|
Resource URL |
String (URL). |
R |
1 |
This field is used as a parameter with LTI. It contains the redirect URL that the LTI tool provider requires to access the tool. The LTI URL authorizes and sets up the tool session while the resource URL accesses the specific tool or resource within the tool provider. |
|
Title [ title ] |
String. |
R |
1 |
This field contains the metadata title of the object. |
|
Description [ description ] |
String. |
R |
1 |
This field contains the metadata description of the object. |
|
Keywords [ subject ] |
String (‘|’ delimited). |
O |
1 |
This field contains the single words separated by the ‘|’ character. This helps organize the object within the system for easier searching and identification. |
|
From Grade |
Enumeration: { p | k | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | a }. |
O |
1 |
This string contains the lowest grade level that should have access to the object. Any grade level that is lower than this value shall be denied access to the object and it may not even be visible to the user. The grade levels are pre-kindergarten or preschool, kindergarten, 1st grade, 2nd grade, etc. Adult represents an object that is post High School. This string is combined with the ‘To Grade’ string value. |
|
To Grade |
Enumeration: { p | k | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | a }. |
O |
1 |
This string contains the highest-grade level that should have access to the object. Any grade level that is higher than this value shall be denied access to the object and it may not even be visible to the user. The grade levels are pre-kindergarten or preschool, kindergarten, 1st grade, 2nd grade, etc. Adult represents an object that is post High School. This string is combined with the ‘From Grade’ string value. |
|
Copyright [ date ] |
Year (4 digit string). |
O |
1 |
This field contains the year in which the object was created. It represents when the copyright of the object was first introduced. |
|
Type [type] |
String. |
R |
This field contains a descriptor string for the type of object supplied at the link endpoint. This is a simpler form of the MIME type (Multipurpose Internet Email Extensions) of an object. The field is used to categorize the object for easier searching and organization. |
|
|
AccessPermission |
Enumeration: { parent | student | teacher | teacher/uploader | school admin | principal | curriculum admin | admin }. |
R |
* |
This field contains the permission needed to access the object. |
|
UseType |
Enumeration: { primary | secondary | teacher | assessment | question | concept | assignment }. |
O |
* |
This field contains the use type of the object. It allows the object to be organized based on the purpose of the object. For example, if the object were a LTI link to resource for homework purposes, it would be set to “assignment”. That means the object would be available to a student during an assignment. The values can be: · Primary: within a lesson it would be part of the primary lesson. · Secondary: within a lesson it would be a secondary object and not necessarily used and isn’t the main focus of the lesson. · Teacher: within a lesson it would be viewable only to a teacher. · Assessment: within a lesson it would be an object that would aid in the assessment. · Question: within a lesson it would be a reference or the main part of a specific question. · Concept: within a lesson it would be part of the concept review. · Assignment: within a lesson it would be part of the assignment. |
|
Visibility |
Enumeration: { private | shared | public }. |
R |
1 |
This field pertains to the visibility of the object. On initial load, who has the ability to see it. The values can be: · Private: Only the person who imported the object has the right to view the object. · Shared: Users within the school can view it. · Public: Everyone in the district can view it. |
|
Thumbnail |
String. |
O |
1 |
This field contains the URL to the location of a thumbnail of the object. This would be used in previewing the object while searching or viewing the object. Since the object is a URL and the tool provider may change the object at any time, the thumbnail would be located on the tool provider’s servers. Updated when the object is updated and accessible without an LTI launch. |
|
Mapping to Curriculum Standards |
List of GUIDs (strings). |
O |
* |
This field (set of fields) contains each state standard or common core standard reference for the object. Along with provider /originator information. In this case the term GUID is used in the sense of any globally unique identifier form e.g. number, URI, etc. |
|
Extension |
N/A |
O |
* |
Support for an extension mechanism. |
4.5.3 Curriculum Standards Metadata
CSM is supported for the cartridge and resource. The CSM takes the form as per Full Common Cartridge.
4.6 Web Links
These take the forms as as per Full Common Cartridge.
4.7 LTI Links
These take the forms as per Full Common Cartridge (note that references to other types of files e.g. icon images, etc. must be to an external end-point becase thiese files must NOT be contained in the package).
5 Implementation Guidelines and Best Practices
5.1 Organizing the Package File Structures
The package is only permitted to contain three types of file:
· The single ‘imsmanifest.xml’ file that must be present:
· Zero or more Web Link XML instance files;
· Zero or more LTI Link XML instance files.
The set of Web Link and LTI Link files can be organized using any folder hierarchy. Whenever possible, no folder hierarchy should be used (this will not be possible if there are name clashes on the source XML files).
5.2 Metadata
5.2.1 Manifest-level Metadata
The Thin CC must be described at the manifest level using the Thin CC profile of the IEEE LOM (loose binding) [IEEE LOM, 05]. It uses the namespace http://ltsc.ieee.org/xsd/imsccv1p2/LOM/manifest or http://ltsc.ieee.org/xsd/imsccv1p3/LOM/manifest. The manifest level metadata context is defined as shown below (the LOM information is denoted by elements using the prefix ‘lomm’).
|
000 001 002 003 004 005 006 007 008 009 010 |
<manifest> <metadata> <schemaversion>1.3.0</schemaversion> … </lomm:lom> </metadata> </manifest> |
Note that the <schema> and <schemaversion> elements are NOT permitted inside the metadata element for a Resource.
5.2.2 LOM Binding
An example of the binding using the IEEE LOM/1EdTech Metadata v1.3.2 is shown below.
|
0000 0001 0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019 0020 0021 0022 0023 0024 0025 0026 0027 0028 0029 0030 0031 0032 0033 0034 0035 0036 0037 0038 0039 0040 0041 0042 0043 0044 0045 0046 0047 0048 0049 0050 0051 0052 0053 0054 0055 0056 0057 0058 0059 0060 0061 0062 0063 0064 0065 0066 0067 0068 0069 0070 0071 0072 0073 0074 0075 0076 0077 0078 0079 |
<metadata> <lom xmlns="http://ltsc.ieee.org/xsd/LOM" <intendedEndUserRole> <source>IMSGLC_CC_Rolesv1p2</lom:source> <value>Learner</lom:value> </intendedEndUserRole> <intendedEndUserRole> <source>IMSGLC_CC_Rolesv1p2</lom:source> <value>Instructor</lom:value> <intendedEndUserRole> </metadata?
|
5.2.3 Curriculum Standards Metadata
An example of the mapping using the 1EdTech Curriculum Standards Metadata v1.0 is shown below (this example has been validated against the relevant 1EdTech XSD and the XML instance is available).
|
0000 0001 0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019 0020 0021 0022 0023 0024 0025 |
<metadata> <curriculumStandardsMetadataSet resourcePartId="...Pointer to Associated Resource-Part..."> </metadata>
|
5.3 Minimalist Thin Cartridges [Only for Thin CC V1.3]
The use of inline XML means that it is possible to create a Thin CC cartridge that consists of a single file i.e. the ‘imsmanifest.xml’ file: this is the Minimalist Thin CC. Whenever possible, the Minimalist Thin CC approach should be used. This does not preclude the use of the <organization> object to arrange the learning activity to be undertaken by a learner.
About This Document
Title: 1EdTech Thin Common Cartridge Profile: Implementation Guide (for CC v1.2 & v1.3)
Editor: Lisa Mattson (1EdTech), Colin Smythe (1EdTech) and Chris Chung (1EdTech)
Version: 1.0
Version Date: 1 May 2015
Status: Final Specification
Summary: This document contains the profile information for Thin 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 |
Chris Chung 1EdTech (USA)
Lisa Mattson 1EdTech (USA)
Colin Smythe 1EdTech (UK)
Revision History
|
Version No. |
Release Date |
Comments |
|
v1.0 |
18 December 2014 |
The first release of the Thin CC v1.3 Specification. |
|
Final v1.0 |
1 May 2015 |
This revision has introduced Thin CC to support Common Cartridge v1.2 as opposed to just Common Cartridge v1.3. |
|
|
|
|
1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this 1EdTech Common Cartridge Profile: Implementation ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
1EdTech would appreciate receiving your comments and suggestions.
Please contact 1EdTech through our website at http://www.imsglobal.org
Please refer to Document Name: 1EdTech Thin Common Cartridge Profile: Implementation Guide (for CC v1.2 & v1.3)
Date: 1 May 2015
