IMS Final Release

IMS Global Logo

IMS Global 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.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS’s procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © 2008 - 2015 IMS Global Learning Consortium. All Rights Reserved.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/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 IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

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

 

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

Trademark Information: http://www.imsglobal.org/copyright.html
Document Name:  IMS Global Thin Common Cartridge Profile: Implementation Guide (for CC v1.2 & v1.3) v1.0 Final Release
Revision: 1 May 2015

Table of Contents

1     Introduction.. 3

1.1      Thin Common Cartridge (CC) Overview... 3

1.2      A Note on Conformance and Exceptions. 3

1.3      References. 4

2     Architecture.. 5

3     Content.. 6

3.1      Common Cartridge Package Interchange File Structure.. 6

3.2      Content Types. 6

4     Thin Common Cartridge Information Model Profiles. 8

4.1      The Conceptual Model.. 8

4.2      Supported Resource Types. 8

4.3      Content Packaging.. 8

4.3.1   Overview.. 8

4.3.2   Manifest 9

4.3.3   Organization. 9

4.3.4   Web Link (URL) Content Type. 10

4.3.5   Learning Tools Interoperability (LTI) Content Type. 11

4.4      Inline XML and External File XML Approaches. 11

4.5      Metadata & Vocabularies. 11

4.5.1   Manifest-level Metadata. 11

4.5.2   Resource-level Metadata. 12

4.5.3   Curriculum Standards Metadata. 16

4.6      Web Links. 16

4.7      LTI Links. 16

5     Implementation Guidelines and Best Practices. 17

5.1      Organizing the Package File Structures. 17

5.2      Metadata.. 17

5.2.1   Manifest-level Metadata. 17

5.2.2   LOM Binding. 17

5.2.3   Curriculum Standards Metadata. 19

5.3      Minimalist Thin Cartridges [Only for Thin CC V1.3] 19

About This Document.. 20

List of Contributors. 20

Revision History.. 21

 

1                  Introduction

1.1            Thin Common Cartridge® (CC®) Overview

IMS “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

IMS 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 IMS, 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 IMS 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]             IMS Basic Learning Tools Interoperability (BLTI) v1.0, IMS Global, May 2010.

[CC, 13a]              IMS Common Cartridge Profile: Overview v1.3, IMS Global, July 2013.

[CC, 13b]              IMS Common Cartridge Profile: Use Cases v1.3, IMS Global, July 2013.

[CC, 13c]               IMS Common Cartridge Profile: Conformance v1.3, IMS Global, July 2013.

[CC, 13d]              IMS Common Cartridge Profile: Appendices v1.3, IMS Global, July 2013.

[CC, 12a]              IMS Common Cartridge Profile: Overview v1.2, IMS Global, October 2011.

[CC, 12b]              IMS Common Cartridge Profile: Use Cases v1.2, IMS Global, October 2011.

[CC, 12c]               IMS Common Cartridge Profile: Conformance v1.2, IMS Global, October 2011.

[CC, 12d]              IMS Common Cartridge Profile: Appendices v1.2, IMS Global, October 2011.

[CP, 07]                 IMS Content Packaging (CP) v1.2, IMS Global, 2007.

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

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

[VDEX, 04]           IMS Vocabulary Definition Exchange (VDEX) v1.0, IMS Global, 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.

Thin CC runtime model.

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”.

 

Thin CC package interchange file.

 

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.

Thin CC content types.

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.

IMS CC Package Metadata

This is IMS 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 IMS 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 IMS Content Packaging:

·         Manifests – in the Thin CC profile all content will be captured in a single IMS 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 ‘IMS THIN CC 1.2 CP 1.2’ or ‘IMS 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">
     <file href="WebLink1/link1.xml"/>
   </resource>
   <resource identifier="Resource17" type="imswl_xmlv1p3">
     <file href="WebLink2/link2.xml"/>
   </resource>
   <resource identifier="Resource18" type="imswl_xmlv1p3">
     <wl:webLink>
        <wl:title>Open2.net: Science and Nature</title>
        <wl:url href="http://www.open2.net/sciencetechnologynature/"/>
    </wl:webLink>
   </resource>

</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 |
Mentor }

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>
     <schema>IMS Thin Common Cartridge<schema>

     <schemaversion>1.3.0</schemaversion>
     <lomm:lom>

        …

     </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/IMS 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"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://ltsc.ieee.org/xsd/LOM                     http://www.imsglobal.org/xsd/imsmd_loose_v1p3p2.xsd">  

