1EdTech Content Packaging v1.2 Public Draft 2 Information Model

1EdTech Content Packaging Information Model

Version 1.2 Public Draft v2.0

Date Issued:	01 March 2007
Latest Version:	http://www.imsglobal.org/content/packaging/index.html
Supersedes:	1EdTech Content Packaging Information Model v1.2 Internal Draft v2.0
Comments / Feedback:	http://www.imsglobal.org/community/forum/categories.cfm?catid=92

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 © 2007 1EdTech Consortium. All Rights Reserved. Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals. 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. 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.

Intellectual property acknowledgements

“UML,” “Unified Modeling Language,” “OMG,” and “Object Management Group” are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.

“Unicode” is a registered trademark of Unicode, Inc.

“W3C” is a trademark (registered in numerous countries) of the World Wide Web Consortium; marks of W3C are registered and held by its host institutions MIT, ERCIM, and Keio.

“XML,” “HTML,” “XHTML” are trademarks of the W3C; marks of W3C are registered and held by its host institutions MIT, ERCIM, and Keio.

“SCORM” is a registered trademark of the Advanced Distributed Learning Initiative, Office of the Deputy Under Secretary of Defense (Readiness), Readiness and Training, 1E525, 4000 Defense Pentagon, Washington, D.C. 20301.

Table of contents

Intellectual property acknowledgements 2

1. Introduction 5

1.1 Overview 5

1.2 Scope and context 6

1.3 Backwards compatibility 6

1.4 Structure of this document 6

2. Normative references 7

3. Definitions, acronyms, and abbreviations 8

3.1 Definitions 8

3.1.1 child-manifest 8

3.1.2 content 8

3.1.3 content file 8

3.1.4 control file 8

3.1.5 interchange package 8

3.1.6 launchable URI 8

3.1.7 local 9

3.1.8 logical package 9

3.1.9 manifest 9

3.1.10 manifest document 9

3.1.11 meta-data 9

3.1.12 namespace 9

3.1.13 organization 9

3.1.14 package 9

3.1.15 package interchange file (PIF) 9

3.1.16 package reader 9

3.1.17 package writer 10

3.1.18 referenced-manifest 10

3.1.19 relative reference 10

3.1.20 remote 10

3.1.21 resource 10

3.1.22 stand-alone resource 10

3.1.23 variants 10

3.2 Acronyms and abbreviations 10

4. Conformance 12

4.1 Normative wording 12

4.2 Interchange package instances 12

4.3 Package readers 12

4.4 Package writers 12

4.5 Extensions 12

5. The 1EdTech Content Packaging conceptual model 13

6. Class definitions and relationship requirements 14

6.1 Key terms and concepts 14

6.2 Platform-independent model of the 1EdTech Content Packaging Information Model 16

6.3 InterchangePackage class 16

6.4 Manifest class family 17

6.4.1 Manifest class 18

6.4.2 ManifestMetadata class 19

6.4.3 Schema class 20

6.4.4 SchemaVersion class 20

6.4.5 MetadataModel class 21

6.5 Organizations class family 22

6.5.1 Organizations class 23

6.5.2 Organization class 24

6.5.3 Title class 24

6.5.4 LingualTitle class 25

6.5.5 Item class 25

6.6 Resources class family 26

6.6.1 Resources class 27

6.6.2 Resource class 28

6.6.3 File class 29

6.6.4 Dependency class 29

6.7 Metadata Class 29

6.8 Variant class 31

6.9 IPointer class 32

6.10 Extension class 34

6.11 Characteristic classes 35

6.11.1 Base class 35

6.11.2 Default class 36

6.11.3 Href class 36

6.11.4 Identifier class 37

6.11.5 IdentifierRef class 37

6.11.6 IsVisible class 39

6.11.7 Language class 40

6.11.8 LinkHref class 40

6.11.9 LinkType class 41

6.11.10 Other class 41

6.11.11 Parameters class 42

6.11.12 Structure class 42

6.11.13 Type class 43

6.11.14 Version class 44

Annex A Bibliography 45

About this document 46

List of contributors 46

Revision history 47

Index 48

1. Introduction

1.1 Overview

The 1EdTech Content Packaging Information Model describes data structures that can be used to exchange data between systems that wish to import, export, aggregate, and disaggregate packages of content.

The 1EdTech Content Packaging specification was initially conceived for the packaging of instructional content. The specification supports the description of content supporting a given learning activity, location of the content, and how these pieces of content may be organized for best instructional effect. As a result of wide adoption of the specification, millions of 1EdTech content packages of instructional content are used in a variety of applications. 1EdTech Content Packaging is a core specification referenced in the Advanced Distributed Learning (ADL) initiative’s Sharable Content Object Reference Model [SCORM, 04].

Adopters of 1EdTech Content Packaging have extended its use beyond just the packaging of instructional content. 1EdTech Content Packaging is now profiled by other 1EdTech Specifications to package and exchange other types of data.

1EdTech Content Packaging Version 1.1 was completed in April 2001. Since then, there have been requests for mostly minor functional additions and corrections, resulting in the Version 1.1.x series of the 1EdTech Content Packaging Specification, culminating with Version 1.1.4.

Requests for major functional additions were not included in the Version 1.1.x series and were accumulated as practice matured around implementing 1EdTech Content Packaging. Evaluation of these requests in 2006, combined with feedback from the wider adopter community, indicated to 1EdTech that this is the right time to make a significant update and definitive release for this specification.

The new functionality and clarifications incorporated in this Version 1.2 of 1EdTech Content Packaging are:

a) The meanings of terms used within the specification have been clarified.

b) The use of (sub)manifests, now termed child-manifests, has been clarified and enhanced:

• Interpretation of an item pointing to a child-manifest has been clarified.

• New functionality allowing components of child-manifests to be precisely referenced and interpreted has been added.

• Support for external child-manifests has been added.

c) Support for external referenced meta-data files has been added.

d) All internal vocabularies have been removed and are now maintained through the 1EdTech registration process and contained in the corresponding VDEX file (for the Type in Resource and Structure in Organization) [VDEX, 04c]¹

e) A new resource type of “stand-alone” has been added that allows another package to be used as a piece of content.

f) The syntax and usage of the Base, Parameter, IsVisible, and Href Information Model classes has been clarified.

g) Support for variant resources has been added. This includes support for alternative resources for accessible content.

h) Support for Organization and Item titles in multiple languages has been added.

i) Support for interchange packages that contain only content and interchange packages that have no local content files has been clarified.

The documentation style for this Version 1.2 of 1EdTech Content Packaging Specification has been substantially revised to reflect 1EdTech Consortium’s adoption of the Unified Modelling Language (UML).

1.2 Scope and context

The scope of the 1EdTech Content Packaging Information Model is the description of data structures that can be used to exchange content among systems that wish to import, export, aggregate, and disaggregate packages of content.

The 1EdTech Content Packaging Information Model Version 1.2 preserves the 1EdTech Content Packaging Information Model Version 1.1.4 as its base model and introduces new functionality by extension of this base model.

This specification supersedes prior versions of the 1EdTech Content Packaging information model documents and obsoletes all previous descriptions and definitions of the 1EdTech Content Packaging Information Model.

The Extensible Markup Language (XML) Schema binding for 1EdTech Content Packaging Information Model Version 1.2 and associated namespace identifiers are declared in the 1EdTech Content Packaging XML Binding Version 1.2 [CP, 07b]. Practices related to the interpretation and implementation of the Information Model are covered in the 1EdTech Content Packaging Best Practice and Implementation Guide Version 1.2 [CP, 07c].

1.3 Backwards compatibility

This document arises in an active implementation environment of ever increasing adoption of 1EdTech Content Packaging. A primary goal of this document is to enable future growth while regularizing current practice. To that end, the following definition of backwards compatibility has guided the development of this 1EdTech Content Packaging Information Model Version 1.2:

a) From the perspective of the 1EdTech Content Packaging Information Model, the 1EdTech Content Packaging Information Model v1.1.4 [CP, 04a] is a proper subset of 1EdTech Content Packaging Information Model v1.2.

b) An XML instance of the 1EdTech Content Packaging that validates against the 1EdTech Content Packaging XML Binding v1.1.4 [CP, 04b] also validates against the 1EdTech Content Packaging XML Binding v1.2 [CP, 07b].

c) The semantics of the 1EdTech Content Packaging Information Model components persists between versions except where necessary to ensure disambiguation.

