![]() |
1EdTech Content Packaging Information Model
|
Date Issued: |
01 March 2007 |
Latest Version: |
|
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.
Intellectual property acknowledgements 2
1.4 Structure of this document 6
3. Definitions, acronyms, and abbreviations 8
3.1.15 package interchange file (PIF) 9
3.1.22 stand-alone resource 10
3.2 Acronyms and abbreviations 10
4.2 Interchange package instances 12
5. The 1EdTech Content Packaging conceptual model 13
6. Class definitions and relationship requirements 14
6.2 Platform-independent model of the 1EdTech Content Packaging Information Model 16
6.3 InterchangePackage class 16
6.4.2 ManifestMetadata class 19
6.5 Organizations class family 22
6.11 Characteristic classes 35
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]1
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).
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].
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:
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. |
Codes for the representation of names of languages – Part 1: Alpha-2 code |
|
Codes for the representation of names of languages – Part 2: Alpha-3 code |
|
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
A Manifest object with contents that are structured according to an 1EdTech Content Packaging XML binding.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 |
Sharable Content Object Reference Model |
|
UML |
Unified Modeling Language |
Uniform Resource Identifier |
|
Extensible Markup Language |
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.
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.
A conforming reader of interchange packages shall read and interpret interchange packages as defined in Section 6.
A conforming writer of interchange packages shall write interchange packages instances that conform with the Information Model described in Section 6.
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].
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.
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.
Table 6.2 defines the InterchangePackage class in the 1EdTech Content Packaging Information Model.
Table 6.2 InterchangePackage class definition.
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
• Extension
Figure 6.2 shows the Manifest class PIM.
Figure 6.2 Simplified view of the Manifest class PIM.
Table 6.3 defines the Manifest class in the 1EdTech Content Packaging Information Model.
Table 6.3 Manifest class definition.
Table 6.4 defines the ManifestMetadata class in the 1EdTech Content Packaging Information Model.
Table 6.4 ManifestMetadata class definition.
Table 6.5 defines the Schema class in the 1EdTech Content Packaging Information Model.
Table 6.5 Schema class definition.
Table 6.6 defines the SchemaVersion class in the 1EdTech Content Packaging Information Model.
Table 6.6 SchemaVersion class definition.
Table 6.7 defines the MetadataModel class in the 1EdTech Content Packaging Information Model.
Table 6.7 MetadataModel class definition.
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
• Extension
Figure 6.3 shows the Organizations class PIM.
Figure 6.3 Simplified view of the Organizations class PIM.
Table 6.8 defines the Organizations class in the 1EdTech Content Packaging Information Model.
Table 6.8 Organizations class definition.
Table 6.9 defines the Organizations class in the 1EdTech Content Packaging Information Model.
Table 6.9 Organization class definition.
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. |
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. |
Table 6.12 defines the Item class in the 1EdTech Content Packaging Information Model.
Table 6.12 Item class definition.
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
• Extension
Figure 6.4 shows the Resources class PIM.
Figure 6.4 Simplified view of the Resources class PIM.
Table 6.13 defines the Resources class in the 1EdTech Content Packaging Information Model.
Table 6.13 Resources class definition.
Table 6.14 defines the Resource class in the 1EdTech Content Packaging Information Model.
Table 6.14 Resource class definition.
Table 6.15 defines the File class in the 1EdTech Content Packaging Information Model.
Table 6.15 File class definition.
Table 6.16 defines the Dependency class in the 1EdTech Content Packaging Information Model.
Table 6.16 Dependency class definition.
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:
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.
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.
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.
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.
Manifest |
Manifest |
Organizations |
Organization |
Organization |
Item |
Item |
Item |
Resources |
Resource |
ManifestMetadata |
MetadataModel |
Metadata |
MetadataModel |
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.
Table 6.22 defines the Base class in the 1EdTech Content Packaging Information Model.
Table 6.22 Base class definition.
Table 6.23 defines the Default class in the 1EdTech Content Packaging Information Model.
Table 6.23 Default class definition.
Table 6.24 defines the Href class in the 1EdTech Content Packaging Information Model.
Table 6.24 Href class definition.
Table 6.25 defines the Identifier class in the 1EdTech Content Packaging Information Model.
Table 6.25 Identifier class definition.
Table 6.26 defines the IdentifierRef class in the 1EdTech Content Packaging Information Model.
Table 6.26 IdentifierRef class definition.
The scoping rules for manifests and (sub)manifests are shown in Figure 6.9.
Figure 6.9 - Scoping rules for manifests and (sub)manifests.
Table 6.27 defines the IsVisible class in the 1EdTech Content Packaging Information Model.
Table 6.27 IsVisible class definition.
Table 6.28 defines the Language class in the 1EdTech Content Packaging Information Model.
Table 6.28 Language class definition.
Table 6.29 defines the LinkHref class in the 1EdTech Content Packaging Information Model.
Table 6.29 LinkHref class definition.
Table 6.30 defines the LinkType class in the 1EdTech Content Packaging Information Model.
Table 6.30 LinkType class definition.
Table 6.31 defines the Other class in the 1EdTech Content Packaging Information Model.
Table 6.31 Other class definition.
Table 6.32 defines the Parameters class in the 1EdTech Content Packaging Information Model.
Table 6.32 Parameters class definition.
Table 6.33 defines the Structure class in the 1EdTech Content Packaging Information Model.
Table 6.33 Structure class definition.
Table 6.34 defines the Type class in the 1EdTech Content Packaging Information Model.
Table 6.34 Type class definition.
Table 6.35 defines the Version class in the 1EdTech Content Packaging Information Model.
Table 6.35 Version class definition.
(informative)
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
Sharable Content Object Reference Model (SCORM) 2004, second edition, Advanced Distributed Learning, July 2004. |
the document properties
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 |
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
Content Package 5, 9, 10, 13, 46
Extension 6, 10, 12, 13, 14, 20, 21, 29, 30, 34, 35, 42, 43
1EdTech Specifications
Vocabulary Definition Exchange 5, 45
interchange package 5, 8, 9, 10, 12, 22, 37
IPointer 18, 19, 20, 22, 24, 26, 28, 29, 30, 32, 33, 37, 38, 41
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
package interchange file 8, 9, 17
package reader 8, 9, 12, 20, 21, 26, 37
reference 8, 9, 10, 13, 14, 17, 19, 26, 28, 29, 32, 36, 38, 41, 44
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
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