<!-- ************************************************************* -->
<!-- GUID, TITLE, DESCRIPTION, KEYWORDS ************************** -->
    <general>
        <identifier>
            <catalog>GUID</catalog>
            <entry>ABCDEFG...123456789...XYZ</entry>
        </identifier>
        <title>
            <string>...Title...</string>
        </title>
        <description>
            <string>...The description...</string>
        </description>
        <keyword>
            <string>Value1 Value2 Value 2</string>
        </keyword>
    </general>
<!-- ************************************************************* -->
<!-- LTI URL, RESOURCE URL *************************************** -->
    <technical>
        <installationRemarks>
            <string>http://...lti authentication URL ...</string>
        </installationRemarks>
        <location>http://...lti launch URL...</location>
    </technical>
<!-- ************************************************************* -->
<!-- FROM GRADE, TO GRADE, TYPE, ACCESS PERMISSION, USETYPE ****** -->
<!-- VISIBILITY, ROLE ******************************************** -->

    <educational>
        <typicalAgeRange>
            <string>’k’ to ‘a’</string>
        </typicalAgeRange >
        <learningResourceType>
            <source>...Vocab Source...</source>
            <value>..Type of Resource e.g. video/mp4...</value>
        </learningResourceType>
        <intendedEndUserRole>
            <source>Access Permission Vocab</source>
            <value>...Access Permission...</value>
        </intendedEndUserRole>
        <intendedEndUserRole>
            <source>UseType Vocab</source>
            <value>...Usetype...</value>
        </intendedEndUserRole>
        <intendedEndUserRole>
            <source>Visibility Vocab</source>
            <value>...Visibility...</value>
        </intendedEndUserRole>

        <intendedEndUserRole>

              <source>IMSGLC_CC_Rolesv1p2</lom:source>

              <value>Learner</lom:value>

        </intendedEndUserRole>

        <intendedEndUserRole>

              <source>IMSGLC_CC_Rolesv1p2</lom:source>

              <value>Instructor</lom:value>

        <intendedEndUserRole>
    </educational>
<!-- ************************************************************* -->
<!-- COPYRIGHT *************************************************** -->
    <lifeCycle>
        <contribute>
            <role>
                <value>publisher</value>
            </role>
            <date>
                <dateTime>2014</dateTime>
            </date>
        </contribute>
    </lifeCycle>
<!-- ************************************************************* -->
   </lom>

</metadata?

 

 

5.2.3           Curriculum Standards Metadata

An example of the mapping using the IMS Curriculum Standards Metadata v1.0 is shown below (this example has been validated against the relevant IMS 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
     xmlns="http://www.imsglobal.org/xsd/imsccv1p3/imscsmd_v1p0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="…"

      resourcePartId="...Pointer to Associated Resource-Part...">
      <curriculumStandardsMetadata providerId="…GUID Originator">
        <setOfGUIDs region="Florida" version="1.0">
           <labelledGUID>
              <label>Human readable string about the standard</label>
                <GUID>...GUID for Standard/Standard-part...</GUID>
           </labelledGUID>
           <labelledGUID>
              <label>Human readable string about the standard</label>
                <GUID>...GUID for Standard/Standard-part...</GUID>
           </labelledGUID>
           <labelledGUID>
              <label>Human readable string about the standard</label>
                <GUID>...GUID for Standard/Standard-part...</GUID>
              </labelledGUID>
        </setOfGUIDs>
      </curriculumStandardsMetadata>  
   </curriculumStandardsMetadataSet>

</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:                                                      IMS Global Thin Common Cartridge Profile: Implementation Guide (for CC v1.2 & v1.3)

Editor:                                                  Lisa Mattson (IMS Global), Colin Smythe (IMS Global) and Chris Chung (IMS Global)

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 IMS 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                          IMS Global (USA)

Lisa Mattson                        IMS Global (USA)

Colin Smythe                       IMS Global (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.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IMS Global Learning Consortium, Inc. ("IMS Global") is publishing the information contained in this IMS Global Common Cartridge Profile: Implementation ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
IMS Global makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
IMS Global would appreciate receiving your comments and suggestions.
Please contact IMS Global through our website at http://www.imsglobal.org
Please refer to Document Name: IMS Global Thin Common Cartridge Profile: Implementation Guide (for CC v1.2 & v1.3)
Date: 1 May 2015