d) Deprecation of classes or behaviors will be announced at least one release before realization (as “flagged for deprecation”).

1.4 Structure of this document

The structure of the rest of this document is:

2. Normative References	Lists references to other standards and requests for comment cited in this document.
3. Definitions, Acronyms, and Abbreviations	Defines terms and expands acronyms and abbreviations used in this document.
4. Conformance	The set of conformance statements that shall be obeyed for conforming systems and document instances.
5. 1EdTech Content Packaging conceptual model	Illustrates the conceptual structure of the 1EdTech Content Packaging Information Model.
6. Class Definitions and Relationship Requirements	Covers the structural relationships, data-type, value-space, and number of occurrences permitted for each kind of information object.

2. Normative references

The following referenced documents are indispensable for the application of this specification. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

[IEEELOM]	“1484.12.1–2002 IEEE Standard for Learning Object Metadata,” The Institute of Electrical and Electronics Engineers, Inc., 2002. ISBN:0-7381-3297-7.
[ISO 639–1]	Codes for the representation of names of languages – Part 1: Alpha-2 code
[ISO 639–2]	Codes for the representation of names of languages – Part 2: Alpha-3 code
[ISO 3166–1]	Codes for the representation of names of countries and their subdivisions – Part 1: Country codes
[RFC2119]	“Keywords for use in RFCs to Indicate Requirement Levels,” S. Bradner, Internet Engineering Task Force, Network Working Group, Request for Comments: 1951, March 1997. http://www.ietf.org/rfc/rfc2119.txt
[RFC2234]	“Augmented BNF for Syntax Specifications: ABNF,” D. Crocker (Ed.), P. Overell, Internet Engineering Task Force, Network Working Group, Request for Comments: 2234, November 1997. http://www.ietf.org/rfc/rfc2234.txt
[RFC2396]	“Uniform Resource Identifiers (URI): Generic Syntax,” T. Berners-Lee, R. Fielding, L. Masinter, Internet Engineering Task Force, Network Working Group, Request for Comments: 2396, August 1998. http://www.ietf.org/rfc/rfc2396.txt
[RFC2732]	“Format for Literal IPv6 Addresses in URL’s,” R. Hinden, B. Carpenter, L. Masinter, Internet Engineering Task Force, Network Working Group, Request for Comments: 2732, December 1999. http://www.ietf.org/rfc/rfc2732.txt
[RFC3986]	“Uniform Resource Identifier (URI): Generic Syntax,” T. Berners-Lee, M. Suignard, Internet Engineering Task Force, Network Working Group, Request for Comments: 3986, January 2005. http://www.ietf.org/rfc/rfc3986.txt
[SDN07, 06]	1EdTech GLC Specification Development Note 7: UML Profile for Platform Independent Model Descriptions of Specifications for Data Models, C.Smythe, v1.0, 1EdTech GLC, October 2006.
[SDN11, 06]	1EdTech GLC Specification Development Note 11: Vocabulary Definition, Registration, and Maintenance Procedures, C.Smythe, v1.0, 1EdTech GLC, July 2006.
[UCS]	“The Unicode Standard, Version 4.0.0, defined by: The Unicode Standard, Version 4.0,” The Unicode Consortium, Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1. http://www.unicode.org/versions/Unicode4.0.0/bookmarks.html

3. Definitions, acronyms, and abbreviations

3.1 Definitions

3.1.1 child-manifest

A complete, subordinate manifest contained by another manifest. A Manifest may contain one or more child-manifests. Alternatively, a manifest may include a reference to a child-manifest that is external to the interchange package. A child-manifest describes a complete logical package that is part of the larger logical package defined by its parent manifest. Child-manifests may be local or remote. See also: interchange package, local, logical package, manifest, remote.

3.1.2 content

A generic term for the logical units of usable (and re-usable) information described by a logical package. For example, in the instructional context content may be web-based instructional materials. A logical package may contain one or more units of content. See also: logical package.

3.1.3 content file

Individual computer files that embody the content described by the logical package. Content will often contain more than one content file. For example, web content is often instantiated by HTML, JPEG, and CSS files. Content files may be local or remote. See also: local, logical package, remote.

3.1.4 control file

Any file that governs the binding of the information model to make it suitable for machine processing. A software component may refer to a control file when assessing the validity of a bound instance of the information model or to guide the creation of a bound instance of the information model. For example, a file containing an XML schema may be used as a control file for an XML binding of a manifest.

3.1.5 interchange package

The set of components that are exchanged between systems. An interchange package shall include a manifest and may include content files and control files. All of the files included in an interchange package shall be described in the manifest or a child-manifest.

The interchange package is identical to the logical package when all components in the logical package are local to the interchange package. The criteria for determining the components of a logical package that should be included in the interchange package is out of scope for this specification and shall be determined by the implementer. Influencing factors may include the size of the instantiation of the interchange package, architectural reasons, and business policies.

An interchange package may be instantiated in a single compressed binary file (package interchange file) or as a collection of files on portable media (e.g., CD, DVD, USB memory device). See also: logical package, package interchange file.

3.1.6 launchable URI

A representation of a Universal Resource Locator (URL) that may be included in a resource description and that is used to locate and access the content described by the resource. The launchable Uniform Resource Identifier (URI) is not meant to be resolved by a package reader. The URI is meant to be stored for later use by other software components (e.g., a web browser) after the contents of a interchange package are processed. See also: interchange package, package reader.

3.1.7 local

Any component of the logical package that is contained within the interchange package is termed local to the interchange package. See also: logical package, interchange package.

3.1.8 logical package

A representation of one or more units of usable (and reusable) content. The logical package encompasses the full set of components described by the manifest and its child-manifests, including the local components and the remote components included by reference. See also: child-manifest, local, manifest, remote.

3.1.9 manifest

A description of a complete instance of a logical package. It describes resources in the logical package, their organization and the locations of the associated content and control files. A manifest may contain references to components that are local or remote. See also: local, logical package, remote.

3.1.10 manifest document

A Manifest object with contents that are structured according to an 1EdTech Content Packaging XML binding.

3.1.11 meta-data

Descriptive information about logical packages, logical organizations, content, and files. Meta-data may be assigned to any of the core structures within the logical package including the manifest. Any binding of a meta-data object is permitted. Each object of meta-data may be local or remote. See also: local, logical package, remote.

3.1.12 namespace

A set of names in which each name is unique and has a semantic value distinct from any other member of the same set. The set need not have any internal structure.

3.1.13 organization

The logical relationships among units of content. More than one logical organization may be described in a manifest. An organization is bound to files through the relationship among item components and their referenced resource components of a manifest. See also: resource.

3.1.14 package

Always used in conjunction with a qualifier. The definitions of the qualified forms of package are given in this section. See also: content package, interchange package, logical package.

3.1.15 package interchange file (PIF)

A particular instantiation of an interchange package described in the information model. An interchange package may be instantiated in a format other than a package interchange file (PIF). For example, an interchange package may be instantiated as a collection of files on removable media, e.g., CD, DVD, USB memory device, or compressed using another format such as .tar, .jar, .cab. See also: interchange package.

3.1.16 package reader

A software component that reads a manifest and verifies the contents of an interchange package. A package reader may also process a logical package (e.g., retrieve and store information referenced by the manifest, unpack local files from a PIF, retrieve or log addresses of remote files, etc.) or delegate that task to another software component. See also: interchange package, logical package.

3.1.17 package writer

A software component that creates or modifies an instance of an interchange package and assembles content files and other files declared local to the interchange package and writes them to the targeted interchange package binding or delegates those tasks to another software component. See also: interchange package.

3.1.18 referenced-manifest

A manifest or a component of a manifest that is referenced from within another manifest. For example, a manifest may reference an organization in another manifest. The manifest containing the component being referenced is called a referenced-manifest. A manifest may contain references to components that are local or remote. See also: local, remote.

3.1.19 relative reference

A type of URI that refers to a resource by describing an extension to the reference context. The extension and the context are combined to create a target URI. For example, relative/path/to/resource.txt is a relative reference that is interpreted in terms of a context to be resolved. The algorithm for resolving relative references in terms of contexts is defined in section 5 of RFC3986.

3.1.20 remote

Any component of the logical package that is located outside the interchange package is termed remote to the interchange package. See also: interchange package, logical package.

3.1.21 resource

A description of a collection of files used by the logical package. The description may include meta-data about the collection of files, a description of each of the files, and information about variant forms of the collection of files. See also: logical package.

