![]() |
1EdTech Content Packaging Best Practice and Implementation Guide Version 1.2 Public Draft v2.0 |
Date Issued: |
01 March 2007 |
Latest Version: |
|
Supersedes: |
1EdTech Content Packaging Best Practice and Implementation Guide 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
“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.
“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.3 Structure of this document 4
1.4 Backwards and forwards compatibility 4
1.6 Referencing external information – the IPointer element 5
3. Stylistic conventions, acronyms, and abbreviations 9
3.2 Acronyms and abbreviations 9
4. Using content packages - use cases and practices 10
4.2 Keeping control over resources after a package has been published 10
4.3 Aggregate content at an appropriate level of granularity 11
4.5 Working with child-manifests and applying sequencing rules using the new IPointer mechanism 14
4.6 Packaging METS and other complex object encodings 16
4.7 Using alternative organization structures, such as topic maps 17
4.8 Working with alternative resources 18
4.9 Avoiding repeated lists of the same assets for different resources 20
4.10 Working with local and global identifiers 21
4.11 Support for multiple languages in titles 22
It is expected that people using this document will already be somewhat familiar with the 1EdTech Content Packaging Specification. For a concise overview of the specification, 1EdTech Content Packaging Specification Primer version 1.2 [CP, 07d]1 is recommended.
This document is informative.
The primary focus of this Best Practice and Implementation Guide is on sharing existing best practice and providing suggested practice for implementing the new functionality included in this version of the specification. 1EdTech content packages have been commonly used in the e-Learning domain. It is hoped that the changes in this release can help broaden the use of content packaging into other domains. This guide focuses on the construction of instances of 1EdTech manifest documents and the 1EdTech content packages they define.
Applications that create 1EdTech manifests and produce 1EdTech content packages are referred to generically as 1EdTech package writers in this guide. Similarly, applications that interpret 1EdTech manifests and consume 1EdTech content packages are referred to as 1EdTech package readers. Finally, applications and systems that create and consume 1EdTech content packages referred to as 1EdTech packagers. 1EdTech package writers and readers may be components of learning management systems (LMSs).
This guide presents examples of use cases and shows how they are satisfied by the 1EdTech Content Packaging Specification. The use cases were contributed by various implementers and users of the specification and are based on years of practice. Though not exhaustive, the range of use cases presented here illustrate how the most common issues in the creation, management, and playback of learning material can be addressed with the specification.
1.3 Structure of this document
The structure of the rest of this document is:
1.4 Backwards and forwards compatibility
Given the widespread adoption of 1EdTech Content Packaging and the proliferation of hundreds of thousands of 1EdTech content packages, it is important that existing software components continue to process content packages they were designed to handle, and that new software components conforming to version 1.2 also process the older content packages as designed. Newer systems will need the ability to process the new extension objects introduced in v1.2 that enable linking and referencing behaviors. The functionality of these new extension objects are described in the Section 4 of this document, and normative descriptions are contained within the 1EdTech Content Packaging Information Model [CP, 07a].
The new extension objects are defined in a separate namespace that leverages the extension points and semantics of 1EdTech Content Packaging without affecting the existing 1EdTech Content Packaging namespace. Version1.2 also separates the lists of vocabulary terms used by certain objects in the information model (and a dedicated new namespace) from the model itself. The details of which are contained the 1EdTech GLC Specification Development Note 11: Vocabulary Definition, Registration, and Maintenance Procedures [SDN11, 06].
By taking this approach we hope that the best of the past is preserved as it provides a strong foundation for future growth without having to alter its structural integrity. (A detailed, normative description of backwards and forwards compatibility is contained in the 1EdTech Content Packaging Information Model.)
The new functionality and clarifications incorporated into v1.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:
i) Interpretation of an item pointing to a child-manifest has been clarified.
ii) New functionality allowing components of child-manifests to be precisely referenced and interpreted has been introduced.
iii) Support for external child-manifests has been added.
d) Support for external referenced meta-data files has been introduced.
e) All internal vocabularies have been removed and they 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].
f) A new Resource type of “stand-alone” has been added that allows another package to be used as a piece of content.
g) The syntax and usage of the Base, Parameter, IsVisible, and Href Information Model classes has been clarified.
h) Support for variant Resource objects has been added. This includes support for alternative resources for accessible content.
i) Support for Organization and Item titles in multiple languages has been included.
j) Support for interchange packages that contain only content and interchange packages that have no local content files has been clarified.
1.6 Referencing external information – the IPointer element
Several communities of practice find benefit in reusing stored assets and parts of different presentation structures found in various instances of 1EdTech manifest documents, whether they are stored inside of package interchange files (PIFs) or as an Extensible Markup Language (XML) document in a file storage system. With the new IPointer object, 1EdTech Content Packaging v1.2 lets these communities reference information held in other 1EdTech manifest documents in an interoperable way.
An IPointer makes an association between two manifests. An 1EdTech package reader then relates the two manifests as indicated by the location of a linking object in one manifest and the target set of objects in the referenced manifest. The data is recovered from both documents for processing and storage.
For example, to associate a set of Item objects contained in another 1EdTech manifest document with an Organization object in your own manifest, you (or your 1EdTech package writer) would declare an IPointer child extension to Organization that points to the collection of Item objects in the remote or child-manifest. IPointer objects can be either local or remote i.e. contained within the PIF itself or within another package.
An IPointer may be placed only in certain other objects and target certain others. The Information Model defines the normative mechanisms for using IPointer. The following chart lists the valid locations and targets of an IPointer. The source and targets are identified by their object names.
Manifest |
Manifest |
Organizations |
Organization |
Organization |
Item |
Item |
Item |
Resources |
Resource |
ManifestMetadata |
MetadataModel |
Metadata |
MetadataModel |
Section 4 of this document illustrates a number of contextualized examples of how IPointer is used.
1EdTech AccessForAll Meta-data Information Model Version 1.0 Final Specification, J.Treviranus, A.Roberts, 1EdTech GLC, Jul 2004. http://www.imsglobal.org/accessibility/accmdv1p0/imsaccmd_infov1p0.html |
|
1EdTech Content Packaging Information Model version 1.2 Public Draft v2.0, B.Nielsen, W.Kraan, N.Ward, 1EdTech GLC, 2007. http://www.imsglobal.org/content/packaging/index.html |
|
1EdTech Content Packaging XML Binding version 1.2 Public Draft v2.0, B.Nielsen, W.Kraan, N.Ward, 1EdTech GLC, 2007. http://www.imsglobal.org/content/packaging/index.html |
|
1EdTech Content Packaging Primer version 1.2 Public Draft v2.0, B.Nielsen, W.Kraan, N.Ward, 1EdTech GLC, 2007. http://www.imsglobal.org/content/packaging/index.html |
|
[EP, 05b] |
1EdTech ePortfolio XML Binding version 1.0 Final Specification, C. Smythe, D.Cambridge, M.McKell, 1EdTech GLC, 2005. http://www.imsglobal.org/ep/epv1p0/imsep_bindv1p0.html |
“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/IEC 13250, 06] |
ISO/IEC 13250–2:2006, “Information technology—Topic Maps—Part 2: Data Model.” |
[ISO/IEC FDIS 21000, 05] |
ISO/IEC FDIS 21000–2:2005, “Information Technology—Multimedia Framework—Part 2: Digital Item Declaration.” |
[LD, 03a] |
1EdTech Learning Design Information Model version 1.0 Final Specification, R.Koper, B.Olivier, T.Anderson, 1EdTech GLC, 2003. http://www.imsglobal.org/learningdesign/ldv1p0/imsld_infov1p0.html |
[LD, 03c] |
1EdTech Learning Design Best Practice and Implementation Guide version 1.0 Final Specification, R. Koper, B. Olivier, T. Anderson, 1EdTech GLC, 2003. http://www.imsglobal.org/learningdesign/ldv1p0/imsld_infov1p0.html |
1EdTech Learner Information Packaging Information Model version 1.0 Final Specification, C.Smythe, F.Tansey, R.Robson, 1EdTech GLC, 2001. http://www.imsglobal.org/profiles/lipinfo01.html |
|
[METS] |
“Metatdata Encoding & Transmission Standard” v. 1.6. http://www.loc.gov/standards/mets/ |
1EdTech Question and Test Interoperability Information Model – Version 2.0 Final Specification,” S.Lay, 1EdTech GLC, 2005. http://www.imsglobal.org/question/qti_v2p0/imsqti_infov2p0.html |
|
1EdTech Question and Test Interoperability XML Binding – Version 2.0 Final Specification, S.Lay, 1EdTech GLC, 2005. http://www.imsglobal.org/question/qti_v2p0/imsqti_bindv2p0.html |
|
1EdTech Question and Test Interoperability Integration Guide – Version 2.0 Final Specification, S.Lay, 1EdTech GLC, 2005. http://www.imsglobal.org/question/qti_v2p0/imsqti_intgv2p0.html |
|
1EdTech Question and Test Interoperability Meta-data and Usage Data – Version 2.0 Final Specification,” S.Lay, 1EdTech GLC, 2005. http://www.imsglobal.org/question/qti_v2p0/imsqti_mdudv2p0.html |
|
[RDF, 04] |
“RDF/XML Syntax Specification (Revised),” W3C Recommendation 10 February 2004. http://www.w3.org/TR/rdf-syntax-grammar/ |
[RFC3986, 05] |
“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 |
[Schema, 04] |
“XML Schema Part 2: Datatypes Second Edition,” W3C recommendation 28 October 2004. http://www.w3.org/TR/xmlschema-2/ |
[SDN11, 06] |
1EdTech GLC Specification Development Note 11: Vocabulary Definition, Registration, and Maintenance Procedures, C.Smythe, v1.0, 1EdTech GLC, July 2006. |
[SS, 03c] |
1EdTech Simple Sequencing Best Practice and Implementation Guide – Version 1.0 Final Specification,” M.Norton, C.Ostyn, A.Panar, B.Towle, 1EdTech GLC, 2003. http://www.imsglobal.org/simplesequencing/ssv1p0/imsss_bestv1p0.html |
1EdTech Vocabulary Definition Exchange Best Practice and Implementation Guide, Version 1.0 Final Specification,” A.Cooper, 1EdTech GLC, 2005. http://www.imsglobal.org/vdex/vdexv1p0/imsvdex_bestv1p0.html |
3. Stylistic conventions, acronyms, and abbreviations
The names of information model components and the tag names and their attribute names in the XML Schema binding are signified by a bold face font and capitalization. Whenever a common term occurs in body text that uses the same spelling, if the term is in bold face and capitalized, the reader should use the definition of the XML Binding [CP, 07b] of the Information Model component; if not, the reader should use the meaning or meanings typically specified in any standard dictionary of the English language or in common use in the e-Learning domain.
Example:
• “File” refers to the 1EdTech Content Packaging object File.
• “file” may refer to a digital object identified by a Uniform Resource Identifier (URI) [RFC3986, 05], a physical object to hold papers, a physical object used to ablate a surface, etc.
3.2 Acronyms and abbreviations
Learning Object Metadata |
|
METS |
Metadata Encoding and Transport Schema |
PIF |
|
SCO |
sharable content object |
Sharable Content Object Reference Model |
|
Uniform Resource Identifier |
|
Extensible Markup Language |
|
4. Using content packages - use cases and practices
The use cases in this section illustrate key areas of the new and existing functionality of the 1EdTech Content Packaging Specification by focussing on particular goals that users of the specification may have and then outlining how such goals can be achieved. The section is not exhaustive either in illustrating all features of the specification or in outlining all uses of a specific feature.
A classic package typically includes all its resources in the PIF and uses a ZIP archive for its interchange format. It has only one level of manifest; no child-manifests are included. All Item objects are either declared or assumed to be visible. When material needs to be presented in more than one language or accessibility modality, two Organization objects tend to be included to separate them.
Content packages that comply with the most popular content-packaging profile, the Sharable Content Object Reference Model (SCORM), also typically follow this simple pattern. Where they differ from packages that follow other profiles is in the inclusion of meta-data: SCORM packages have package-level meta-data in a separate file that is referenced by the manifest. Other profiles typically include package-level meta-data inline in the manifest itself. Other differences include the support SCORM packages have for learner-to-content interaction tracking and, in SCORM 2004, 1EdTech Simple Sequencing [SS, 03c].
Content packages of this type are likely to be most widely supported in various LMSs, and therefore, the most robust in interoperability
Note: The “Simple_Manifest_Core” package in the set of examples that is included with this specification is a typical instance of a classic package. The example packages are available on the 1EdTech website: http://www.imsglobal.org/content/packaging/index.html.
4.2 Keeping control over resources after a package has been published
Originally, a PIF, such as a ZIP archive, was intended to function solely as a means of transporting a course from one delivery environment (e.g., an LMS) to another. In practice, however, often a course is delivered from the archive after the archive has been installed in an LMS, thereby changing the nature and use of the PIF that contains the course from a transport mechanism to a content management device.
Though this does work, there are cases where it is desirable not to copy the content that is aggregated in a PIF, but have it reside on a central server. That way, access to the resources can be controlled more easily; content files can be updated at any point in time and use monitored more accurately by the publisher.
4.3 Aggregate content at an appropriate level of granularity
A SCORM sharable content object (SCO) is the lowest level at which a learner’s progress through a course can be tracked in SCORM. Therefore, SCOs often contain multiple pages of content. This makes it difficult to track precisely where a learner is in the material, which may, for example, impede re-opening a session at a later stage.
This issue can be addressed by aggregating SCOs in a level of packaging between the SCO and the course manifest. Such a level would also help with the management of content, because levels of aggregation can be separated more cleanly.
With some clarification, child-manifests can be used for this purpose. A child-manifest is a complete, subordinate manifest used by another manifest. A child-manifest describes a complete logical package that is part of the larger logical package defined by its parent manifest. A manifest may contain one or more child-manifests. Alternatively, from version 1.2 onwards, a manifest may include a reference to one or more child-manifests that are external to the parent manifest.
As an example of the use of child-manifests, suppose a content author was developing a lesson on camping based on three existing content packages: “How to construct a tent”, “How to start a fire”, and “How to make Smores”. The content author can either (a) include the manifests for these existing content packages in the new manifest, or (b) reference the existing manifests. Referenced child-manifests may be local to the interchange package or may be hosted separately (for example in a repository).
Figure 4.1 An example of the use of child-manifests.
Specialized packages do not conform to a particular common pattern, but are similar in that they are used to convey very specific types of content, often inline, in the manifest. In practice, most of these packages are combinations of packages with other 1EdTech specification content including:
• 1EdTech ePortfolio [EP, 05b]
• 1EdTech Learning Design [LD, 03a, c]
• 1EdTech QTI [QTI, 05a, b, c, d]
• 1EdTech Simple Sequencing [SS, 03c]
In each of these cases, a significant part of the content that is described in the manifest is neither an external file, nor does its structure conform to the 1EdTech Content Packaging Specification itself. Instead, at the core of these packages are descriptions of specific data in XML dialects. Content packaging merely provides a convenient way of aggregating such descriptions. Guidance on how each of these specifications uses content packaging is provided in the relevant 1EdTech documentation set.
4.5 Working with child-manifests and applying sequencing rules using the new IPointer mechanism
Some specifications, such as 1EdTech Simple Sequencing, add their own XML attributes to 1EdTech Content Packaging's Item structure. Thought needs to be given as to how the information conveyed by those attributes affect the tree-like structures that can be built with Item objects in an Organization. Specifically, conflicts may exist among several sets of sequencing rules when a parent Manifest declares an association with one or more child Manifest objects and all contain sequencing instructions. This is conceptually no different from cases where sequencing rules exist on a parent Item that contains at least one child Item that also has sequencing rules. When using IPointer objects, a key point to bear in mind is whether an Item becomes a parent to a target Item in the external Manifest to which the IPointer points. This same logic applies to Manifest objects that contain internal references to child Manifest objects.
4.6 Packaging METS and other complex object encodings
Several formats exist for aggregating complex digital objects in addition to 1EdTech Content Packaging. In the library community, for example, Metadata Encoding and Transport Schema (METS) [METS] is widely used, while MPEG–21 DID [ISO/IEC FDIS 21000, 05] is used in many multimedia applications.
Ideally, complex digital objects should be transformable from one such format to another. However, this is not always possible or even desirable. Sometimes, it may be preferable to exchange a complex digital object in one format wrapped inside another. This approach can be used to exchange a complex digital object without affecting its native format, structural integrity, or semantic fidelity.
4.7 Using alternative organization structures, such as topic maps
Traditionally, 1EdTech Content Packaging has provided one default Structure type: “hierarchical”. “Hierarchical” is intended to support table-of-contents type structures to learning resources. However, many implementers have use cases for other means of organizing resources that are not defined by 1EdTech Content Packaging. Typically, these cases are driven by a need to provide richer or more complex learning activities. Examples of alternative organizations are directed graphs, flat lists, and standardized structures, such as ISO 13250-2 Topic Maps [ISO/IEC 13250, 06].
4.8 Working with alternative resources
Because the access requirements of different learners vary, the accessibility properties of educational content needs to be described such that a package processing tool can make a good decision about which content to render for a particular learner. Content that is described in this way can reside in more than one place. What this means is that, at or close to run time, a primary media learning resource or component may be replaced or supplemented. The replacement or supplementation may relate to a resource or to a file or to files that form part of the resource. When working with a resource, accessibility meta-data [ACCMD, 04a] about that resource will commonly describe its properties including the location of any replacement or supplementary resources. In 1EdTech AccessForAll Meta-data, each alternative resource that is associated with a primary resource can be found at the end of a URI that can point to a location internal to the system or external to it.
The mechanism provided is that a Resource object can have one or more associated variant Resource objects. Association is via a dedicated Variant object within a Resource that references the alternative Resource within the same Manifest. Where the alternative resource is external, it is referenced indirectly via the internal associated resource. The relationship is logically equivalent to containment of the variant resource within the one for which it is a variant.
The 1EdTech Content Packaging Specification places no constraints on how the mechanism is used to structure resources, and several different ways to do this are possible, some of which are shown in the examples.
Figure 4.5 A simple example for specifying alternative languages.
Variant references may be from any Resource object to any peer Resource object (child of the same parent). A closer look at this example reveals that in fact the example contains not only the reference shown in Figure 4.5, but also the reverse reference, which may be a useful mechanism in some scenarios.
Any Resource can contain zero or more such references. This enables scenarios, such as
• A Resource has many Variant objects referenced within it.
• A referenced Variant (the alternative resource) has its own Variant objects.
• Variant objects could be hierarchically structured.
• A set of Resource objects, such as might be described with RDF [RDF, 04], could have arbitrarily-structured Variant references.
4.9 Avoiding repeated lists of the same assets for different resources
Many users and content vendors prefer that learning resources have a similar look and feel. This is easily achieved by re-using the same images and styling information for all resources in a content package. However, because Resource objects are required to list all the content files that a resource uses, this approach has the disadvantage that it can lead to a lot of repetition in the Resources section of the Manifest. Therefore, the 1EdTech Content Packaging Specification has a feature that lets content authors list commonly used content files once and reference that list from many different Resource objects.
4.10 Working with local and global identifiers
1EdTech Content Packaging uses the Identifier object to identify parts of a manifest. This local-identifier feature is used primarily to associate Item objects with Resources. Because the Identifier attribute is defined by the W3C's XML Schema specification [Schema, 04] as unique within each document, many tools can easily ensure that objects in a Manifest are unique and that references to them are unambiguous. The cost of this useful feature is that the form of the local identifier has a set of constrains. Most notably, these constraints preclude the use of many common forms of global identifiers, such as Uniform Resource Names (URNs). As a consequence, the Identifier object is not a good way to store globally unique identifiers for a logical package or any part thereof.
A much better way to store such global identifiers is in the Metadata object. Unlike the structural role of a local identifier, a globally unique identifier can be seen as a type of meta-data; it conveys information about the content package, but does not play a role in the package itself. In addition, Metadata can easily accommodate the wide variety of globally unique identifier syntaxes, semantics, and data models that different communities use. Moreover, Metadata can contain an unlimited number of globally unique identifier instances in almost any form.
4.11 Support for multiple languages in titles
The Title object defined for Organization and Item is just a label. It does not specify a language. Nor can the Title be repeated to accommodate multiple languages. Yet learning material that is intended to be used in multilingual environments or material used in language teaching requires the use of titles in more than one language or at least an indication of what language a title is in.
Language-sensitive titles can be added into a Manifest as extensions from another namespace as children of an Organization or Item object. For example, if one wanted to express representations of the same title in multiple languages, one could use the title element from the LOM standard. No restrictions exist on how many instances of LOM’s title element are included in an Item, Manifest, or Organization, and LOM’s title element also has a means of indicating what language the title is in.
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 |
Accessibility 7, 10, 18, 19, 20
Best Practice Guide 1, 4, 7, 8, 24
child-manifest 5, 6, 10, 11, 12, 13, 14
Content Package 4, 11, 12, 15, 16, 17, 18, 20, 21, 22, 23, 24
1EdTech Specifications
Content Packaging 1, 4, 5, 7, 9, 10, 14, 16, 17, 18, 19, 21, 24, 25
Learner Information Package 7, 13
Question and Test Interoperability 7, 13
Vocabulary Definition Exchange 5, 8
Information Model 4, 5, 6, 7, 9, 24
Learning 4, 9, 10, 17, 18, 20, 22
Manifest 4, 5, 6, 10, 11, 12, 13, 14, 21, 24
Meta-data 5, 10, 17, 18, 19, 22
reference 5, 11, 12, 19, 20, 21
Repositories 10, 11, 12, 16, 18, 22
Resources 5, 10, 11, 17, 18, 19, 20, 21
Structure 4, 14, 15, 16, 17, 18, 19
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 Best Practice and Implementation Guide Public Draft v2.0
Date: 1 March 2007