A resource is often used to describe a unit of content. When this is the case, the resource may contain a launchable URI for the content.

The files described by a resource may be local or remote. See also: launchable URI, local, remote.

3.1.22 stand-alone resource

A resource type that allows a manifest to declare a relationship to another manifest in such a way that the related manifests are processed as separate but related data sets. The related manifests may be contained within a single content package or accessible as an external URI addressable resource. Each manifest represents a stand-alone learning resource which may be aggregated with other learning resources to create arbitrarily rich learning experiences.

3.1.23 variants

A container for referencing and describing variant content. A particular resource may have variants of different formats and for different purposes. The listing of variants within a resource identifies alternative collections of files for the resource. Meta-data is used to describe the intended uses of the original resource and the intended uses of the variants. Examples include, but are not limited to, use as lingual variants, visual or auditory variants, remediation variants, and platform delivery variants. See also: meta-data, resource.

3.2 Acronyms and abbreviations

ABNF	Augmented Backus-Naur Form
ADL	Advanced Distributed Learning
PIF	Packaging Interchange File
PIM	Platform Independent Model
SCORM	Sharable Content Object Reference Model
UML	Unified Modeling Language
URI	Uniform Resource Identifier
XML	Extensible Markup Language

4. Conformance

This section focuses on the conformance expected of systems or applications that prepare or process instances of an interchange package. No requirement is made on application developers to use a specific programming language or set of heuristics when implementing the requirements described by this Information Model.

4.1 Normative wording

In this document, “shall” is to be interpreted as a requirement on an implementation; “shall not” is to be interpreted as a prohibition. “Should,” “should not,” and “may” shall be interpreted as described in RFC2119.

4.2 Interchange package instances

A conforming instance of an 1EdTech Content Packaging Version 2.2 interchange package shall conform with the Information Model described in Section 6.

4.3 Package readers

A conforming reader of interchange packages shall read and interpret interchange packages as defined in Section 6.

4.4 Package writers

A conforming writer of interchange packages shall write interchange packages instances that conform with the Information Model described in Section 6.

4.5 Extensions

A conforming writer of interchange packages shall ascertain that a class from an extending namespace is congruent with the information type of the targeted extension point within the 1EdTech Content Packaging Information Model. The semantics of an Extension object shall stay within the scope of the semantics of its parent object in this Information Model. The semantics of an Extension object shall not override or redefine the semantics of any parent object defined in this Information Model.

A conforming package reader shall not have any responsibility for ensuring that the semantics of any extending class preserves or extends a kind of container or value object in this document.

Conforming package readers shall not have an obligation to test the validity of any character strings expressed in extending children of File or File.Metadata that are presented file references

A conforming package reader shall not be obligated to interpret and process the content of extension classes. If a package reader does not process an extension object, it shall ignore the extension object without affecting processing of the remainder of the interchange package.

5. The 1EdTech Content Packaging conceptual model

(Informative)

Figure 5.1 is a conceptual diagram that illustrates the structure of the 1EdTech Content Packaging Information Model.

Figure 5.1 1EdTech Content Packaging conceptual model.

These core structural components are:

• Logical package – a representation of one or more units of usable (and reusable) content. The logical package encompasses the full set of components described by the manifest, including the local components and the remote components included by reference.

• Interchange package – the set of components that are to be exchanged between systems including the manifest and other selected files.

• Manifest – the component that describes a complete instance of a logical package. A manifest may contain references to components that are local or remote.

• Organizations – logical relationships among the units of content. More than one logical organization may be described.

• Resources – an inventory of content and files used by the parent manifest. The files may be local or remote.

• Child-manifests – complete and subordinate manifests that are contained within or referenced from a manifest. These each describe a complete logical package that is part of the larger logical package. The child-manifests may be local or remote.

• Files – computer files that embody the content described by the logical package or govern the binding of other files to make them suitable for machine processing. Content files may be local or remote.

• Meta-data – descriptive information about content packages, logical organizations, content, or files. In this diagram the meta-data box represents the set of local and/or remote meta-data objects that are contained within the logical package. Any binding of a meta-data object is permitted. Meta-data may be assigned to any of the core structures within the logical package including the manifest.

The information model defines these core structural components for describing and organizing content for exchange. An important underpinning is support for extensibility. Implementers of this specification may use these extension mechanisms to define new vocabulary terms and structures.

6. Class definitions and relationship requirements

An informative overview of the entire 1EdTech Content Packaging Information Model is provided as a Platform Independent Model (PIM) expressed in UML constructs. All UML diagrams expressed as “Platform Independent Model” are non-normative. Normative tables defining the classes in this Information Model follow the informative UML diagrams.

A full definition of the UML Profile and the terms used in the normative tabular descriptions in this document to describe the PIM can be found in [SDN07, 06].

In the tables in this section the character sequence “n / a” is used to mark a field “not applicable.” Any field so marked is not relevant to the class being defined. Features so marked shall be ignored when binding a class defined by this Information Model.

Augmented Backus-Naur form (ABNF) is used to define certain rules in the tables. Augmented Backus-Naur form is defined in [RFC2234].

6.1 Key terms and concepts

Classes in this information model are classified into four abstract class types. These abstractions are bound to specific data structures for machine processing in the 1EdTech Content Packaging XML Binding Version 1.2 [CP, 07b]. The four abstract class types are:

• container: A container class may be a parent of one or more child classes.

• value: A value class shall not be a parent. That is, it shall not be a composite of characteristic, container, value, or unspecified class types. A value class shall always be a child of a container class and shall have semantic value within the scope of its parent class’s semantic value.

• characteristic: A characteristic class shall not be a parent. A characteristic class shall declare a trait or value that is an intrinsic feature or part of a container class. A characteristic class is tightly coupled to the container class it modifies or one of which facets it describes.

• unspecified: An unspecified class may be a parent. An unspecified class serves as an extension point for this Information Model.

Table 6.1 lists the class descriptors used to describe the abstract classes and definitions of the descriptors.

Table 6.1 Class descriptors.


Descriptor	Definition
Class name	The name given to the class being described.
Class type	The abstract class type of this class.
Data type	For value and characteristic classes, the allowed structure for valid values for the class. Valid data types are: URI: Any syntactically valid instance of a URI as defined in RFC3986. Note: Many of the foundational Specifications, Standards, and Recommendations referred to by this Information Model use RFC2396 and RFC2732 as the definitions of URI. These are made obsolete by RFC3986, but many of the foundational documents have not been updated to reference RFC3986. LUID: An identifier that is locally unique within a manifest. This will be based upon the String data-type that has a constrained value-space. LUIDref: A reference to a LUID that has been defined elsewhere within a manifest. The value of the LUID and the LUIDref(s) that reference it shall be the same. Boolean: The primitive, two-valued data type that uses the keywords “true” and “false” to indicate the logical state of an object. String: A sequence of printable characters. unspecified: The data type is not known or is not important.
Value space	The range of valid values for this class. If the value space is unspecified, it is not known or is not important.
Multiplicity	A property of a class indicating the number of times it may be used or appear in a given parent context. The values of this property are expressed as a range or shorthand for a range using this notation: • ‘0..1’ [optional; restricted] • ‘0..unbounded’ [optional; unrestricted] • ‘1..1’ [mandatory; restricted] • ‘1..unbounded’ [mandatory; unrestricted] Multiplicities may also appear in short-hand notation in the UML models. The short-hand equivalents shall be (exclusive of bracketed comments): • ‘’ [optional; unrestricted] • ‘1’ [mandatory; restricted] • ‘1..’ [mandatory; unrestricted] Where multiplicity is greater than one, the importance of the ordering of siblings is also indicated by appending either “,”ordered or “,” unordered. ordered specifies a sequence of siblings as listed, unordered specifies a collection or bag of siblings. Order is not important.
Characteristic classes	Lists the characteristic classes associated with this class in the form “{“ characteristic *“,” characteristic “}”. One or more characteristics may be expressed within curly braces. Each characteristic shall be separated by a comma. Where more than one characteristic is listed, the importance of the ordering of siblings is also indicated by appending either “,”ordered or “,” unordered. ordered specifies sequence of siblings as listed, unordered specifies a collection or bag of siblings. Order is not important.
Parents	Lists classes that may be parents of this class.
Children	Lists the possible child classes of this class in the form “[” child *“,” child “]”. One or more child classes may be expressed within square brackets. Each child class shall be separated by a comma. Where more than one child is listed, the importance of the ordering of siblings is also indicated by appending either “,”ordered or “,” unordered. ordered specifies a sequence of siblings as listed, unordered specifies a collection or bag of siblings. Order is not important.
Description	Contains descriptions relating to the class and its values space.

6.2 Platform-independent model of the 1EdTech Content Packaging Information Model

Figure 6.1 is a visual summary of the structure of the 1EdTech Content Packaging Information Model.

Figure 6.1 Structural view of the Content Packaging PIM (overview).

The structural view in Figure 6.1 is focused on the relationships among the primary classes. It does not contain the details of the multiplicities, ordering, or attributes for the classes.

6.3 InterchangePackage class

Table 6.2 defines the InterchangePackage class in the 1EdTech Content Packaging Information Model.

Table 6.2 InterchangePackage class definition.


Descriptor	Definition
Class name	InterchangePackage
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	1..1
Characteristic classes	n / a
Parents	none
Children	[Manifest]
Description	An InterchangePackage object is the subset of a logical package that is exchanged between systems. An InterchangePackage shall meet the following conditions: a) The InterchangePackage shall include a Manifest object and may include content files and control files. b) Any file described in the Manifest using a URI that resolves to a location within the InterchangePackage shall be included in the InterchangePackage. c) All files included in an InterchangePackage shall be described in the Manifest. d) Files contained in the InterchangePackage may contain internal references to other files (e.g., a HTML content file may reference a JPEG content file, or an XML Schema control file may reference another XML Schema control file). When a file contained in an InterchangePackage references another file using a URI that resolves to a location within the InterchangePackage, the referenced file shall be described in the InterchangePackage’s Manifest. A package interchange file (PIF) is a particular instantiation of an InterchangePackage. Package readers and writers are not obliged to support the reading or writing of PIFs. A PIF shall meet the following conditions: a) Physical encapsulation shall be as a compressed binary file conforming to RFC1951. b) A PIF shall contain a single 1EdTech manifest document object at the root of the PIF. That object shall be bound as an XML document named imsmanifest.xml. This document is called the root 1EdTech manifest document for the PIF. c) Any control files included in the PIF shall be placed at the root of the PIF. d) All references from within the root 1EdTech manifest document to files contained in the PIF shall be via relative reference. The references shall be relative to the root of the PIF. e) A PIF shall not include any file with an absolute path (declared or resolved from a relative reference) higher than that of the 1EdTech manifest document object in the same hierarchical path, or when their absolute path is completely distinct from the location of an 1EdTech manifest document.

6.4 Manifest class family

This section defines the following classes in the 1EdTech Content Packaging Information Model:

• Manifest

• ManifestMetadata

• Schema

• SchemaVersion

• MetadataModel

This section also defines relationships with the following classes defined in Sections 6.5.1, 6.6.1, 6.9, and 6.10, respectively:

• Organizations

• Resources

• IPointer

• Extension

Figure 6.2 shows the Manifest class PIM.

Figure 6.2 Simplified view of the Manifest class PIM.

6.4.1 Manifest class

Table 6.3 defines the Manifest class in the 1EdTech Content Packaging Information Model.

Table 6.3 Manifest class definition.


Descriptor	Definition
Class name	Manifest
Class type	Container
Data type	n / a
Value space	n / a
Multiplicity	1..1 as child of InterchangePackage 0..unbounded as child of Manifest, unordered
Characteristic classes	{ Identifier, Version, Base, Other }, unordered
Parents	InterchangePackage Manifest
Children	[ ManifestMetadata, Organizations, Resources, Manifest, IPointer, Extension ], ordered
Description	A Manifest object is a container for the data structures that describe a complete instance of a logical package. A Manifest may contain child objects of the Manifest class (child-manifests). Child-manifests define complete instances of logical packages that are part of the larger logical package. A Manifest may also contain child objects of the IPointer class that reference child-manifests external to the Manifest. Any combination of child-manifests and externally referenced child-manifests are permitted and their order within the Manifest is not significant. Appropriate targets for an IPointer declared as a direct child of a Manifest are defined in Section 6.9. A Manifest may contain references to components that are local or remote to its ancestor InterchangePackage object. References are made via Resource, File, and IPointer child objects. Resource and File are used to reference content files and control files. IPointer is used to identify referenced-manifests. A Manifest shall contain File objects that describe all of the control files needed to interpret the Manifest.

6.4.2 ManifestMetadata class

Table 6.4 defines the ManifestMetadata class in the 1EdTech Content Packaging Information Model.

Table 6.4 ManifestMetadata class definition.


Descriptor	Definition
Class name	ManifestMetadata
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	0..1
Characteristic classes	n / a
Parents	Manifest
Children	[ Schema, SchemaVersion, IPointer, MetadataModel ], ordered
Description	A ManifestMetadata object contains descriptive information about its parent Manifest object. The scope of ManifestMetadata is the entire logical package described by the parent Manifest. The Schema and SchemaVersion children of ManifestMetadata provide information about the specification or profile that governs the meaning of the parent Manifest. A MetadataModel child of ManifestMetadata serves as a placeholder for general descriptive information about its parent Manifest. MetadataModel is an extension point that allows meta-data with an information structure that is defined in another namespace. Multiple, differing meta-data models may be declared as extensions contained within a single ManifestMetadata object. If the meta-data is defined in an external Metadata object, then the link to that object is achieved using an IPointer object. Any combination of MetadataModel and externally referenced meta-data is permitted and their order within the Metadata object is not significant Appropriate targets for IPointer declared as a child of ManifestMetadata are defined in Section 6.9.

6.4.3 Schema class

Table 6.5 defines the Schema class in the 1EdTech Content Packaging Information Model.

Table 6.5 Schema class definition.


Descriptor	Definition
Class name	Schema
Class type	value
Data type	string
Value space	repertoire of printable characters from [UCS]
Multiplicity	0..1
Characteristic classes	n / a
Parents	ManifestMetadata
Children	n / a
Description	A Schema object declares the name of a specification or profile for its parent Manifest object. The value of Schema informs a package reader of the specification or profile that governs the meaning of the Manifest. This value should not be confused with the name or label assigned to a given meta-data schema. No requirements are placed on the contents or syntax of a string declared as the value of a Schema, except that the string shall not include any versioning information. The default value shall be “1EdTech Content”.

6.4.4 SchemaVersion class

Table 6.6 defines the SchemaVersion class in the 1EdTech Content Packaging Information Model.

Table 6.6 SchemaVersion class definition.


Descriptor	Definition
Class name	SchemaVersion
Class type	value
Data type	string
Value space	repertoire of printable characters from [UCS]
Multiplicity	0..1
Is extension point	false
Characteristic classes	n / a
Parents	ManifestMetadata
Children	n / a
Description	A SchemaVersion object declares the version of the specification or profile that is declared as a value for its sibling Schema object. This value informs a package reader of the version of the model or profile identified by a sibling Schema. A value for SchemaVersion shall include no other information. The default value shall be “1.2” when “1EdTech Content” is declared as the value for its sibling Schema and the manifest document is governed by a binding of this Information Model. Neither a syntax for version information nor a heuristic for applying any versioning syntax is specified by this Information Model.

6.4.5 MetadataModel class

Table 6.7 defines the MetadataModel class in the 1EdTech Content Packaging Information Model.

Table 6.7 MetadataModel class definition.


Descriptor	Definition
Class name	MetadataModel
Class type	unspecified
Data type	unspecified
Value space	unspecified
Multiplicity	0..unbounded, ordering also unspecified
Characteristic classes	unspecified, ordering also unspecified
Parents	ManifestMetadata Metadata
Children	unspecified, ordering also unspecified
Description	A MetadataModel object is a placeholder. It informs bindings of this Information Model as to the valid locations for the inclusion of meta-data in an interchange package. The actual names of extending container or value class types comprising one or more meta-data models will be known only when a binding of those classes is imported into a bound instance of this Information Model. Hence, the actual type of class is unspecified in this Information Model. MetadataModel is used by two meta-data containers: ManifestMetadata and Metadata. MetadataModel is the only means for expressing meta-data models and associated information in a bound instance of this Information Model. A package writer may express as many different meta-data models as is needed to adequately describe the contents encapsulated by MetadataModel’s parent object. MetadataModel shall be used only for declaring one or more meta-data models and information associated with them. The semantics of MetadataModel shall stay within the semantics of its parent in this Information Model. The semantics of MetadataModel shall not override or redefine the semantics of its parent as defined in this Information Model.

6.5 Organizations class family

This section defines the following classes in the 1EdTech Content Packaging Information Model:

• Organizations

• Organization

• Title

• LingualTitle

• Item

It also defines relationships with the following classes defined in Sections 6.7, 6.9, and 6.10, respectively:

• Metadata

• IPointer

• Extension

Figure 6.3 shows the Organizations class PIM.

Figure 6.3 Simplified view of the Organizations class PIM.

6.5.1 Organizations class

Table 6.8 defines the Organizations class in the 1EdTech Content Packaging Information Model.

Table 6.8 Organizations class definition.


Descriptor	Definition
Class name	Organizations
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	1..1
Characteristic classes	{ Default, Other }, unordered
Parents	Manifest
Children	[ Organization, IPointer, Extension ], ordered
Description	An Organizations object is a container for classes describing logical relationships among Resources objects. More than one logical organization may be described using either Organization or IPointer children of Organizations. The order of Organization and IPointer objects is not significant. Organizations defined in referenced-manifests are identified using IPointer. Appropriate targets for IPointer declared as a child of Organizations are defined in Section 6.9.

6.5.2 Organization class

Table 6.9 defines the Organizations class in the 1EdTech Content Packaging Information Model.

Table 6.9 Organization class definition.


Descriptor	Definition
Class name	Organization
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	0..unbounded, ordered
Characteristic classes	{ Identifier, Structure, Other }, unordered
Parents	Organizations
Children	[ Title, LingualTitle, Item, IPointer, Metadata, Extension ], ordered
Description	An Organization object is a container for classes describing a particular logical relationship between the Resource objects encapsulated by a Manifest object. Multiple Organization objects are equivalent in purpose. Each shows a way for structuring the same set of Resource objects within a given Manifest, though each Organization should show a different structure. Item child objects are used to represent structural nodes within an Organization. Item objects defined in referenced-manifests are identified using IPointer objects. Any combination of Item and IPointer objects is permitted and the order of the objects is significant. Appropriate targets for IPointer declared as a child of an Organization are defined in Section 6.9. At least one child Item or IPointer shall be declared for each Organization.

6.5.3 Title class

Table 6.10 defines the Title class in the 1EdTech Content Packaging Information Model.

Table 6.10 Title class definition.


Descriptor	Definition
Class name	Title
Class type	value
Data type	string
Value space	repertoire of printable characters from [UCS]
Multiplicity	0..1
Characteristic classes	n / a
Parents	Organization Item
Children	n / a
Description	A Title object contains a textual value applied to an Organization or Item object to name or label the structures each represents. The textual value has no language type. The value of a Title is a string of characters. Implementers that desire one or more language-sensitive representations of a string of characters for a title should use the LingualTitle class.

6.5.4 LingualTitle class

Table 6.11 defines the LingualTitle class in the 1EdTech Content Packaging Information Model.

Table 6.11 LingualTitle class definition.


Descriptor	Definition
Class name	LingualTitle
Class type	value
Data type	string
Value space	repertoire of printable characters from [UCS]
Multiplicity	0..unbounded, unordered
Characteristic classes	{ Language }
Parents	Organization Item
Children	n / a
Description	A LingualTitle object contains a language-specific textual value applied to an Organization or Item object to name or label the structures each represents. The language of LingualTitle is specified by a Language object.

6.5.5 Item class

Table 6.12 defines the Item class in the 1EdTech Content Packaging Information Model.

Table 6.12 Item class definition.


Descriptor	Definition
Class name	Item
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	1..unbounded, ordered
Characteristic classes	{ Identifier, IdentifierRef, IsVisible, Parameters, Other }, unordered
Parents	Organization Item
Children	[ Title, Item, IPointer Metadata, Extension ], ordered
Description	An Item object is a container for representing a structural node in a particular Organization or in another Item object. Item objects may contain child Item or IPointer objects, each representing a unique structural node. Items defined in referenced-manifests are identified using the IPointer class. Any combination of Item and IPointer is permitted within an Item, and the order of the objects is significant. Appropriate targets for IPointer declared as a child of an Item are defined in Section 6.9. An Item may use an IdentifierRef object to express an internal reference to a Resource object that is to be associated with its structural role and position. An Item may use IdentifierRef to express an internal reference to a child-manifest object that is to be associated with its structural role and position. The result of the reference is as if: a) the referencing Item and all of its descendants are replaced with the collection of objects contained in the default Organization of the referenced child-manifest or the first Organization in the referenced child-manifest, if the referenced child-manifest does not have a default Organization; b) the sibling Item objects of the replaced referencing Item are displaced in the sequence of child objects by the indirectly referenced Item and its siblings. A package reader need not actually create a memory model or a data-storage model that mimics an actual splicing or joining of the two structures described above. However, the package reader shall interpret the reference as if the structure described above had been created.

6.6 Resources class family

This section defines the following classes in the 1EdTech Content Packaging Information Model:

• Resources

• Resource

• File

• Dependency

It also defines relationships with the following classes defined in Sections 6.7, 6.8, 6.9, and 6.10, respectively:

• Metadata

• Variant

• IPointer

• Extension

Figure 6.4 shows the Resources class PIM.

Figure 6.4 Simplified view of the Resources class PIM.

6.6.1 Resources class

Table 6.13 defines the Resources class in the 1EdTech Content Packaging Information Model.

Table 6.13 Resources class definition.


Descriptor	Definition
Class name	Resources
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	1..1
Characteristic classes	{ Base, Other }, unordered
Parents	Manifest
Children	[ Resource, IPointer, Extension ], ordered
Child grouping model	ordered
Description	A Resources object is a container for all information about files used by the parent Manifest object. The files may be local or remote. Resources describes files for its parent Manifest. Reference files in any other Manifest object, including Manifest objects that are siblings to, descendants of, or ancestors of the parent Manifest, are out of the Resources object’s scope. The Resource and IPointer children of the Resources object are used to describe a particular collection of files. IPointer is used to identify a Resource in a referenced-manifest. The order of the child Resource and IPointer objects is not significant. Appropriate targets for an IPointer child of a Resources object are defined in Section 6.9.

6.6.2 Resource class

Table 6.14 defines the Resource class in the 1EdTech Content Packaging Information Model.

Table 6.14 Resource class definition.


Descriptor	Definition
Class name	Resource
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	0..unbounded, unordered
Characteristic classes	{ Identifier, Type, Base, Href, Other }, unordered
Parents	Resources
Children	[ Metadata, File, Dependency, Variant, Extension ], ordered
Description	A Resource object is a container for information relating to a particular collection of files used by the ancestor Manifest object. Variant resources are identified using the Variant class. The relationship between the parent Resource and the set of Variant objects shall be described using meta-data in the variant resources. A value declared by a Resource{ Href } object is a launchable URI. A file reference declared in a Resource{ Href } shall have an associated declaration in a File object in the same Resource. The Href of the associated File object shall reference the same file as the Resource{ Href }. The Resource{ Href } and associated File{ Href } URIs may differ in that the Resource{ Href } may contain “launch” parameters in the URI.

6.6.3 File class

Table 6.15 defines the File class in the 1EdTech Content Packaging Information Model.

Table 6.15 File class definition.


Descriptor	Definition
Class name	File
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	0..unbounded, unordered
Characteristic classes	{ Href, Other }, unordered
Parents	Resource
Children	[ Metadata, Extension ], ordered
Description	A File object is a container for all information relating to a single computer file, encapsulated by its parent Resource object. A File holds meta-data describing a computer file and a reference to the location of the file.

6.6.4 Dependency class

Table 6.16 defines the Dependency class in the 1EdTech Content Packaging Information Model.

Table 6.16 Dependency class definition.


Descriptor	Definition
Class name	Dependency
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	0..unbounded, unordered
Is extension point	false
Characteristic classes	{ IdentifierRef, Other }, unordered
Parents	Resource
Children	[ Extension ]
Description	A Dependency object allows a Resource object to reference the collection of files described in a sibling Resource object. Dependency shall use an IdentifierRef object to reference a Resource or an IPointer object. The referenced Resource or IPointer shall be encapsulated by the Dependency’s grandparent Resources object. If the reference is to an IPointer, then the IPointer shall reference a Resource within the referenced–manifest. The result of the reference is that the files included in the scope of a referenced Resource shall be considered within the scope of the referencing Dependency’s parent Resource. The characteristic objects associated with the referenced Resource shall not be considered in scope of the referencing Dependency’s parent Resource.

6.7 Metadata Class

This section defines the Metadata class abstraction that is part of the 1EdTech Content Packaging Information Model. It also defines relationships with the following object defined in Section 6.9:

• IPointer

Figure 6.5 shows the Metadata class PIM.

Figure 6.5 Simplified view of the Metadata class PIM.

Table 6.17 defines the Metadata class in the 1EdTech Content Packaging Information Model.

Table 6.17 Metadata class definition.


Descriptor	Definition
Class name	Metadata
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	0..1
Characteristic classes	none
Parents	Organization Item Resource File
Children	[ IPointer, MetadataModel ], xor
Description	A Metadata object contains descriptive information about its parent containers-class-type object. The scope of Metadata is the parent container class only. The MetadataModel child object serves as a container for general descriptive information about its parent. MetadataModel is an extension point that allows meta-data with an information structure that is defined in another namespace. Multiple, differing meta-data models may be declared as extensions contained within a single MetadataModel object. If the meta-data is defined in an external object, then the link to that object is achieved using an IPointer object. Any combination of MetadataModel and externally referenced meta-data is permitted, and their order within the Metadata object is not significant. Appropriate targets for IPointer declared as a child of Metadata are defined in Section 6.9.

6.8 Variant class

This section defines the Variant class that is part of the 1EdTech Content Packaging Information Model. It also defines relationships with the following classes defined Sections 6.6.2 and 6.7, respectively:

• Resource

• Metadata

Figure 6.6 shows the Variant class PIM.

Figure 6.6 Simplified view of the Variant class PIM.

Table 6.18 defines the Variant class in the 1EdTech Content Packaging Information Model.

Table 6.18 Variant class definition.


Descriptor	Definition
Class name	Variant
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	1..unbounded, unordered
Characteristic classes	{ Identifier, IdentifierRef, Other }, unordered
Parents	Resource
Children	[ Metadata, Extension ], ordered
Description	A Variant object allows a Resource object to reference and describe a variant Resource object. A Variant shall use an IdentifierRef object to reference a Resource or an IPointer object. The referenced Resource or IPointer shall be encapsulated by the Variant’s grandparent Resources object. If the reference is to an IPointer, then the IPointer shall reference a Resource within the referenced–manifest. The Metadata child object for the Variant should be used to describe the relationship between the Variant and the parent Resource.

6.9 IPointer class

This section defines the IPointer class that is part of the 1EdTech Content Packaging Information Model. It also defines relationships with the following classes defined in Sections 6.4.1, 6.4.2, 6.7, 6.5.1, 6.5.2, 6.5.5, and 6.6.1, respectively:

• Manifest

• ManifestMetadata

• Metadata

• Organizations

• Organization

• Item

• Resources

Figure 6.7 shows the IPointer class PIM.

Figure 6.7 Simplified view of the IPointer class PIM.

Table 6.19 defines the IPointer class in the 1EdTech Content Packaging Information Model.

Table 6.19 IPointer class definition.


Descriptor	Definition
Class name	IPointer
Class type	container
Data type	n / a
Value space	n / a
Multiplicity	0..unbounded, ordered
Characteristic classes	{ Identifier, LinkType, LinkHref, Other }, unordered
Parents	Manifest ManifestMetadata Metadata Organizations Organization Item Resources
Children	n / a
Description	An IPointer object is a linking object. Its purpose is to identify a node set in a manifest document and associate that node set with its parent. The source of the identified node set may be either be local or remote. The node set that is identified by the IPointer shall be a valid child of the IPointer’s parent class (see Table 20).

Table 6.20 defines the permitted combinations of parent-class-to-target-class linking allowed using the IPointer class.

Table 6.20 Permitted linking combinations of parent/target classes.


Parent class of the IPointer class	Valid target nodeset for the IPointer class
Manifest	Manifest
Organizations	Organization
Organization	Item
Item	Item
Resources	Resource
ManifestMetadata	MetadataModel
Metadata	MetadataModel

6.10 Extension class

This section defines the Extension class placeholder that is part of the 1EdTech Content Packaging Information Model. Figure 6.8 shows the Extension class PIM.

Figure 6.8 Simplified view of the Extension class PIM.

Table 6.21 defines the Extension class in the 1EdTech Content Packaging Information Model.

Table 6.21 Extension class definition.


Descriptor	Definition
Class name	Extension
Class type	unspecified
Data type	unspecified
Value space	unspecified
Multiplicity	0..unbounded, ordered
Is extension point	true
Characteristic classes	unspecified, ordering also unspecified
Parents	Manifest Organizations Organization Item Resources Resource Variant File Dependency
Children	unspecified, ordering also unspecified
Description	An Extension object is a placeholder. It informs bindings of this Information Model as to the valid locations for the inclusion of value or container classes that extend any class of type container in this Information Model. The Extension class is one of two mechanisms for extending any class of type container in this Information Model. The second extension mechanism is the Other class. An Extension object is used to extend classes of type container. The actual name of an extending container or value class type used in place of an Extension object will be known only when a binding of that object is imported into a bound instance of this Information Model. Hence, the actual type of class is unspecified in this Information Model. The semantics of Extension shall stay within the scope of the semantics of its parent object in this Information Model. The semantics of Extension shall not override or redefine the semantics of any parent object defined in this Information Model.

6.11 Characteristic classes

6.11.1 Base class

Table 6.22 defines the Base class in the 1EdTech Content Packaging Information Model.

Table 6.22 Base class definition.


Descriptor	Definition
Class name	Base
Class type	characteristic
Data type	URI
Value space	Binding language dependent.
Multiplicity	0..1
Parents	Manifest Resources Resource
Description	A Base object is used to specify an object's base URI for the object with which Base is associated for the purpose of resolving relative references that appear in descendants of the associated object. The scope of Base’s value shall apply to all descendants of the object with which Base is associated, unless the value declared for Base is replaced or amended by a subsequent Base object in a permitted descendant. All relative path segments expressed as a value for Base shall resolve to the manifest document containing those expressions. Relative path segments shall be constructed in such a way that the segment expressed Base can be appended to a relative path segment expressed in the nearest ancestor object expressing a value in its Base object and so on up to the root Manifest object. The resulting sequence of collected relative path segments shall then be appended to the location at which the manifest document is located or being processed to create an absolute path. Relative references appearing within the scope of a Base object shall then be interpreted according to the rules defined in RFC3986.

6.11.2 Default class

Table 6.23 defines the Default class in the 1EdTech Content Packaging Information Model.

Table 6.23 Default class definition.


Descriptor	Definition
Class name	Default
Class type	characteristic
Data type	Binding language dependent (the default is string).
Value space	the value of an Organizations{ Default }.Organization{ Identifier } object
Multiplicity	0..1
Parents	Organizations
Description	A Default object designates a single child Organization object of an Organizations object as the primary or default organizing structure for a given Manifest object. The designation of a default Organization shall be done by referencing the value of the Identifier object of the target Organization object. A target Organization shall be a child of an Organizations object that has a Default. No other reference by Default shall be permitted. When a Default is not declared for an Organizations object, the first defined Organization object in an Organizations object shall be considered the primary or default organizing structure.

6.11.3 Href class

Table 6.24 defines the Href class in the 1EdTech Content Packaging Information Model.

Table 6.24 Href class definition.


Descriptor	Definition
Class name	Href
Class type	characteristic
Data type	URI
Value space	as defined by RFC3986.
Multiplicity, by parent object	0..1 : Resource 1..1 : File
Parents	Resource File
Description	An Href object is used to locate a resource. A value declared for Href shall be a syntactically valid URI. This document makes no guarantee that a string so declared is a valid URI or will resolve to an actual resource or part of a resource at the location so identified. A value declared for Manifest.Resources.Resource{Href} represents a URL that can be used to locate and access the content described by the resource. A package reader is not required to resolve the URI. The URI is meant to be stored for later use by other software components after the contents of an interchange package are processed. A value declared for Manifest.Resources.Resource.File{Href}shall be a locator for a single digital resource, with no other implication as to the use of the resource so identified.

6.11.4 Identifier class

Table 6.25 defines the Identifier class in the 1EdTech Content Packaging Information Model.

Table 6.25 Identifier class definition.


Descriptor	Definition
Class name	Identifier
Class type	characteristic
Data type	Binding language dependent Locally Unique Identifier (LUID).
Value space	Binding language dependent.
Multiplicity	1..1
Parents	Manifest Organization Item Resource IPointer Variant
Description	An Identifier object uniquely identifies that Identifier object’s parent within a Manifest object. That is, only one occurrence of a given value for an Identifier may occur within the same Manifest, including that Manifest’s child-manifest objects. A value for Identifier may be used for internal referencing from another object using an IdentifierRef object.

6.11.5 IdentifierRef class

Table 6.26 defines the IdentifierRef class in the 1EdTech Content Packaging Information Model.

Table 6.26 IdentifierRef class definition.


Descriptor	Definition
Class name	IdentifierRef
Class type	Characteristic
Data type	Binding language dependent reference to an existing LUID (LUIDref).
Value space	A value for an Identifier object in the IdentifierRef object’s immediately containing Manifest object, and as further constrained by internal referencing rules defined below.
Multiplicity, by parent objects	0..1 : Item 1..1 : Dependency 1..1 : Variant
Parents	Item Dependency Variant
Description	An IdentifierRef object shall duplicate exactly a value for an Identifier object that is a descendant of the IdentifierRef object’s immediately containing Manifest object. An object’s immediately containing Manifest is defined as the first encountered Manifest in the object’s chain of ancestors. The referenced Identifier may be in a child-manifest of the immediately containing Manifest. In addition, IdentifierRef is limited by the following internal referencing rules: A. An IdentifierRef child of an Item object may reference one of: i) A Resource or IPointer object that is a descendant of the referencing Item’s immediately containing Manifest object. ii) A Manifest or IPointer that is a descendant of the referencing Item’s immediately containing Manifest iii) A Resource or IPointer that is contained within a child-manifest object that is a descendant of the referencing Item’s immediately containing Manifest. No reference shall be allowed from an IdentifierRef of an Item in a child-manifest object to any object in an ancestor Manifest. B. An IdentifierRef child of a Dependency object: i) Shall reference only a Resource that is a sibling of the Dependency’s parent Resource. ii) Shall not reference the Dependency’s parent Resource. iii) Shall not reference any object in a Manifest that is a child or ancestor of the Dependency’s immediately containing Manifest. C. An IdentifierRef child of a Variant object: i) Shall reference only a Resource or IPointer that is a sibling of the Variant’s parent Resource. ii) Shall not reference the Variant’s parent Resource. iii) Shall not reference any object in a Manifest that is a child or ancestor of the Variant’s immediately containing Manifest.

The scoping rules for manifests and (sub)manifests are shown in Figure 6.9.

Figure 6.9 - Scoping rules for manifests and (sub)manifests.

6.11.6 IsVisible class

Table 6.27 defines the IsVisible class in the 1EdTech Content Packaging Information Model.

Table 6.27 IsVisible class definition.


Descriptor	Definition
Class name	IsVisible
Class type	Characteristic
Data type	Boolean
Value space	true (default) false
Multiplicity	0..1
Parents	Item
Description	An IsVisible object signals a rendering process of whether to display a text string declared in a sibling Title object or to visually indicate the existence of an Item object in any other way. No other behavior is imputed by this flag. There is no inheritance of visibility state declared by this IsVisible for any descendant Item of this IsVisible’s parent Item. A value of “true” shall be the default value for IsVisible, even if it is not declared in a bound instance of an Item. That is, the absence of IsVisible for a parent Item is the same as if IsVisible with a value of “true” had been declared for the Item. A value of “true” shall be interpreted to mean that the contents of a sibling Title should be displayed by a rendering application (i.e., Item{ IsVisible }.Title). A value of “false” shall be interpreted to mean that the contents of a sibling Title should not be displayed by a rendering application (i.e., Item{ IsVisible }.Title).

6.11.7 Language class

Table 6.28 defines the Language class in the 1EdTech Content Packaging Information Model.

Table 6.28 Language class definition.


Descriptor	Definition
Class name	Language
Class type	characteristic
Data type	string
Value space	The value space for the 1.3 Language element defined by IEEE 1484.12.1. The value space is defined by the following ABNF rules: language-id = lang-code *lang-sub-code ; lang-code is any language code defined by ISO 639–1 & 2 lang-sub-code = "-" country-code ; country-code is any country code defined by ; ISO 3166-1
Multiplicity	1
Parents	LingualTitle
Description	A Language object identifies the human language of the string contained in the parent LingualTitle object.

6.11.8 LinkHref class

Table 6.29 defines the LinkHref class in the 1EdTech Content Packaging Information Model.

Table 6.29 LinkHref class definition.


Descriptor	Definition
Class name	LinkHref
Class type	characteristic
Data type	URI
Value space	Binding language dependent. Constrained by the external referencing rules defined below.
Multiplicity	1
Parents	IPointer
Description	A LinkHref object unambiguously identifies a set of objects in a manifest, either in the same or a different (“remote”) manifest document. A value declared for LinkHref shall be a syntactically valid absolute or relative reference. Because the URL has no location constraints, the scope of the characteristic is global.

6.11.9 LinkType class

Table 6.30 defines the LinkType class in the 1EdTech Content Packaging Information Model.

Table 6.30 LinkType class definition.


Descriptor	Definition
Class name	LinkType
Class type	characteristic
Data type	string
Value space	Binding language dependent.
Multiplicity	0..1
Parents	IPointer
Description	A LinkType object provides a place to declare a term or keyword (e.g., a vocabulary word or phrase) to which special meaning has been assigned. 1EdTech Content Packaging shall use the “simple” keyword as a value for this object. Linktype's scope is limited to its parent. NOTE A simple link is a link that associates exactly two resources, one local and one remote, with an arc going from the former to the latter. Thus, a simple link is always an outbound link.

6.11.10 Other class

Table 6.31 defines the Other class in the 1EdTech Content Packaging Information Model.

Table 6.31 Other class definition.


Descriptor	Definition
Class name	Other
Class type	characteristic
Data type	unknown to this Information Model
Value space	unknown to this Information Model
Multiplicity	0..unbounded
Parents	Manifest Metadata Organizations Organization Item Resources Resource File Dependency
Description	An Other object is an extension point for characteristics of a container class declared as the logical equivalents of characteristic classes. Other is a placeholder. It informs bindings of this Information Model as to the valid locations for the introduction of characteristic classes that are defined by an information model other than this Information Model. The actual name of an extending characteristic class type used in its place will be known only when a binding of that class is imported into a bound instance of this Information Model. The semantics of any extending characteristic class shall stay within the scope of the semantics of a parent class per that class’s definition in this Information Model. The semantics of any extending characteristic class shall not override or redefine the semantics of any parent class defined in this Information Model. The scope of Other is limited to its parent object.

6.11.11 Parameters class

Table 6.32 defines the Parameters class in the 1EdTech Content Packaging Information Model.

Table 6.32 Parameters class definition.


Descriptor	Definition
Class name	Parameters
Class type	characteristic
Data type	string
Value space	See description below.
Multiplicity	0..1
Parents	Item
Description	A Parameters object provides a place to declare certain static, application-specific information that shall always be associated with an Item object. The parameters are not defined by this Information Model. Typically, the parameters are defined for use by an application that works with the information declared by an Item, including any files specified in any Resource object referenced by the Parameters’s parent Item. The characters expressed as a value declared for a Parameters should be URI-encoded as defined in RFC3986. The scope of Parameters is limited to its parent object.

6.11.12 Structure class

Table 6.33 defines the Structure class in the 1EdTech Content Packaging Information Model.

Table 6.33 Structure class definition.


Descriptor	Definition
Class name	Structure
Class type	characteristic
Data type	string
Value space	See description below.
Multiplicity	0..1
Is extension point	false
Parents	Organization
Description	A Structure object describes the particular way that Item objects relate to each other within an Organization object. The scope of the Structure characteristic is limited to the parent Organization. The value space for Structure includes terms approved by 1EdTech Consortium, Inc. and made available to the public in a controlled list [SDN11, 06]. The syntax and semantics of the approved list of terms shall be supported by all software components implementing this Information Model. The value space for Structure may be extended. Such extending expressions may be created and used only when no approved 1EdTech value satisfies the expressive need of an implementing community to define the shape of a collection of Item objects in a given Organization. Extending expressions used as a value for Structure shall follow the URI syntax rule defined in Section 3 of RFC3986. The syntax for terms extending the Structure value space shall disclose the source of a term as a URI and the term itself as a URI fragment: scheme://authority/hierarchy#term.

6.11.13 Type class

Table 6.34 defines the Type class in the 1EdTech Content Packaging Information Model.

Table 6.34 Type class definition.


Descriptor	Definition
Class name	Type
Class type	characteristic
Data type	string
Value space	See description below.
Multiplicity	1..1
Parents	Resource
Description	A Type object provides a term, keyword, or phrase that indicates the type of resource being described by the parent Resource object. The value space for Type includes the terms approved by 1EdTech Consortium, Inc. and made available to the public in a controlled list [SDN11, 06]. The syntax and semantics of the approved list of terms shall be supported by all software components implementing this Information Model. The value space for Type may be extended beyond that in the controlled list. Such extending expressions may be created and used only when no approved 1EdTech value satisfies the expressive need of an implementing community. Extending expressions used as a value for Type shall follow the URI syntax rule defined in Section 3 of RFC3986. The syntax for terms extending the Type value space shall disclose the source of a term as a URI and the term itself as a URI fragment: scheme://authority/hierarchy#term. The scope of the Type characteristic is limited to the parent object. In particular, semantics expressed in a value for Type are not transmitted or “inherited” through the use of a Resource.Dependency{ IdentifierRef } reference.

6.11.14 Version class

Table 6.35 defines the Version class in the 1EdTech Content Packaging Information Model.

Table 6.35 Version class definition.


Descriptor	Definition
Class name	Version
Class type	characteristic
Data type	string
Value space	repertoire of printable characters from [UCS]
Multiplicity	0..1
Parents	Manifest
Description	A Version object holds a value that signifies a distinctive version of a Manifest object. When this characteristic is declared for a Manifest that is a child of an InterchangePackage object, the value is the version of an 1EdTech manifest document. When this characteristic is declared for any child-manifest, it is specific to that Manifest only and not to the entire document in which that child of Manifest resides. A syntax for version information is not specified by this document. Implementers are allowed to use any syntactical representation that meets their needs. The scope of Version is limited to its parent object.

Annex A Bibliography

(informative)

[CP, 07b]	1EdTech Content Packaging XML Binding Version 1.2 Public Draft 2.0, B. Nielsen, W. Kraan, J.Day and C.Smythe, 1EdTech GLC, Inc., 2007. http://www.imsglobal.org/content/packaging/index.html
[CP, 07c]	1EdTech Content Packaging Best Practices and Implementation Guide Version 1.2 Public Draft 2.0, B. Nielsen, W. Kraan, J.Day and C.Smythe, 1EdTech GLC, Inc., 2007. http://www.imsglobal.org/content/packaging/index.html
[VDEX, 04c]	1EdTech Vocabulary Definition Exchange Best Practice and Implementation Guide, Version 1.0 Final Specification, A. Cooper, 1EdTech GLC, Inc., 2005. http://www.imsglobal.org/vdex/vdexv1p0/imsvdex_bestv1p0.html
[CP, 04a]	1EdTech Content Packaging Information Model v1.1.4, C.Smythe, A.Jackl, 1EdTech GLC, Inc., October 2004. http://www.imsglobal.org/content/packaging/index.html
[CP, 04b]	1EdTech Content Packaging XML Binding v1.1.4, C.Smythe, A.Jackl, 1EdTech GLC, Inc., October 2004. http://www.imsglobal.org/content/packaging/index.html
[SCORM, 04]	Sharable Content Object Reference Model (SCORM) 2004, second edition, Advanced Distributed Learning, July 2004.

About this document

the document properties


Title	1EdTech Content Packaging Information Model
Editors	Colin Smythe (1EdTech), Boyd Nielsen (Independent)
Co-chairs	Wilbert Kraan (JISC/CETIS), Jan Poston Day (Blackboard), Nigel Ward (DEST)
Version	v1.2 (Public Draft v2.0)
Version Date	01 March 2007
Status	Public Draft v2.0
Summary	This document describes the 1EdTech Content Packaging v1.2 Information Model objects, their relationships, and purpose. It also defines selected behaviors of software components that create or process 1EdTech content packages and 1EdTech manifest documents.
Revision Information	04 December 2006
Purpose	This document is circulated for public comment. This document is the formal description of the 1EdTech Content Packaging v1.2 Information Model. Organizations are encouraged to implement this version of the specification and to provide feedback on their experience.
Document Location	http://www.imsglobal.org/content/packaging/index.html

List of contributors

The following individuals contributed to the development of this document:

Name	Organization	Name	Organization
Martin Bayly	WebCT, Canada	Steve Hirst	Pearson Education, USA
Bill Bilic	WebCT, Canada	Scott Lewis	ADL, USA
Kerry Blinco	DEST, Australia	Wilbert Kraan	CETIS / JISC, UK
Jennifer Brooks	ADL, USA	Sheila MacNeill	CETIS / JISC, UK
Daniel Burgos	UNFOLD / OUNL, NL	Boyd Nielsen	Independent, USA
Adam Cooper	Tribal Technology, UK	Allyn Radford	HarvestRoad, Australia
Jan Poston Day	Blackboard, USA	Colin Smythe	1EdTech, UK
Philip Dodds	ADL, USA	Schawn Thropp	ADL, USA
Andy Heath	Independent, UK	Nigel Ward	DEST, Australia

Revision history

Version No.	Release Date	Comments
Final 1.0	25 May 2000	The initial release of the CP specification.
Final 1.1	19 April 2001	The first revision of the CP specification.
Final 1.1.1	23 May 2001	The first maintenance release of CP v1.1. There were no functional additions.
Final 1.1.2	08 August 2001	The second maintenance release of CP v1.1. There were no functional additions.
Final 1.1.3	12 June 2003	The third maintenance release of CP v1.1. There were no functional additions. The issues resolved were sourced from the 1EdTech maintenance database.
Final 1.1.4	04 October 2004	The fourth maintenance release of CP v1.1. There were no functional additions. The issues resolved were sourced from the 1EdTech maintenance database.
Public Draft 1.2 v1.0	21 November 2005	The initial v1.2 Public Draft version that was released to solicit initial feedback on the proposed changes in CP v1.2.
Internal Draft 1.2 v2.0	01 March 2007	The final v1.2 Internal Draft version that is issued to promote feedback of experience of implementation.

Index

Behavior 6, 40, 46

Best Practice Guide 6, 45

Binding 6, 8, 9, 10, 13, 14, 21, 22, 35, 36, 37, 38, 41, 42, 45

child-manifest 5, 8, 9, 13, 19, 26, 37, 38, 44

Conformance 6, 12

Content Package 5, 9, 10, 13, 46

control file 8, 9, 17, 19

CSS 8

Extension 6, 10, 12, 13, 14, 20, 21, 29, 30, 34, 35, 42, 43

IEEE 7, 40

1EdTech Specifications

Content Packaging 1, 5, 6, 9, 12, 13, 14, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 34, 35, 36, 37, 39, 40, 41, 42, 43, 44, 45, 46, 47

Vocabulary Definition Exchange 5, 45

imsmanifest 17

Information Model 1, 5, 6, 12, 13, 14, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 34, 35, 36, 37, 39, 40, 41, 42, 43, 44, 45, 46

interchange package 5, 8, 9, 10, 12, 22, 37

IPointer 18, 19, 20, 22, 24, 26, 28, 29, 30, 32, 33, 37, 38, 41

ISO 7, 40

launchable URI 8, 10, 28

Learning 5, 10

logical package 8, 9, 10, 13, 17, 19, 20

Manifest 8, 9, 10, 13, 14, 17, 21, 26, 28, 29, 32, 33, 36, 41, 44, 46

Namespace 6, 9, 12, 20, 30

Normative 14

package interchange file 8, 9, 17

package reader 8, 9, 12, 20, 21, 26, 37

package writer 10, 22

Profile 20, 21

reference 8, 9, 10, 13, 14, 17, 19, 26, 28, 29, 32, 36, 38, 41, 44

Resource 5, 8, 9, 10, 37, 44

Resources 5, 9, 10, 28, 41

Schema 8, 20

SCORM 2, 5, 11, 45

Standards 6

Structure 6, 9, 13, 14, 16, 20, 24, 26, 30, 36

URI 7, 8, 10, 11, 14, 17, 28, 35, 36, 37, 41, 42, 43, 44

XML 6, 8, 9, 11, 14, 17, 45

Citations in brackets correspond to those in Section 2 and Annex A.

1EdTech Consortium, Inc. (“1EdTech GLC”) is publishing the information contained in this document (“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 Content Packaging v1.2 Information Model Public Draft v2.0
Date: 1 March 2007