Sharable Content Object Reference Model (SCORMTM)
Version 1.2
October 1, 2001
This page intentionally left blank.
Available at ADLNet (http://www.adlnet.org/)
This page intentionally left blank.
Editor
Philip Dodds (ADL)
Key Contributing Editors (ADL)
Ron Ball Jeff Krinock
William Capone Lori Morealli
Jeff Falls Douglas Peterson
Dexter Fletcher Jonathan Poltrack Alan Hoberney Chris Snyder
Paul Jesukiewicz Schawn Thropp
Kirk Johnson Bryce Walat
Mary Krauland Jerry West
Partial List of Contributors:
Alliance of Remote Instructional Authoring & Distribution Networks for Europe (ARIADNE) (http://www.ariadne-eu.org/) Erik Duval
Eddy Forte Florence Haenny Ken Warkentyne
Aviation Industry CBT (Computer-Based Training) Committee (AICC) (http://www.aicc.org/)
Jack Hyde Bill McDonald
Anne Montgomery
Institute of Electrical and Electronics Engineers (IEEE) Learning Technology Standards Committee (LTSC) (http://ltsc.ieee.org/)
Mike Fore Wayne Hodgins
IMS Global Learning Consortium, Inc. (http://www.imsglobal.org/)
Thor Anderson Steve Griffin Mark Norton Ed Walker
(At Large)
Bob Alcorn Mike Pettit Lenny Greenberg Dan Rehak
Chris Moffatt Tom Rhodes
Boyd Nielsen Tyde Richards
Claude Ostyn Roger St. Pierre
Chantal Paquin Kenny Young
…and many others.
This page intentionally left blank.
SECTION 2 The SCORMTM Content Aggregation Model 2-1
The SCORMTM Content Aggregation Model 2-3
The SCORM Content Model Components 2-3
Assets 2-3
Sharable Content Object (SCO) 2-4
Content Aggregation 2-6
The SCORM Meta-data Components 2-8
Content Aggregation Meta-data 2-8
Sharable Content Object (SCO) Meta-data 2-8
Asset Meta-data 2-8
Meta-Data 2-11
Overview 2-12
The History of the SCORM Meta-data 2-12
The SCORM Meta-data Information Model 2-12
The SCORM Meta-data XML Binding 2-30
<lom> Element 2-32
<general> Element 2-33
<lifecycle> Element 2-40
<metametadata> Element 2-46
<technical> Element 2-54
<educational> Element 2-63
<rights> Element 2-73
<relation> Element 2-75
<annotation> Element 2-82
<classification> Element 2-84
Common Element Types 2-89
LangString Element 2-90
Date Type 2-90
Vocabulary Type 2-91
Electronic Business Card Elements 2-92
Vcard 2-93
XML Extension Mechanism 2-93
The SCORM Meta-data Application Profiles 2-94
Content Aggregation Meta-data 2-95
Sharable Content Object Meta-data 2-95
Asset Meta-data 2-95
The SCORM Meta-data Application Profile Requirements 2-95
SCORM Meta-data Best Practice 2-99
Use of Vocabularies 2-99
Stand-Alone XML Meta-data Documents 2-99
XML Examples 2-100
Content Packaging 2-101
Overview 2-101
Content Structure 2-102
Authoring Content and Content Collections 2-103
Representing Content Structure. 2-103
Content Hierarchy 2-105
Context Specific Meta-data 2-106
Sequencing and Navigation 2-107
Sequencing/Navigation Today 2-108
Sequencing/Navigation Preview 2-110
IMS Package Description 2-111
Content Packaging Overview 2-111
Package 2-112
Manifest 2-112
Meta-data 2-112
Organizations 2-112
Resources 2-112
Physical Files 2-113
Package Interchange File 2-113
The SCORM Content Packaging Information Model 2-113
The SCORM Content Packaging XML Binding 2-124
<manifest> Elements. 2-126
<metadata> Element 2-127
<organizations> Element 2-128
<resources> Element 2-130
<metadata> Element 2-131
<schema> Element 2-132
<schemaversion> Element 2-132
<adlcp:location> 2-133
{Meta-data} 2-133
<organizations> Element 2-134
<organization> 2-134
<resources> Elements 2-142
<resource> Element 2-142
<metadata> Element 2-144
<file> Element 2-144
<dependency> Element 2-145
<manifest> Elements. 2-145
XML Extension Mechanism 2-146
Content Packaging Application Profiles 2-146
Resource Package 2-147
Content Aggregation Package 2-150
Recommended Best Practice 2-151
Packaging Multiple Courses 2-151
Multiple Organizations for a Single Course 2-151
Packaging Learning Content for Reuse 2-152
2.3.6.4. XML Examples 2-152
APPENDIX A ACRONYM LIST.............................................................................A-1
APPENDIX B REFERENCES.................................................................................. B-1
APPENDIX C REVISION HISTORY ...................................................................... C-1
This page intentionally left blank.
The SCORMTM Content Aggregation Model
This page intentionally left blank.
The SCORMTM Content Aggregation Model
The SCORM Content Aggregation Model represents a pedagogically neutral means for designers and implementers of instruction to aggregate learning resources for the purpose of delivering a desired learning experience. A learning resource is any representation of information that is used in a learning experience. Learning experiences consist of activities that are supported by electronic or non-electronic learning resources.
One activity of the process of creating and delivering learning experiences involves the creation, discovery and gathering together, or aggregation, of simple assets into more complex learning resources and then organizing the resources into a predefined sequence of delivery. The SCORM Content Aggregation Model supports this component and is made up of the following:
Content Model: Nomenclature defining the content components of a learning experience.
Meta-data: A mechanism for describing specific instances of the components of the content model.
Content Packaging: Defines how to represent the intended behavior of a learning experience (Content Structure) and how to package learning resources for movement between different environments (Content Packaging).
This section provides an overview of the main components of the Content Aggregation Model and defines terms for the various elements.
The SCORM Content Model Components
The SCORM Content Model describes the SCORM components used to build a learning experience from reusable learning resources. The Content Model also defines how these lower-level sharable, reusable learning resources are aggregated to compose higher-level units of instruction. The Content Model components are all considered specializations of learning resources. The SCORM Content Model is made up of the following components: Assets, Sharable Content Objects (SCO) and Content Aggregations. ADL envisions more specializations of learning resources to be introduced in future versions of the SCORM.
Assets
Learning content in its most basic form is composed of Assets that are electronic representations of media, text, images, sound, web pages, assessment objects or other pieces of data that can be delivered to a Web client. An Asset can be described with Asset Meta-data (see Asset Meta-data definition below) to allow for search and discovery within online repositories, thereby enhancing opportunities for reuse. The mechanism for
binding Assets to Asset Meta-data is the Content Package that will be introduced in Section 2.3. Figure 2.1.1.1a provides examples of Assets.
Asset
Whole Web Page
Asset
WAV
Asset
JavaScript Functions
Asset
JPEG
Asset
XML Doc
Asset
GIF
Asset
HTML
Fragment
Asset
Flash Object
Figure 2.1.1.1a: Examples of Assets
Sharable Content Object (SCO)
A Sharable Content Object (SCO) represents a collection of one or more Assets that include a specific launchable asset that utilizes the SCORM Run-Time Environment to communicate with Learning Management Systems (LMSs). A SCO represents the lowest level of granularity of learning resources that can be tracked by an LMS using the SCORM Run-Time Environment. Figure 2.1.1.2a below shows an example of a SCO composed of several Assets.
To be reusable, a SCO by itself should be independent of learning context. For example, a SCO could be reused in different learning experiences to fulfill different learning objectives. In addition, one or more SCOs can be aggregated to form a higher-level unit of instruction or training that fulfills higher level learning objectives.
SCOs are intended to be subjectively small units, such that potential reuse across multiple learning objectives is feasible. The SCORM does not impose any particular constraints on the exact size of a SCO. During content design and authoring activities, when determining the size of a SCO, thought should be given to the smallest logical size of content that one might desire to have tracked by a LMS at run-time. It is intended that
the content developer will determine the size of the SCO based on how much information is needed to achieve the learning outcome and on the level of reuse that the content developer wishes to obtain.
A SCO can be described with SCO Meta-data (see SCO Meta-data definition below) to allow for search and discovery within online repositories, thereby enhancing opportunities for reuse. The mechanism for binding SCOs to SCO Meta-data is the Content Package that will be introduced in a Section 2.3.
Asset
JAVA Script Functions
Asset
Flash Object
Asset
WAV
Asset
JPEG
Asset
HTML
Fragment
Asset
GIF
Asset
XML Doc
Figure 2.1.1.2a: SCO
A SCO is required to adhere to the SCORM Run-Time Environment. This implies that it must have a means to locate an LMS’s API Adapter and must contain the minimum API calls ( LMSInitialize(“”) and LMSFinish(“”) ). There is no obligation to implement any of the other API calls as those are optional and depend upon the nature of the content.
Participation in the SCORM Run-Time Environment also means that a SCO may only be launched by an LMS. A SCO may not itself launch other SCOs.
The requirement that a SCO participate in the SCORM Run-Time Environment yields the following benefits:
Any LMS that supports the SCORM Run-Time Environment can launch SCOs and track them, regardless of who generated them;
Any LMS that supports the SCORM Run-Time Environment can track any SCO and know when it has been started and when it has ended; and
Any LMS that supports the SCORM Run-Time Environment can launch any SCO in the same way.
See the SCORM Run-Time Environment Book for more details.
Content Aggregation
A Content Aggregation is a map (content structure) that can be used to aggregate learning resources into a cohesive unit of instruction (e.g. course, chapter, module, etc.), apply structure and associate learning taxonomies. The content structure defines the taxonomic representation of the learning resources. A content aggregation can reference Content Aggregation Meta-data (see Content Aggregation Meta-data definition below) to allow for search and discovery within online repositories, thereby enhancing opportunities for reuse.
The mechanism for binding content aggregations to Content Aggregation Meta-data is the Content Package that will be introduced in Section 2.3. Figure 2.1.1.3a below shows an example of a Content Aggregation.
The Content Aggregation defines the content structure that provides the mechanisms for defining the sequence that learning resources are to be presented to the user.
Content Structure
Content Aggregation
Aggregation
Learning Resource
Asset
Aggregation
SCO
Asset
Asset
Learning Resource
SCO
Learning Resource
SCO
Learning Resource
Asset
Asset
Learning Resource
Asset
Asset
The SCORM Version 1.2 contains specialized instances of resources: Assets and SCOs.
Assets are learning content in its most basic form. Assets are electronic representations of media, text, images, sound, web pages, chat session, assessment objects or other pieces of data that can be delivered to a Web client.
SCOs represents a collection of one or more Assets and/or Sharable Resources that include a specific launchable asset that utilizes the SCORM Run-time Environment to communicate with LMSs. A SCO represents the lowest level of granularity of content that is able to be tracked by an LMS using the SCORM Run-time Environment.
Content Aggregation is the process of aggregating resources (SCOs/Assets) into a defined structure (content structure) to build a particular learning experience.
Figure 2.1.1.3a: Content Aggregation
In this version of the SCORM, navigation and sequencing between learning resources is defined in the content structure using prerequisites for each learning resource or content aggregation. The LMS is responsible for interpreting the intended sequence described in the content structure and controlling the actual sequencing of the learning resources at run-time.
This represents a major departure from the way courseware has been developed using stand-alone computer-based training (CBT) authoring tools. In the past, these tools typically embedded, inside proprietary data formats, all of the navigation information that governs what part of the course the student will view next. In nearly all cases, authoring tools or systems defined and implemented proprietary and sometimes unique course sequencing methods. Thus it was, and still is, difficult or impossible to share content between different authoring environments, and equally difficult to reuse content in other contexts that involved different sequencing requirements.
Within the SCORM, which is deliberately browser-based, learning resource sequencing is defined in the content structure and is external to the learning resource. It is the responsibility of the LMS to launch the learning resources in the appropriate defined sequence at run-time. This is conceptually important because learning resource reuse cannot really happen if the learning resource has embedded information that is context
specific to the course. In particular, if a learning resource (SCO) contained a “hardwired” branching to another learning resource (SCO) under specific conditions, it could not be used in a different course in which the second learning resource (SCO) might not be applicable or available. The reusability of a learning resource (SCO) depends on it being independent and not tied to a particular aggregation.
The SCORM recognizes, however, that some learning resources may contain internal logic to accomplish a particular learning task. Such a learning resource might branch within itself depending on user interactions. These branches are all self contained, relevant to a stand-alone learning resource (and therefore reusable) and are not usually visible to the LMS. Importantly, internal branching must not reference external learning resources that may or may not be present in other content aggregations. This is an important area that content developers should pay attention to when determining what learning resources should be used and how they are aggregated.
The SCORM Meta-data Components
Meta-data represents a mapping and recommended usage of the IEEE LTSC Learning Object Metadata 21 elements for each of the SCORM Content Model components. The details of this mapping are provided in Section 2.2. In general, guidance is provided for meta-data to be applied to Assets, SCOs and Content Aggregations to describe them in a consistent fashion such that they can be searched for and discovered within and across systems to further facilitate sharing and reuse.
Policies governing the application of meta-data to the components of the Content Aggregation Model should be defined within organizations that wish to enable reuse based on the requirements of those organizations. The SCORM does not seek to impose requirements related to the scope of meta-data tagging of Content Model components, but rather seeks to provide practical, standards-based guidance for those organizations wishing to enable sharing and reuse.
Content Aggregation Meta-data
A definition for meta-data that describes the content aggregation. The purpose of applying Content Aggregation Meta-data is to make the content aggregation accessible (enabling discoverability) within, for example, a content repository and to provide descriptive information about the aggregated content represented by the content package as a whole, autonomous unit.
Sharable Content Object (SCO) Meta-data
A definition of meta-data that can be applied to SCOs that provides descriptive information about the content represented in the SCO. This meta-data is used to facilitate reuse and discoverability of such content within, for example, a content repository.
Asset Meta-data
A definition of meta-data that can be applied to “raw media” Assets that provides descriptive information about the Asset independent of any usage or potential usage within courseware content. This meta-data is used to facilitate reuse and discoverability, principally during content creation, of such Assets within, for example, a content repository.
This page intentionally left blank.
Meta-Data
This section provides specific guidance for applying meta-data to learning resources. The SCORM meta-data application profiles defined in this section directly reference the IEEE LTSC Learning Object Meta-data (LOM) standard21 and the IMS Learning Resource Meta-data XML Binding Specification22. The IEEE specification provides roughly 64 meta-data elements – more than would be practical for everyday use. This section defines, in the SCORM context, which data elements are mandatory in meta-data used for tagging assets, sharable content objects, and aggregations (collections) of learning resources. While SCORM fully adheres to the IEEE and IMS specifications, this section provides additional specific guidance for using meta-data in SCORM conforming environments.
There are five basic subsections to the SCORM Meta-data section:
Section 2.2.1 Overview provides background on the evolution of learning object meta-data.
Section 2.2.2 Information Model defines the meta-data elements. This is essentially the “dictionary” of meta-data tags that define the intended usage of each element. The Information Model is the same as the IEEE LOM specification and does not define how to encode these tags in any particular way.
Section 2.2.3 The SCORM Meta-data XML Binding is based directly on the IMS Learning Resource Meta-data XML specification. It defines how to encode, or bind, the “dictionary” elements defined in Section 2.2.2 in XML. Note that as elsewhere in the SCORM (and within IEEE and IMS as well), an effort has been made to separate the so-called information model from the binding under the assumption that other encodings (bindings) may one day be used even though the data definitions remain the same. In other words, XML is only one possible encoding; others may emerge over time, but the information model should persist.
Section 2.2.4 The SCORM Meta-data Application Profiles provides specific guidance for how to implement meta-data in the SCORM environment. It defines the SCORM mandatory elements and how they are to be encoded to be SCORM conformant.
Section 2.2.5 SCORM Meta-data Best Practices reflects experiences gained by the ADL Technical Team to aid in the development of consistent application of meta-data to learning content.
Overview
The purpose of meta-data (data about data) is to provide a common nomenclature enabling learning resources to be described in a common way. Meta-data can be collected in catalogs, as well as directly packaged with the learning resource it describes. Learning resources that are described with meta-data can be systematically searched for and retrieved for use and reuse.
The History of the SCORM Meta-data
Meta-data for learning resources has been under development within a number of national and international organizations over the past few years. ADL has looked to the IEEE Learning Technology Standards Committee (LTSC) Standard for Information Technology -- Education and Training Systems -- Learning Objects and Metadata Working Group2, the IMS Global Learning Consortium, Inc.3 and the Alliance of Remote Instructional Authoring and Distribution Networks for Europe (ARIADNE)12 as the bodies that are defining meta-data specifically for learning resources. These groups, which have been working collaboratively, have developed a core set of specifications to which this document refers.
The SCORM references the IMS Learning Resource Meta-data Information Model22, itself based on the IEEE Learning Technology Standards Committee (LTSC) Learning Objects Metadata (LOM) Specification21 that was developed as a result of a joint effort between the IMS Global Learning Consortium, Inc.3 and the Alliance of Remote Instructional Authoring and Distribution Networks for Europe (ARIADNE)12 to define a standard set of meta-data element definitions that can be used to describe learning resources. The SCORM has adopted the same set of meta-data elements described in the IMS Learning Resource Meta-data Information Model22. The SCORM also references the IMS Learning Resource Meta-data XML Binding Specification22. This binding specification provides an XML representation for the IMS Learning Resource Meta-data Information Model22.
The SCORM applies the IMS meta-data element definitions to the three content model components: Asset, SCO and Content Aggregation. These three components define the meta-data portion of the SCORM Content Aggregation Model.
This mapping of standardized definitions from IMS and IEEE to the SCORM Content Aggregation Model provides the missing link between general specifications and specific content models. The following sections define the SCORM application of IMS and IEEE definitions to the meta-data portion of the SCORM Content Aggregation Model.
The SCORM Meta-data Information Model
The SCORM Meta-data Information Model describes the data elements that are defined to build SCORM conformant meta-data records. SCORM conformant meta-data records may contain additional data elements, as described in section 2.2.3.4. XML Extension Mechanism. The SCORM Meta-data Information Model is broken up into nine
categories. These categories are based on the definitions found in the IMS Learning Resource Meta-data Information Model22. The nine categories of meta-data elements are:
The General category groups the general information that describes the resource as a whole.
The Lifecycle category groups the features related to the history and current state of this resource and those who have affected this resource during its evolution.
The Meta-metadata category groups information about the meta-data record itself (rather than the resource that the record describes).
The Technical category groups the technical requirements and characteristics of the resource.
The Educational category groups the educational and pedagogic characteristics of the resource.
The Rights category groups the intellectual property rights and conditions of use for the resource.
The Relation category groups features that define the relationship between this resource and other targeted resources.
The Annotation category provides comments on the educational use of the resource and information on when and by whom the comments were created.
The Classification category describes where this resource falls within a particular classification system.
The SCORM Meta-data Information Model table lists the meta-data elements and how they are organized hierarchically. Each element is described with the following pieces of information:
Nr: Hierarchical number system
Name: Element name
Explanation: Detailed description of the element
Multiplicity: How many instances of the element are allowed within the immediate parent element.
Data Type: Whether the element’s value is textual, numerical or a date; and any constraints on its size and format. There are three general-purpose types used in the information model: LangString Type, Date Type and Vocabulary Type. The information model for each of these data types is specified following the SCORM Meta-data Information Model
Identifier elements have a multiplicity value of “RESERVED”. This indicates that at this time consensus has not been reached on the exact specification to be used to represent globally unique identifiers and is subsequently excluded from use.
Some elements use the term smallest permitted maximum in the multiplicity and/or data type columns. The smallest permitted maximum indicates that applications that process meta-data shall support at least that number of entries. In other words, an application may impose a maximum on the number of entries its supports, but that maximum shall not be lower than the smallest permitted maximum value.
For those elements that have a data type of a Vocabulary Type, additional information is provided on whether or not the vocabulary is a Restricted or Best Practice Vocabulary. Restricted indicates that the meta-data element is restricted to the vocabulary entries listed. Best Practice indicates that the SCORM recommends, as best practice, to use the vocabulary entries listed.
The SCORM Meta-data Information Model | ||||
Nr | Name | Explanation | Multiplicity | Data Type |
1 | General | This category groups the general information that describes the resource as a whole. | 1 and only 1 | Container |
1.1 | Identifier | A globally unique label that identifies the resource. This is reserved and shall not be used, as there is no uniformly accepted method for the creation and distribution of globally unique identifiers. This element can be transparent to the meta- data creator. It can be created by the meta- data management system. | RESERVED | String |
1.2 | Title | Name given to this resource. The title can be an already existing one or it may be created by the indexer ad hoc. | 1 and only 1 | LangString Type (smallest permitted maximum: 1000 characters) |
1.3 | Catalog Entry | This sub-category defines an entry within a catalog (i.e. a listing identification system) assigned to this resource. It is intended to describe this resource according to some known cataloging system so that it may be externally searched for and located according to the methodology of the specified system. It may be used as a functional replacement for the element 1.1:General.Identifier, as that is currently reserved. | 0 or More (smallest permitted maximum: 10) | Container |
1.3.1 | Catalog | The name of the catalog (i.e. listing identification system). | 0 or 1 | String (smallest permitted maximum: 1000 characters) |
1.3.2 | Entry | Actual value of the entry within the catalog (i.e. listing identification system). | 0 or 1 | LangStringType (smallest permitted maximum: 1000 characters) |
1.4 | Language | The primary human language used within this resource to communicate to the intended user. This language is the language used within the resource being described. “None” is an acceptable value. Must be expressed as per ISO 63923 & ISO 316624 standards. | 0 or More (smallest permitted maximum: 10) | String (smallest permitted maximum: 100 characters) |
1.5 | Description | A textual description of the content of this resource being described. | 1 or More (smallest permitted maximum: 10) | LangStringType (smallest permitted maximum: 2000 characters) |
1.6 | Keyword | Keywords or phrases describing this resource. This element should not be used for characteristics that can be described by other elements. | 0 or More (smallest permitted maximum: 10) | LangStringType (smallest permitted maximum: 1000 characters) |
1.7 | Coverage | The span or extent of such things as time, culture, geography or region that applies to this resource. | 0 or More (smallest permitted maximum: 10) | LangStringType (smallest permitted maximum: 1000 characters) |
1.8 | Structure | Underlying organizational structure of this resource. IEEE LOM Vocabulary: | 0 or 1 | VocabularyType (Restricted) |
Collection
Mixed
Linear
Hierarchical
Networked
Branched
Parceled
Atomic
1.9 | Aggregation Level | The functional granularity of this resource. IEEE LOM Vocabulary: | 0 or 1 | VocabularyType (Restricted) |
2 | Life Cycle | This category describes the history and current state of this resource and those who have affected this resource during its evolution. | 0 or 1 | Container element |
2.1 | Version | The edition of this resource. | 0 or 1 | LangStringType (smallest permitted maximum: 50 characters) |
2.2 | Status | The state or condition this resource is in. IEEE LOM Vocabulary: | 0 or 1 | VocabularyType (Restricted) |
2.3 | Contribute | This sub-category describes those people or organizations that have affected the state of this resource during its evolution (includes creation, edits and publication). Note: This sub-category is different from 3.3:MetaMetaData.Contribute. | 0 or More (smallest permitted maximum: 30) | Container |
1 - defined as smallest level of aggregation, e.g. raw media data or fragments.
2 - defined as a collection of atoms, e.g. an HTML document with some embedded pictures or a lesson.
3 - defined as a collection of level 1 resources, e.g. a ’Web’ of HTML documents, with an index page that links the pages together or a unit.
4 - defined as the largest level of granularity, e.g. a course.
Draft
Final
Revised
Unavailable
2.3.1 | Role | Kind of contribution. Note: It is recommended that exactly one instance of Author exists. IEEE LOM Vocabulary: | 0 or 1 | VocabularyType (Best Practice) |
2.3.2 | Entity | The identification of and information about the people or organizations contributing to this resource, most relevant first. If 2.3.1:LifeCycle.Contribute.Role equals Author, then the entity should be a person. If 2.3.1:LifeCycle.Contribute.Role equals Publisher, then the entity should be an organization. If 2.3.1:LifeCycle.Contribute.Role is not equal to Author or Publisher, then this element shall be a contributor. If the entity is an organization, then it should be a university department, company, agency, institute, etc. under whose responsibility the contribution was made. Note: This is a vCard25 element. | 0 or More (smallest permitted maximum: 40) | String (smallest permitted maximum: 1000 characters) |
2.3.3 | Date | This sub-category defines the date of the contribution. Must be bound as a DateType that may contain a datetime element expressed as per ISO 860126 standard and a description element. | 0 or 1 | DateType |
Author
Publisher
Unknown
Initiator
Terminator
Validator
Editor
Graphical Designer
Technical Implementer
Content Provider
Technical Validator
Educational Validator
Script Writer
Instructional Designer
3 | Meta- Metadata | This category describes the specific information about this meta-data record itself (rather than the resource that this record describes). This category describes such things as who created this meta-data record, how, when and with what references. | 1 and only 1 | Container |
3.1 | Identifier | This sub-category defines a globally unique label that identifies this meta-data record. This is reserved and shall not be used, as there is no uniformly accepted method for the creation and distribution of globally unique identifiers. Note: This element can be transparent to the meta-data creator. It can be created by the meta-data management system. | RESERVED | String |
3.2 | Catalog Entry | This sub-category defines an entry within a catalog (i.e. listing identification system), given to the meta-data instance. It is intended to describe this meta-data instance according to some known cataloging system so that it may be externally searched for and located according to that system. This element may be used as a functional replacement for the currently reserved element 3.1:MetaMetaData.Identifier. Note: The tool can generate one of the catalog entries automatically. | 0 or More (smallest permitted maximum: 10) | Container |
3.2.1 | Catalog | The name of the catalog (i.e. listing identification system). Note: This element value is generally system generated. | 0 or 1 | String (smallest permitted maximum: 1000 characters) |
3.2.2 | Entry | Actual string value of the entry in the catalog. Note: This element value is generally system generated. | 0 or 1 | LangStringType (smallest permitted maximum: 1000 characters) |
3.3 | Contribute | This sub-category describes those people or organizations that have affected the state of this meta-data instance during its evolution (includes creator and validator). This element is different from 2.3:Lifecycle.Contribute. | 0 or More (smallest permitted maximum: 10) | Container |
3.3.1 | Role | Kind of contribution. Note: It is recommended that exactly one instance of Creator exists. IEEE LOM Vocabulary: | 0 or 1 | VocabularyType (Best Practice) |
3.3.2 | Entity | The identification of and information about the people or organizations contributing to this meta-data instance, most relevant first. Note: This is a vCard25 element. | 0 or More (smallest permitted maximum: 10) | String (smallest permitted maximum: 1000 characters) |
3.3.3 | Date | The date of the contribution. Must be bound as a DateType that may contain a datetime element expressed as per ISO 860126 standard and a description element. | 0 or 1 | DateType |
3.4 | Metadata Scheme | The name and version of the authoritative specification used to create this meta-data instance. This element may be user selectable or system generated. If multiple values are provided, then the meta-data instance shall conform to multiple meta-data schemes. | 1 or More (smallest permitted maximum: 10) | String (smallest permitted maximum: 30 characters) |
3.5 | Language | Language of this meta-data instance. This is the default language for all langstring values in this meta-data instance. This can be a different language than that of the content being described. “None” is an acceptable value. | 0 or 1 | String (smallest permitted maximum: 100 characters) |
4 | Technical | This category describes the technical requirements and characteristics of this resource. | 1 and only 1 | Container |
4.1 | Format | Technical data type of this resource. This element shall be used to identify the software needed to access the resource. The string is restricted to be either a MIME type or ‘non-digital’. | 1 or More (smallest permitted maximum: 40) | String (smallest permitted maximum: 500 characters) |
Creator
Validator
4.2 | Size | The size of the digital resource in bytes. Only the digits ’0’..’9’ should be used; the unit is bytes, not MBytes, GB, etc. This element shall refer to the actual size of this resource, and not to the size of a compressed version of this resource. | 0 or 1 | String (smallest permitted maximum: 30 characters) |
4.3 | Location | A string that is used to access this resource. It may be a location (e.g. Universal Resource Locator (URL)27), or a method that resolves to a location (e.g. Universal Resource Identifier (URI)27). Note: Relative URL’s are permitted if the URL is relative to the location of this meta- data record. Preferable location first. This is where the learning resource described by this meta-data instance is physically located. | 1 or More (smallest permitted maximum: 10) | String (smallest permitted maximum: 1000 characters) |
4.3.1 | Type | This item specifies the type of string that may be used to identify the location of a learning resource as used in the location item. These values indicate whether the string used will be a simple textual description of where a resource is located or whether the string represents a resource available on the Internet with a specific address such as a URL. At this time there are two restricted strings identified to be used to describe the type: | 0 or 1 | String (Restricted values) |
4.4 | Requirement | This sub-category describes the technical capabilities required in order to use this resource. If there are multiple requirements, then all are required, i.e. the logical connector is AND. | 0 or More (smallest permitted maximum: 40) | Container |
4.4.1 | Type | The technology required to use this resource, i.e. hardware, software, network, etc. IEEE LOM Vocabulary: | 0 or 1 | Vocabulary Type (Best Practice) |
TEXT
URI
Operating System
Browser
4.4.2 | Name | Name of the required technology to use this resource. The value for this element may be derived from 4.1:Technical.Format automatically, e.g., "video/mpeg" implies "Multi-OS". IEEE LOM Vocabulary: 4.4.1:Technical.Requirements.Typ e = something other then Open Vocabulary | 0 or 1 | Vocabulary Type (Best Practice) |
4.4.3 | Minimum Version | Lowest possible version of the required technology to use this resource. | 0 or 1 | String (smallest permitted maximum: 30 characters) |
4.4.4 | Maximum Version | Highest version of the technology known to support the use of this resource. | 0 or 1 | String (smallest permitted maximum: 30 characters) |
4.5 | Installation Remarks | Description on how to install this resource. | 0 or 1 | LangString Type (smallest permitted maximum: 1000 characters) |
4.6 | Other Platform Requirements | Information about other software and hardware requirements. | 0 or 1 | LangString Type (smallest permitted maximum: 1000 characters) |
If
:Technical.Requirements.Typ e = ’Operating System’
PC-DOS
MS-Windows
MacOS
Unix
Multi-OS
Other
None
If
:Technical.Requirements.Typ e = ’Browser’
Any
Netscape Communicator
Microsoft Internet Explorer
Opera
If
4.7 | Duration | Time continuous resource takes when played at intended speed. This is especially useful for sounds, movies or animations. Must be bound as a DateType that may contain a datetime element expressed as per ISO 860126 standard and a description element. | 0 or 1 | Date Type |
5 | Educational | This category describes the key educational or pedagogic characteristics of this resource. This is the pedagogical information essential to those involved in achieving a quality learning experience. The audience for this meta-data includes teachers, managers, authors and learners. | 0 or 1 | Container |
5.1 | Interactivity Type | The flow of interaction between this resource and the intended user. IEEE LOM Vocabulary: In an expositive resource, the information flows mainly from this resource to the learner. Expositive documents are typically used for learning-by-reading. These include essays, video clips, graphical material and hypertext documents. In an active resource, information also flows from the learner to this resource. Active documents are typically used for learning-by-doing. These include simulations, questionnaires and exercises. Note: Activating links to navigate in hypertext documents is not considered as an information flow. Thus, hypertext documents are expositive. | 0 or 1 | Vocabulary Type (Restricted) |
Active
Expositive
Mixed
Undefined
5.2 | Learning Resource Type | Specific kind of resource, most dominant kind first. The vocabulary is adapted for the specific purpose of learning resources. IEEE LOM Vocabulary: | 0 or More (smallest permitted maximum: 10) | Vocabulary Type (Best Practice) |
5.3 | Interactivity Level | This element shall define the degree of interactivity between the end user and this resource. IEEE LOM Vocabulary: | 0 or 1 | Vocabulary Type (Restricted) |
5.4 | Semantic Density | This element defines a subjective measure of this resource’s usefulness as compared to its size or duration. IEEE LOM Vocabulary: | 0 or 1 | Vocabulary Type (Restricted) |
Exercise
Simulation
Questionnaire
Diagram
Figure
Graph
Index
Slide
Table
Narrative Text
Exam
Experiment
Problem Statement
Self Assesment
very low
low
medium
high
very high
very low
low
medium
high
very high
5.5 | Intended End User Role | Principal user(s) for which this resource was designed, most dominant first. IEEE LOM Vocabulary: A learner works with a resource in order to learn something. An author creates or publishes a resource. A manager manages the delivery of the resource, e.g., a university or college. The document for a manager is typically a curriculum. | 0 or More (smallest permitted maximum: 10) | Vocabulary Type (Restricted) |
5.6 | Context | The principal environment within which the learning and use of this resource is intended to take place. IEEE LOM Vocabulary: | 0 or More (smallest permitted maximum: 10) | Vocabulary Type (Best Practice) |
Teacher
Author
Learner
Manager
Primary Education
Secondary Education
Higher Education
University First Cycle
University Second Cycle
University Postgrade
Technical School First Cycle
Technical School Second Cycle
Professional Formation
Continuous Formation
Vocational Training
5.7 | Typical Age Range | Age of the typical intended user. This element shall refer to developmental age, if that would be different from chronological age. The age of the learner is important for finding resources, especially for school age learners and their teachers. When applicable, the string should be formatted as minage-maxage or minage-. This is a compromise between adding three subfields (minAge, maxAge and description) and having just a free text field. Various reading age schemes, IQ’s or developmental age measures should be represented through the 9:Classification category | 0 or More (smallest permitted maximum: 5) | LangString Type (smallest permitted maximum: 1000 characters) |
5.8 | Difficulty | This element defines how hard it is to work through this resource for the typical target audience. IEEE LOM Vocabulary: | 0 or 1 | Vocabulary Type (Restricted) |
5.9 | Typical Learning Time | Approximate or typical time it takes to work with this resource. Must be bound as a DateType that may contain a datetime element expressed as per ISO 860126 standard and a description element. | 0 or 1 | Date Type |
5.10 | Description | Comments on how this resource is to be used. E.g., Teacher guidelines that come with a textbook. | 0 or 1 | LangString Type (smallest permitted maximum: 1000 characters) |
5.11 | Language | The human language used by the typical intended user of the resource. “None” is an acceptable value. Must be expressed as per ISO 63923 & ISO 316624 standards. | 0 or More (smallest permitted maximum: 10) | String (smallest permitted maximum: 10 characters) |
very easy
easy
medium
difficult
very difficult
6 | Rights | This category describes the intellectual property rights and conditions of use for this resource. The intent is to reuse results of ongoing work in the Intellectual Property Right and e-commerce communities. This category currently provides the absolute minimum level of detail only. | 1 and only 1 | Container |
6.1 | Cost | Whether use of the resource requires payment. IEEE LOM Vocabulary: | 1 and only 1 | Vocabulary Type (Restricted) |
6.2 | Copyright And Other Restrictions | Whether copyright or other restrictions apply to the use of this resource. IEEE LOM Vocabulary: | 1 and only 1 | Vocabulary Type (Restricted) |
6.3 | Description | Comments on the conditions of use of this resource. | 0 or 1 | LangString Type (smallest permitted maximum: 1000 characters) |
7 | Relation | This category defines the relationship between this resource and other resources, if any. To define multiple relationships there may be multiple instances of this category. If there is more than one target resource, then each target is covered by a new relationship instance. | 0 or More (smallest permitted maximum: 100) | Container |
yes
no
yes
no
7.1 | Kind | Nature of the relationship between this resource and the target resource, identified by 7.2:Relation.Resource. IEEE LOM Vocabulary (from Dublin Core28): | 0 or 1 | Vocabulary Type (Best Practice) |
7.2 | Resource | The target resource that this relationship references. | 0 or 1 | Container |
7.2.1 | Identifier | Unique Identifier of the target resource. This is reserved and shall not be used. | RESERVED | String |
7.2.2 | Description | Description of the target resource. Gives a more detailed description of the elements in this sub-category (Relation). | 0 or 1 | LangString Type (smallest permitted maximum: 1000 characters) |
7.2.3 | Catalog Entry | This sub-category defines an entry within a catalog (i.e. a listing identification system) assigned to this resource. It is intended to describe this resource according to some known cataloging system so that it may be externally searched for and located according to the methodology of the specified system. It may be used as a functional replacement for the element 1.1:General.Identifier, as that is currently reserved. | 0 or More (smallest permitted maximum: 10) | Container |
7.2.3.1 | Catalog | The name of the catalog (i.e. listing identification system). | 0 or 1 | String (smallest permitted maximum: 1000 characters) |
7.2.3.2 | Entry | Actual value of the entry within the catalog (i.e. listing identification system). | 0 or 1 | LangString Type (smallest permitted maximum: 1000 characters) |
IsPartOf
HasPart
IsVersionOf
HasVersion
IsFormatOf
HasFormat
References
IsReferencedBy
IsBasedOn
IsBasisFor
Requires
IsRequiredBy
8 | Annotation | This category provides comments on the educational use of this resource, who created this annotation and when. When multiple annotations are needed, multiple instances of this category may be used. | 0 or More (smallest permitted maximum: 30) | Container |
8.1 | Person | The person who created this annotation. Note: This is a vCard25 element. | 0 or 1 | String (smallest permitted maximum: 1000 characters) |
8.2 | Date | Date that this annotation was created. Must be bound as a DateType that may contain a datetime element expressed as per ISO 860126 standard and a description element. | 0 or 1 | Date Type |
8.3 | Description | The content of this annotation. Gives a more detailed description of the elements in this sub-category (Annotation). | 0 or 1 | LangString Type (smallest permitted maximum: 1000 characters) |
9 | Classification | This category describes where this resource is placed within a particular classification system. To define multiple classifications, there may be multiple instances of this category. | 0 or More (smallest permitted maximum: 40) | Container |
9.1 | Purpose | The purpose of classifying this resource. IEEE LOM Vocabulary: | 0 or 1 | Vocabulary Type (Best Practice) |
9.2 | Taxon Path | This sub-category describes a taxonomic path in a specific classification system. Each succeeding level is a refinement in the definition of the higher level. There may be different paths in the same or different classifications that describe the same characteristic. A taxonomy is a hierarchy of terms or phrases that are taxons. | 0 or More (smallest permitted maximum: 15) | Container |
Discipline
Idea
Prerequisite
Educational Objective
Accessibility Restrictions
Educational Level
Skill Level
Security Level
9.2.1 | Source | The name of the classification system. This element may use any recognized "official" taxonomy, or any user-defined taxonomy. An indexation or query tool may provide the top-level entries of a well- established classification (LOC, UDC, DDC, etc.). | 0 or 1 | LangString Type (smallest permitted maximum: 1000 characters) |
9.2.2 | Taxon | This sub-category describes a particular term within a hierarchical classification system or taxonomy. A taxon is a node that has a defined label or term. A taxon may also have an alphanumeric designation or identifier for standardized reference. Either or both the label and the entry may be used to designate a particular taxon. An ordered list of Taxons creates a taxonomic path, i.e. "taxonomic stairway": this is a path from a more general to more specific entry in a classification. A TaxonPath shall have a depth from 1 to 9. Normal values should be defined as values between 2 and 4. e.g., Physics/ Acoustics/ Instruments/ Stethoscope; Medicine/ Diagnostics/ Instruments/ Stethoscope | 0 or More (smallest permitted maximum: 15) | Container |
9.2.2.1 | Id | The identifier of the taxon, such as a number or letter combination provided by the source of the taxonomy. (e.g., 300) | 0 or 1 | String (smallest permitted maximum: 100 characters) |
9.2.2.2 | Entry | The textual label of the taxon. (e.g., Social Sciences) | 0 or 1 | LangString Type (smallest permitted maximum: 500 characters) |
9.3 | Description | This is the description of the resource relative to the stated 9.1:Classification.Purpose of this specific classification, such as discipline, idea, skill level, educational objective, etc. | 0 or 1 | LangString Type (smallest permitted maximum: 2000 characters) |
9.4 | Keyword | These are the keywords and phrases descriptive of the resource relative to the stated 9.1:Classification.Purpose of this specific classification, such as accessibility, security level, etc., most relevant first. | 0 or More (smallest permitted maximum: 40) | LangString Type (smallest permitted maximum: 1000 characters) |
LangString Type Information Model | ||||
Nr | Name | Explanation | Multiplicity | Data Type |
1 | Langstring | String in one or more human languages. | 0 or More (smallest permitted maximum: 10) | Container |
1.1 | Language | Human language in which the string is expressed. | single value | String(smallest permitted maximum: 100 characters) |
1.2 | String | Actual string value. | single value | String |
Date Type Information Model | ||||
Nr | Name | Explanation | Multiplicity | Data Type |
1 | Datetime | Date expressed as per ISO 8601 standard. | single value | String (smallest permitted maximum: 200 characters) |
2 | Description | Description of the date. | single value | LangString Type (smallest permitted maximum: 1000 characters) |
Vocabulary Information Model | ||||
Nr | Name | Explanation | Multiplicity | Data Type |
1 | Source | Source of vocabulary item(s). | single value | LangString Type (smallest permitted maximum: 1000 characters) |
2 | Value | Actual descriptor. | single value | LangString Type (smallest permitted maximum: 1000 characters) |
The SCORM Meta-data XML Binding
The SCORM Meta-data XML Binding is based off of the IMS Learning Resource XML Binding Specification22. The XML Binding defines how the SCORM Meta-data Information model is interpreted and bound into XML. The binding describes how the
Information Model items are represented in XML by indicating which items are XML elements versus XML attributes, the names of the elements/attributes, etc.
Some of the elements have smallest permitted maximum values defined for data elements within a list of elements and data elements with a data type of character string or langstring. This indicates that all applications shall support at least that number of entries for the list or that length for the strings (character strings and langstrings).
There are two varieties of vocabularies: restricted and best practice. A restricted vocabulary means that the element must contain a value from the list provided as part of the element’s description. A “best practice” vocabulary presents a recommended list of appropriate values for that element, but the element is not mandated to contain a value from the list. However, meta-data elements that rely on the recommended best practice values will have the highest degree of semantic interoperability, i.e. the likelihood that such meta-data will be understood by other end users is highest.
The following table shows symbols that denote the contents of the element. Elements may contain other elements, or they may be “leaf nodes” and contain data. This table also shows symbols that relate directly to the “Multiplicity” specified for each element. This describes the number of times the element can occur within its parent element, or in the case of the top most element in the document, how many times the element occurs in the XML document.
Symbol | Meaning |
This symbol denotes that the element has one or more child elements. | |
This symbol denotes that the element contains data. | |
This text denotes the XML Schema Definition (XSD) type assigned to the element. | |
(no symbol) | When no multiplicity symbol is present, this denotes that the element may exist one and only one time. |
+ | The plus sign denotes that the element may occur one or more times within its parent element. |
? | The question mark denotes that the element may occur zero or one time within its parent element. |
* | The asterisk denotes that the element may occur zero to many times within its parent element. |
<lom> Element
Description: The outermost, root, element. This element indicates the beginning of the SCORM Meta-data XML record.
Multiplicity: The <lom> element is the root element of the XML. This element should occur 1 and only 1 time in a SCORM XML Meta-data document.
Attributes:
None
Elements:
<general>
<lifecycle>
<metametadata>
<technical>
<educational>
<rights>
<relation>
<annotation>
<classification>
<general> Element
Description: This data element describes the general information that describes the learning resource as a whole.
Multiplicity: The <general> element must occur 1 and only 1 time within the top-level
<lom> element.
Attributes:
None
Elements:
<identifier>
<title>
<catalogentry>
<language>
<description>
<keyword>
<coverage>
<structure>
<aggregationlevel><identifier> Element
Description: This data element describes a globally unique label that identifies this learning resource. This data element is not and shall not be used, because there is no specified method for the creation of a globally unique identifier.
Multiplicity: The <identifier> element is reserved at this time.
Attributes:
None
Elements:
None
Example:
None – Element is reserved
<title> Element
Description: This data element describes the name given to the learning resource.
Multiplicity: The <title> element must occur 1 and only 1 time within the <general> element.
Attributes:
None
Elements:
<langstring> (The <langstring> element can be repeated 1 or more times within the <title> element. However, each langstring is required to contain a different xml:lang attribute).
<general>
<title>
3
4
5
<langstring xml:lang=”en”>Title 1 in English</language>
<langstring xml:lang=”fr”>Title 1 in French</language>
</title>
Example:
6 </general>
<catalogentry> Element
Description: This data element describes an entry within a catalog (i.e. a listing identification system) assigned to this learning resource. This sub-category shall describe this learning resource according to some known cataloging system so that it may be externally searched for and located according to the methodology of the specified system.
Multiplicity: The <catalogentry> element occurs 0 or more times within the <general> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
<catalog>
<entry>
<general>
<catalogentry>
3
4
5
6
7
<catalog>ISBN</catalog>
<entry>
<langstring>2-7342</langstring>
</entry>
</catalogentry>
8 </general>
Example:
<catalog> Element
Description: This data element describes the name of the catalog (i.e. listing identification system).
Multiplicity: The <catalog> element occurs 0 or 1 time within the <catalogentry> element.
Attributes:
None
Elements:
None
Example:
1 <general>
3
4
5
6
7
<catalog>ISBN</catalog>
<entry>
<langstring>2-7342</langstring>
</entry>
</catalogentry>
8 </general>
2 <catalogentry>
<entry> Element
Description: This data element describes the actual string value of the entry within the catalog (i.e. listing identification system).
Multiplicity: The <entry> element must occurs 0 or 1 time within the <catalogentry> element.
Attributes:
None
Elements:
<langstring> (The <langstring> element can be repeated 1 or more times within the <entry> element. However, each langstring is required to contain a different xml:lang attribute).
<general>
<catalogentry>
3
4
5
6
7
<catalog>ISBN</catalog>
<entry>
<langstring>2-7342</langstring>
</entry>
</catalogentry>
8 </general>
Example:
<language> Element
Description. This data element describes the primary human language or languages used within this learning resource to communicate to the intended user.
Multiplicity. The <language> element occurs 0 or more times within the <general> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
None
Example:
<general>
<language>en</language>
<language>fr</language>
</general>
<description> Element
Description: This data element describes a textual description of the content of this learning resource.
Multiplicity: The <description> element occurs 1 or more times within the <general> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <description> element. However, each langstring is required to contain a different xml:lang attribute).
<general>
<description>
3
4
5
<langstring xml:lang=”en”>Description in English</langstring>
<langstring xml:lang=”fr”>Description in French</langstring>
</description>
6 </general>
Example:
<keyword> Element
Description: This data element describes keywords or phrases describing this learning resource. This data element should not be used for characteristics that can be described by other data elements.
Multiplicity: The <keyword> element occurs 0 or more times within the <general> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <keyword> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<general>
<keyword>
<langstring xml:lang=”en”>metadata</langstring>
<langstring xml:lang=”nl”>metadata</langstring>
<langstring xml:lang=”fr”>metadonnees</langstring>
</keyword>
<keyword>
<langstring xml:lang=”en”>learning object</langstring>
<langstring xml:lang=”nl”>leerobject</langstring>
<langstring xml:lang=”fr”>objet d’apprentissage</langstring>
</keyword>
<keyword>
<langstring xml:lang=”en”>education</langstring>
</keyword>
<general>
<coverage> Element
Description: This data element describes the span or extent of such things as time, culture, geography or region that applies to this learning resource.
Multiplicity: The <coverage> element occurs 0 or more times within the <general> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <coverage> element. However, each langstring is required to contain a different xml:lang attribute).
<general>
<coverage>
3
4
<langstring xml:lang=”en”>Circa, 16th century France</langstring>
</coverage>
5 <general>
Example:
<structure> Element
Description: This data element describes the underlying organizational structure of this learning resource. The vocabularies defined for this element are restricted vocabularies.
Multiplicity. The <structure> element occur 0 or 1 time within the <general> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Restricted Vocabulary:
Collection
Mixed
Linear
Hierarchical
Networked
Branched
Parceled
Atomic
Example:
<general>
<structure>
<vocabulary>
<source>
<langstring xml:lang=”x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=”x-none”>Collection</langstring>
</value>
</vocabulary>
</structure>
</general>
<aggregationlevel> Element
Description: This data element describes the functional granularity of this learning resource. The vocabularies defined for this element are restricted vocabularies.
Multiplicity: The <aggregationlevel> element occurs 0 or 1 time within the <general> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Restricted Vocabulary:
1 – the smallest level of aggregation, e.g. raw media data or fragments.
2 – a collection of atoms, e.g. an HTML document with some embedded pictures or a lesson.
3 – a collection of level 2 learning resources, e.g. a ‘web’ of HTML documents, with an index page that links the pages together or a course.
4 – the largest level of granularity, e.g. a set of courses that lead to a certificate.
Example:
<general>
<aggregationlevel>
<vocabulary>
<source>
<langstring xml:lang=”x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=”x-none”>1</langstring>
</value>
</vocabulary>
</aggregationlevel>
</general>
<lifecycle> Element
Description: This data element describes the features related to the history and current state of this learning resource and those who have affected this learning resource during its evolution.
Multiplicity: The <lifecycle> element occurs 0 or 1 time within the top-level <lom> element.
Attributes:
None
Elements:
<version>
<status>
<contribute>
<version> Element
Description: This data element describes the edition of this learning resource. Multiplicity: The <version> element occurs 0 or 1 time within the <lifecycle> element. Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <version> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<lifecycle>
<version>
3
4
<langstring xml:lang=”en”>1.0.alpha</langstring>
</version>
5 </lifecycle>
<status> Element
Description: This data element describes the state or condition of this learning resource. The vocabularies defined for this element are restricted vocabularies.
Multiplicity: The <status> element occurs 0 or 1 time within the <lifecycle> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Restricted Vocabulary:
Draft
Final
Revised
Unavailable
Example:
<lifecycle>
<status>
<vocabulary>
<source>
<langstring xml:lang=”x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=”x-none”>Final</langstring>
</value>
</vocabulary>
</status>
</lifecyle>
<contribute> Element
Description: This data element describes those people or organizations that have affected the state of this learning resource during its evolution.
Multiplicity: The <contribute> element occurs 0 or more times within the <lifecycle> element. The smallest permitted maximum is 30 items.
Attributes:
None
Elements:
<role>
<centity>
<date>
Example:
<lifecycle>
<contribute>
<role>
<vocabulary>
<source>
<langstring xml:lang=”x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=”x-none”>Author</langstring>
</value>
</vocabulary>
</role>
<centity>
<vcard>
begin:vcard
fn: Joe Author
end:vcard
</vcard>
</centity>
<date>
<datetime>2000-12-12</datetime>
<description>
<langstring>Date Description</langstring>
</description>
</date>
</contribute>
</lifecycle>
<role> Element
Description: This data element describes the kind of contribution. It is recommended that at least the Author(s) of the learning resource should be described. The vocabularies defined for this element are recommended best practice vocabularies.
Multiplicity: If the <contribute> element is used, the <role> element occurs 0 or 1 time within the <contribute> element. If there are multiple contributors (different roles), then the <contribute> element should be repeated.
Attributes:
<vocabulary>
Elements:
None
LOM Defined Vocabularies (<source> element set to LOMv1.0) Best Practice Vocabulary:
Author
Publisher
Unknown
Initiator
Terminator
Validator
Editor
Graphical Designer
Technical Implementer
Content Provider
Technical Validator
Educational Validator
Script Writer
Instructional Designer
Example:
<lifecycle>
<contribute>
<role>
<vocabulary>
<source>
<langstring xml:lang=”x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=”x-none”>Author</langstring>
</value>
</vocabulary>
</role>
<centity>
<vcard>
begin:vcard
fn: Joe Author
end:vcard
</vcard>
</centity>
<date>
<datetime>2000-12-12</datetime>
<description>
<langstring>Date Description</langstring>
</description>
</date>
</contribute>
</lifecycle>
<centity> Element
Description. This data element describes the identification of and information about people or organizations contributing to this learning resource, most relevant first.
Multiplicity. The <centity> element occurs 0 or more times within the <contribute> element. The smallest permitted maximum is 40 items.
Attributes:
None
Elements:
<vcard>
Example:
<lifecycle>
<contribute>
<role>
<vocabulary>
<source>
<langstring xml:lang=”x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=”x-none”>Author</langstring>
</value>
</vocabulary>
</role>
<centity>
<vcard>
begin:vcard
fn: Joe Author
end:vcard
</vcard>
</centity>
<date>
<datetime>2000-12-12</datetime>
<description>
<langstring>Date Description</langstring>
</description>
</date>
</contribute>
</lifecycle>
<date> Element
Description: This data element describes the date of the contribution.
Multiplicity: The <date> element occurs 0 or 1 time within the <contribute> element.
Attributes:
None
Elements:
<datetime>
<description>
Example:
<lifecycle>
<contribute>
<role>
<vocabulary>
<source>
<langstring xml:lang=”x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=”x-none”>Author</langstring>
</value>
</vocabulary>
</role>
<centity>
<vcard>
begin:vcard
fn: Joe Author
end:vcard
</vcard>
</centity>
<date>
<datetime>2000-12-12</datetime>
<description>
<langstring>Date Description</langstring>
</description>
</date>
</contribute>
</lifecycle>
<metametadata> Element
Description: This data element describes the information about the meta-data record itself (rather than the learning resource that this record describes).
Multiplicity: The <metametadata> element must occur 1 and only 1 time within the top- level <lom> element.
Attributes:
None
Elements:
<identifier>
<catalogentry>
<contribute>
<metadatascheme>
<language>
<identifier> Element
Description: This data element describes a globally unique label that identifies this meta-data record. This data element is not and shall not be used, because there is no specified method for the creation of a globally unique identifier.
Multiplicity: The <identifier> element is reserved at this time.
Attributes:
None
Elements:
None
Example:
None – Element Reserved
<catalogentry> Element
Description: This data element defines an entry within a catalog (i.e. a listing identification system) given to the meta-data instance. This sub-category should describe this meta-data instance according to some known cataloging system so that it may be externally searched for and located according to the methodology of the specified system.
Multiplicity: The <catalogentry> element occurs 0 or more times within the
<metametadata> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
<catalog>
<entry>
1 <metametadata>
2
3
4
5
6
7
<catalogentry>
<catalog>ISBN</catalog>
<entry>
<langstring>2-7342</langstring>
</entry>
</catalogentry>
8 </metametadata>
Example:
<catalog> Element
Description: This data element describes the name of the catalog (i.e. listing identification system).
Multiplicity. The <catalog> element must occur 0 or 1 time within the <catalogentry> element.
Attributes:
None
Elements:
None
<metametadata>
<catalogentry>
3
4
5
6
7
<catalog>ISBN</catalog>
<entry>
<langstring>2-7342</langstring>
</entry>
</catalogentry>
8 </metametadata>
Example:
<entry> Element
Description: This data element describes the actual string value of the entry within the catalog (i.e. listing identification system).
Multiplicity: The <entry> element occurs 0 or 1 time within the <catalogentry> element. If the <catalogentry> element is used, the <entry> element must occur 1 and only 1 time with the <catalogentry> element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <catalogentrycoverage> element. However, each langstring is required to contain a different xml:lang attribute).
<metametadata>
<catalogentry>
3
4
5
6
7
<catalog>ISBN</catalog>
<entry>
<langstring>2-7342</langstring>
</entry>
</catalogentry>
8 </metametadata>
Example:
<contribute> Element
Description: This data element describes those people or organizations that have affected the state of this meta-data instance during its evolution.
Multiplicity: The <contribute> element occurs 0 or more times within the
<metametadata> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
<role>
<centity>
<date>
Example:
<metametadata>
<contribute>
<role>
<vocabulary>
<source><source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Creator</langstring>
</value>
</vocabulary>
</role>
<entity>
<vcard>
begin:vcard
fn: Joe Creator
end:vcard
14 </vcard>
</entity>
<date>
<datetime>2000-12-12</datetime>
<description>
<langstring>Date Description</langstring>
</description>
</date>
</contribute>
</metametadata>
<role> Element
Description: This data element describes the kind of contribution. It is recommended that at least the Creator(s) of the meta-data instance should be described. The vocabularies defined for this element are recommended best practice vocabularies.
Multiplicity: If the <contribute> element is used, the <role> element occurs 0 or 1 time within the <contribute> element. If there are multiple contributors (different roles), then the <contribute> element should be repeated.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Best Practice Vocabulary:
Creator
Validator
Example:
<metametadata>
<contribute>
<role>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Creator</langstring>
</value>
</vocabulary>
</role>
<entity>
<vcard>
begin:vcard
fn: Joe Creator
end:vcard
</vcard>
</entity>
<date>
<datetime>2000-12-12</datetime>
<description>
<langstring>Date Description</langstring>
</description>
</date>
</contribute>
</metametadata>
<centity> Element
Description: This data element describes the identification of and information about people or organizations contributing to this meta-data instance, most relevant first.
Multiplicity: The <entity> element occurs 0 or more times within the <contribute> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
<vcard>
Example:
<metametadata>
<contribute>
<role>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Creator</langstring>
</value>
</vocabulary>
</role>
<entity>
<vcard>
begin:vcard
fn: Joe Creator
end:vcard
</vcard>
</entity>
<date>
<datetime>2000-12-12</datetime>
<description>
<langstring>Date Description</langstring>
</description>
</date>
</contribute>
</metametadata>
<date> Element
Description: This data element describes the date of the contribution.
Multiplicity: The <date> element occurs 0 or 1 time within the <contribute> element.
Attributes:
None
Elements:
<datetime>
<description>
Example:
<metametadata>
<contribute>
<role>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Creator</langstring>
</value>
</vocabulary>
</role>
<entity>
<vcard>
begin:vcard
fn: Joe Creator
end:vcard
</vcard>
</entity>
<date>
<datetime>2000-12-12</datetime>
<description>
<langstring>Date Description</langstring>
</description>
</date>
</contribute>
</metametadata>
<metadatascheme> Element
Description: This data element represents the name and version of the authoritative specification used to create this meta-data instance. If multiple values are provided, then the meta-data instances shall conform to multiple meta-data schemes.
Multiplicity: The <metadatascheme> element occurs 1 or more times within the
<metametadata> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
None
1 <metametadata>
2
<metadatascheme>LOM-1.0</metadatascheme>
3 </metametadata>
Example:
<language> Element
Description: This data element describes the language of this meta-data instance. This is the default language for all LangString values in this meta-data instance.
Multiplicity: The <language> element occurs 0 or 1 time within the <metametadata> element.
Attributes:
None
Elements:
None
Example:
<metametadata>
<language>en</language>
</metametadata>
<technical> Element
Description: This data element groups the technical requirements and characteristics of the learning resource.
Multiplicity: The <technical> element must occur 1 and only 1 time within the top-level
<lom> element.
Attributes:
None
Elements:
<format>
<size>
<location>
<requirement>
<installationremarks>
<otherplatformrequirements>
<duration>
<format> Element
Description: This data element describes the technical data type(s) of (all the components of ) this learning resource. This data element shall be used to identify the software needed to access the learning resource.
Multiplicity: The <format> element must occur 1 or more times within the <technical> element. The smallest permitted maximum is 40 items.
Attributes:
None
Elements:
None
1 <technical>
2
3
<format>video/mpeg</format>
<format>text/html</format>
4 </technical>
Example:
<size> Element
Description. This data element describes the size of the digital learning resource in bytes. Only digits ‘0’ through ‘9’ should be used; the unit is bytes, not Mbytes, GB, etc. This date element shall refer to the actual size of this learning resource. If the learning resource is compressed, then this data element shall refer to the uncompressed size.
Multiplicity. The <size> element occurs 0 or 1 time within the <technical> element.
Attributes:
None
Elements:
None
Example:
<technical>
<size>568</size>
</technical>
<location> Element
Description: This data element describes a string that is used to access this learning resource. It may be a location (e.g. Universal Resource Locator), or a method that resolves to a location (e.g. Universal Resource Identifier). The preferable location first. This is where the learning resource described by this meta-data instance is physically located.
Multiplicity: The <location> element occurs 1 or more times within the <technical> element. The smallest permitted maximum is 10 items.
Attributes:
type
Valid values for type attribute:
URI – a resource available on the Internet with a specific address such as a URL. TEXT – simple textual description of where the resource is located.
Elements:
None
1 <technical>
2
<location type=”URI”>http://host/id</location>
3 </technical>
Example:
<requirement> Element
Description: This data element describes the technical capabilities required in order to use this learning resource. If there are multiple requirements, then all are required, i.e. the logical connector is AND.
Multiplicity: The <requirement> element occurs 0 or more times within the <technical> element. The smallest permitted maximum is 40 items.
Attributes:
None
Elements:
<type>
<name>
<minimumversion>
<maximumversion>
1 <technical>
2
3
4
5
6
7
8
<requirement>
<type>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
Example:
9
10
11
12
13
14
15
16
17
18
19
<langstring xml:lang=“x-none”>Browser</langstring>
</value>
</vocabulary>
</type>
<name>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Mircosoft Internet
Explorer</langstring>
20
21
22
23
24
25
</value>
</vocabulary>
</name>
<minimumversion>4.0</minimumversion>
<maximimversion>5.0</maximumversion>
</requirement>
26 </technical>
<type> Element
Description: This data element describes the technology required to use this learning resource, i.e. hardware, software, network, etc. The vocabularies defined for this element are recommended best practice vocabularies.
Multiplicity: The <type> element occurs 0 or 1 time within the <requirement> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Best Practice Vocabulary:
Operating System
Browser
Example:
<technical>
<requirement>
<type>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Browser</langstring>
</value>
</vocabulary>
12
13
14
15
16
17
18
19
</type>
<name>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Microsoft Internet
Explorer</langstring>
20
21
22
23
24
25
</value>
</vocabulary>
</name>
<minimumversion>4.0</minimumversion>
<maximimversion>5.0</maximumversion>
</requirement>
26 </technical>
<name> Element
Description: This data element describes the name of the required technology to use this learning resource. The value for this data element may be derived from the 4.4.1 Technical.Format automatically, e.g., “video/mpeg” implies “Multi-OS”. The vocabularies defined for this element are recommended best practice vocabularies.
Multiplicity: The <name> element occurs 0 or 1 time within the <requirement> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Best Practice Vocabulary:
If 4.4.1:Technical.Requirements.Type = ’Operating System’
PC-DOS
MS-Windows
MacOS
Unix
Multi-OS
Other
None
If 4.4.1:Technical.Requirements.Type = ’Browser’
Any
Netscape Communicator
Microsoft Internet Explorer
Opera
If 4.4.1:Technical.Requirements.Type = something other
Open Vocabulary
Example:
<technical>
<requirement>
<type>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Browser</langstring>
</value>
</vocabulary>
</type>
<name>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Microsoft Internet Explorer</langstring>
</value>
</vocabulary>
</name>
<minimumversion>4.0</minimumversion>
<maximimversion>5.0</maximumversion>
</requirement>
</technical>
<minimumversion> Element
Description: This data element describes the lowest possible version of the required technology to use this learning resource.
Multiplicity: The <minimumversion> element occurs 0 or 1 time within the
<requirement> element.
Attributes:
None
Elements:
None
Example:
<technical>
<requirement>
<type>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Browser</langstring>
</value>
</vocabulary>
</type>
<name>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Microsoft Internet Explorer</langstring>
20
21
22
23
24
25
</value>
</vocabulary>
</name>
<minimumversion>4.0</minimumversion>
<maximimversion>5.0</maximumversion>
</requirement>
26 </technical>
<maximumversion> Element
Description: This data element describes the highest version of the technology known to support the use of this learning resource.
Multiplicity: The <maximumversion> element occurs 0 or 1 time within the
<requirement> element.
Attributes:
None
Elements:
None
Example:
<technical>
<requirement>
<type>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Browser</langstring>
</value>
</vocabulary>
12
13
14
15
16
17
18
19
</type>
<name>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Microsoft Internet
Explorer</langstring>
20
21
22
23
24
25
</value>
</vocabulary>
</name>
<minimumversion>4.0</minimumversion>
<maximimversion>5.0</maximumversion>
</requirement>
26 </technical>
<installationremarks> Element
Description: This data element contains the description of how to install this learning resource.
Multiplicity: The <installationremarks> element occurs 0 or 1 time within the
<technical> element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <installationremarks> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<technical>
<installatinremarks>
<langstring>Installation remakes placed here</langstring>
</installationremarks>
</technical>
<otherplatformrequirements> Element
Description: This data element describes information about other software and hardware requirements.
Multiplicity: The <otherplatformrequirements> element occurs 0 or 1 time within the
<technical> element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <otherplatformrequirements> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<technical>
<otherplatformrequirements>
<langstring>Other platform requirements placed here</langstring>
</otherplatformrrequirements>
</technical>
<duration> Element
Description: This data element describes the time a continuous learning resource takes when played at the intended speed. This data element is especially useful for sounds, movies or animations.
Multiplicity: The <duration> element occurs 0 or 1 time within the <technical> element.
Attributes:
None
Elements:
<datetime>
<description>
Example:
<technical>
<duration>
<date>
<datetime>00:00:15</datetime>
<description>
<langstring>Length of time to play the simulation</langstring>
</description>
</date>
</duration>
</technical>
<educational> Element
Description: This data element describes conditions of use of the resource.
Multiplicity: The <educational> element occurs 0 or 1 time within the top-level <lom> element.
Attributes:
None
Elements:
<interactivitytype>
<learningresourcetype>
<interactivitylevel>
<semanticdensity>
<intendedenduserrole>
<context>
<typicalagerange>
<difficulty>
<typicallearningtime>
<description>
<language>
<interactivitytype> Element
Description: This data element describes the type of interactivity supported by the learning resource. The vocabularies defined for this element are restricted vocabularies.
Multiplicity: The <interactivitytype> element occurs 0 or 1 time within the
<educational> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Restricted Vocabulary:
Active
Expositive
Mixed
Undefined
Example:
<educational>
<interactivitytype>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Active</langstring>
</value>
</vocabulary>
</interactivitytype>
</educational>
<learningresourcetype> Element
Description: This data element describes a specific kind of resource, most dominant kind first. The vocabularies defined for this element are recommended best practice vocabularies.
Multiplicity: The <learningresourcetype> element occurs 0 or more times within the
<educational> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Best Practice Vocabulary:
Exercise
Simulation
Questionnaire
Diagram
Figure
Graph
Index
Slide
Table
Narrative Text
Exam
Experiment
Problem Statement
Self Assesment
Example:
<educational>
<learningresourcetype>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Simulation</langstring>
</value>
</vocabulary>
</learningresourcetype>
</educational>
<interactivitylevel> Element
Description: This data element describes the level of interactivity between an end user and the learning resource. The vocabularies defined for this element are restricted vocabularies.
Multiplicity: The <interactivitylevel> element occurs 0 or 1 time within the
<educational> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Restricted Vocabulary:
very low
low
medium
high
very high
Example:
<educational>
<interactivitylevel>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>very high</langstring>
</value>
</vocabulary>
</interactivitylevel>
</educational>
<semanticdensity> Element
Description: This data element describes the subjective mesure of the learning resource’s usefulness as compared to its size or duration. The vocabularies defined for this element are restricted vocabularies.
Multiplicity: The <semanticdensity> element occurs 0 or 1 time within the
<educational> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Restricted Vocabulary:
very low
low
medium
high
very high
Example:
<educational>
<semanticdensity>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>very high</langstring>
</value>
</vocabulary>
</semanticdensity>
</educational>
<intendedenduserrole> Element
Description: This data element describes the normal user of the learning resource, most dominant first. The vocabularies defined for this element are restricted vocabularies.
Multiplicity: The <intendedenduserrole> element occurs 0 or more times within the
<educational> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Restricted Vocabulary:
Teacher
Author
Learner
Manager
Example:
<educational>
<intendedenduserrole>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Learner</langstring>
</value>
</vocabulary>
</intendedenduserrole>
</educational>
<context> Element
Description: This data element describes the typical learning environment where use of learning resource is intended to take place. The vocabularies defined for this element are recommended best practice vocabularies.
Multiplicity: The <context> element occurs 0 or more times within the <educational> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Best Practice Vocabulary:
Primary Education
Secondary Education
Higher Education
University First Cycle
University Second Cycle
University Postgrade
Technical School First Cycle
Technical School Second Cycle
Professional Formation
Continuous Formation
Vocational Training
Example:
<educational>
<context>
<vocabulary>
4
5
6
7
8
9
10
11
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>University Postgrade</langstring>
</value>
</vocabulary>
</context>
12 </educational>
<typicalagerange> Element
Description: This data element describes the age of the typical intended user.
Multiplicity: The <typicalagerange> element occurs 0 or more times within the
<educational> element. The smallest permitted maximum is 5 items.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <typicalagerange> element. However, each langstring is required to contain a different xml:lang attribute).
1 <educational>
2
3
<typicalagerange>
<langstring xml:lang=”en”>adult pilot with 3 years
experience</langstring>
</typicalagerange>
</educational>
Example:
<difficulty> Element
Description: This data element describes how hard it is to work throughout the learning resource for the typical target audience. The vocabularies defined for this element are restricted vocabularies.
Multiplicity: The <difficulty> element occurs 0 or 1 time within the <educational> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Restricted Vocabulary:
very easy
easy
medium
difficult
very difficult
Example:
<educational>
<difficulty>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>medium</langstring>
</value>
</vocabulary>
</difficulty>
</educational>
<typicallearningtime> Element
Description: This data element describes the approximate or typical time it takes to work with the resource.
Multiplicity: The <typicallearningtime> element occurs 0 or 1 time within the
<educational> element.
Attributes:
None
Elements:
<datetime>
<description>
Example:
<educational>
<typicallearningtime>
<datetime>01:30:00</datetime>
</typicallearningtime>
</educational>
<description> Element
Description: This data element comments on how the learning resource is to be used.
Multiplicity: The <description> element occurs 0 or 1 time within the <educational> element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <description> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<educational>
<description>
<langstring>Used for training on in-flight refueling</langstring>
</description>
</educational>
<language> Element
Description: This data element describes the user’s natural language.
Multiplicity: The <language> element occurs 0 or more times within the <educational> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
None
Example:
<educational>
<language>en</language>
</educational>
<rights> Element
Description: This data element describes the conditions of use of the resource.
Multiplicity: The <rights> element must occur 1 and only 1 time within the top-level
<lom> element.
Attributes:
None
Elements:
<cost>
<copyrightandotherrestrictions>
<description>
<cost> Element
Description: This data element describes whether use of the resource requires payment. The vocabularies defined for this element are restricted vocabularies.
Multiplicity: The <cost> element must occur 1 and only 1 time within the <rights> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Restricted Vocabulary:
yes
no
Example:
<rights>
<cost>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>no</langstring>
</value>
</vocabulary>
</cost>
</rights>
<copyrightandotherrestrictions> Element
Description: This data element describes whether copyright or other restrictions apply.
Multiplicity: The <copyrightandotherrestrictions> element must occur 1 and only 1 time within the <rights> element. The vocabularies defined for this element are restricted vocabularies.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Restricted Vocabulary:
yes
no
1 <rights>
2
<copyrightandotherrestrictions>
Example:
3
4
5
6
7
8
9
106
117
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>no</langstring>
</value>
</vocabulary>
</copyrightandotherrestrictions>
12 </rights>
<description> Element
Description: This data element comments on the conditions of use of the resource.
Multiplicity: The <description> element must occur 0 or 1 time within the <rights> element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <description> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<rights>
<description>
<langstring xml:lang=”en”>LOMv1.0</langstring>
</description>
</rights>
<relation> Element
Description: This data element describes the features of the resource in relationship to other learning resources.
Multiplicity: The <relation> element occurs 0 or more times within the top-level <lom> element. The smallest permitted maximum is 100 items.
Attributes:
None
Elements:
<kind>
<resource>
<kind> Element
Description: This data element describes the nature of the relationship between the resource being described and the one identified by 7.2 Relation.Resource. The vocabularies defined for this element are recommended best practice vocabularies.
Multiplicity: The <kind> element occurs 0 or 1 time within the <relation> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Best Practice Vocabulary:
IsPartOf
HasPart
IsVersionOf
HasVersion
IsFormatOf
HasFormat
References
IsReferencedBy
IsBasedOn
IsBasisFor
Requires
IsRequiredBy
Example:
<relation>
<kind>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Requires</langstring>
</value>
</vocabulary>
</kind>
<resource>
<description>
<langstring>Description of resource</langstring>
</description>
</resource>
<catalogentry>
<catalog>ISBN</catalog>
<entry>
<langstring>2-7342</langstring>
</entry>
</catalog>
</catalogentry>
</relation>
<resource> Element
Description: This data element describes the target learning resource that this relationship references.
Multiplicity: The <resource> element occurs 0 or 1 time within the <relation> element.
Attributes:
None
Elements:
<identifier>
<description>
<catalogentry>
Example:
<relation>
<kind>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Requires</langstring>
</value>
</vocabulary>
</kind>
<resource>
<description>
<langstring>Description of resource</langstring>
</description>
</resource>
<catalogentry>
<catalog>ISBN</catalog>
<entry>
<langstring>2-7342</langstring>
</entry>
</catalog>
</catalogentry>
</relation>
<identifier> Element
Description: This data element describes the unique identifier of the other resource.
Multiplicity: The <identifier> element is reserved at this time.
Attributes:
None
Elements:
None
Example:
None – Element is Reserved
<description> Element
Description: This data element describes the other resource.
Multiplicity: The <description> element occurs 0 or 1 time within the <resource> element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <description> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<relation>
<kind>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Requires</langstring>
</value>
</vocabulary>
</kind>
<resource>
<description>
<langstring>Description of resource</langstring>
</description>
</resource>
<catalogentry>
<catalog>ISBN</catalog>
<entry>
<langstring>2-7342</langstring>
</entry>
</catalog>
</catalogentry>
</relation>
<catalogentry> Element
Description: This data element describes the reference to the other resource.
Multiplicity: The <catalogentry> element occurs 0 or more times within the <resource> element. The smallest permitted maximum is 10 items.
Attributes:
None
Elements:
<catalog>
<entry>
Example:
<relation>
<kind>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Requires</langstring>
</value>
</vocabulary>
</kind>
<resource>
<description>
<langstring>Description of resource</langstring>
</description>
</resource>
<catalogentry>
<catalog>ISBN</catalog>
<entry>
<langstring>2-7342</langstring>
</entry>
</catalog>
</catalogentry>
</relation>
<catalog> Element
Description: This data element describes the name of the catalog (i.e. listing identification system).
Multiplicity. The <catalog> element must occur 0 or 1 time within the <catalogentry> element.
Attributes:
None
Elements:
None
1 <relation>
2
3
4
5
6
<kind>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
Example:
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<value>
<langstring xml:lang=“x-none”>Requires</langstring>
</value>
</vocabulary>
</kind>
<resource>
<description>
<langstring>Description of resource</langstring>
</description>
</resource>
<catalogentry>
<catalog>ISBN</catalog>
<entry>
<langstring>2-7342</langstring>
</entry>
</catalog>
</catalogentry>
24 </relation>
<entry> Element
Description: This data element describes actual string value of the entry within the catalog (i.e. listing identification system).
Multiplicity: The <entry> element occurs 0 or 1 time within the <catalogentry> element. If the <catalogentry> element is used, the <entry> element must occur 1 and only 1 time with the <catalogentry> element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <catalogentrycoverage> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<relation>
<kind>
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Requires</langstring>
</value>
</vocabulary>
</kind>
<resource>
<description>
<langstring>Description of resource</langstring>
</description>
</resource>
17
18
<catalogentry>
<catalog>ISBN</catalog>
19
20
21
22
23
<entry>
<langstring>2-7342</langstring>
</entry>
</catalog>
</catalogentry>
24 </relation>
<annotation> Element
Description: This data element comments on the educational use of the learning resource.
Multiplicity: The <annotation> element occurs 0 or more times within the top-level
<lom> element. The smallest permitted maximum is 30 items.
Attributes:
None
Elements:
<person>
<date>
<description>
<person> Element
Description: This data element describes the annotator.
Multiplicity: The <person> element occurs 0 or 1 time within the <annotation> element.
Attributes:
None
Elements:
<vcard>
Example:
<annotation>
<person>
<vcard>
begin:vcard
org: IMS
end:vcard
</vcard>
</person>
</annotation>
<date> Element
Description: This data element describes the date that this annotation was created. Multiplicity: The <date> element occurs 0 or 1 time within the <annotation> element. Attributes:
None
Elements:
<datetime>
<description>
Example:
<annotation>
<date>
<datetime>2001-04-17</datetime>
</date>
</annotation>
<description> Element
Description: This data element describes the content of the annotation.
Multiplicity: The <description> element occurs 0 or 1 time within the <annotation> element. The <description> element is required if the parent <annotation> element is used.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <description> element. However, each langstring is required to contain a different xml:lang attribute).
1 <annotation>
2
3
<description>
<langstring xml:lang=”en”>This simulation can be used in conjunction
with the in-flight refueling course</langstring>
</description>
</annotation>
Example:
<classification> Element
Description: This data element describes the characteristic of the resource via entries in classification schemes.
Multiplicity: The <classification> element occurs 0 or more times within the top-level
<lom> element. The smallest permitted maximum is 40 items.
Attributes:
None
Elements:
<purpose>
<taxonpath>
<description>
<keyword>
<purpose> Element
Description: This data element describes the characteristics of the resource described by this classification entry. The vocabularies defined for this element are recommended best practice vocabularies.
Multiplicity: The <purpose> element occurs 0 or 1 time within the <classification> element.
Attributes:
None
Elements:
<vocabulary>
LOM Defined Vocabularies (<source> element set to LOMv1.0) Best Practice Vocabulary:
Discipline
Idea
Prerequisite
Educational Objective
Accessibility Restrictions
Educational Level
Skill Level
Security Level
<classification>
<purpose>
3
4
5
6
<vocabulary>
<source>
<langstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
Example:
78
9
<val<ulea>ngstring xml:lang=“x-none”>Educational Objective</langstring>
</value>
11
</purpose>
12 </classification>
10 </vocabulary>
<taxonpath> Element
Description: This data element describes a taxonomic path in a specific classification.
Multiplicity: The <taxonpath> element occurs 0 or more times within the top-level
<classification> element. The smallest permitted maximum is 15 items.
Attributes:
None
Elements:
<source>
<taxon>
Example:
<classification>
<taxonpath>
<source>
<langstring>DDC</langstring>
<source>
</taxonpath>
</classification>
<source> Element
Description: This data element describes a specific classification. Any recognized “official” taxonomy.
Multiplicity: The <source> element occurs 0 or 1 time within the <taxonpath> element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <source> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<classification>
<taxonpath>
<source>
<source>
</taxonpath>
</classification>
4 <langstring>DDC</langstring>
<taxon> Element
Description: This data element describes an entry in a classification. An ordered list of taxons creates a taxonomic path: this is a path from a more general to more specific entry in a classification.
Multiplicity: The <taxon> element occurs 0 or more times within the <taxonpath> element. The smallest permitted maximum is 15 items.
Attributes:
None
Elements:
<id>
<entry>
<taxon>
Example:
<classification>
<taxonpath>
<taxon>
4 <id>912</id>
<taxon>
</taxonpath>
</classification>
<id> Element
Description: This data element describes a specific classification. Any recognized “official” taxonomy.
Multiplicity: The <id> element occurs 0 or 1 time within the <taxon> element.
Attributes:
None
Elements:
None
Example:
<classification>
<taxonpath>
<taxon>
4 <id>912</id>
<taxon>
</taxonpath>
</classification>
<entry> Element
Description: This data element describes taxon’s name or label.
Multiplicity: The <entry> element occurs 0 or 1 time within the <taxon> element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <entry> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<classification>
<taxonpath>
<taxon>
<entry>simulation</entry>
<taxon>
</taxonpath>
</classification>
<taxon> Element
Description: See Section 2.2.3.1.9.2.2 for the details on the <metadata> element.
<description> Element
Description: This data element describes a textual description of learning resource relative to its stated purpose.
Multiplicity: The <description> element occurs 0 or 1 time within the <classification> element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <description> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<classification>
<description>
<langstring xml:lang=”en”>
Electronic, computer generated simulation
</langstring>
</description>
</classification>
<keyword> Element
Description: This data element describes the keywords or phrases describing the learning resourceive relative to its stated purpose. The smallest permitted maximum is 40 items.
Multiplicity: The <keyword> element occurs 0 or more times within the
<classification> element. The smallest permitted maximum is 40 items.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <keyword> element. However, each langstring is required to contain a different xml:lang attribute).
Example:
<classification>
<keyword>
<langstring xml:lang=”en”>simulation</langstring>
</keyword>
</classification>
Common Element Types
There are some common structures that are used more than once within the meta-data. The use of these common structures and elements may facilitate the creation of common data storage structures in implementations, and are described in greater detail below.
LangString Element
Description: This data element describes a phrase in a human language.
Multiplicity: The <langstring> element occurs 0 or 1 time within its parent element. However, each langsring is required to contain a different xml:lang attribute. The smallest permitted maximum is 10 items.
Attributes:
xml:lang – represents the human language of the contents of the element. A value of “x-none” is required for <source> and <value> for vocabulary types.
Elements:
None
Example:
<classification>
<keyword>
<langstring xml:lang=”en”>simulation</langstring>
</keyword>
</classification>
Date Type
Description: This data element defines the structure of a Date Type.
Multiplicity: Varies – see parent element.
Attributes:
None
Elements:
<datetime>
<description>
Example:
<datetime>00:00:20</datetime>
<description>
<langstring>Description of Date</langstring>
</description>
<datetime> Element
Description: This data element describes the date expressed as per ISO 8601 standard.
Multiplicity: The <datetime> element occurs 0 or 1 time within its parent element.
Attributes:
None
Elements:
None
<description> Element
Description: This data element describes the description of the date.
Multiplicity: The <description> element occurs 0 or 1 time within its parent element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <description> element. However, each langstring is required to contain a different xml:lang attribute).
Vocabulary Type
Description: This data element defines the vocabulary structure. A Vocabulary is made up of two elements: <source> describes the source of the vocabulary, <value> describes the actual vocabulary term.
Multiplicity: Varies – see parent element.
Attributes:
None
Elements:
<source>
<value>
Example:
<classification>
<purpose>
<vocabulary>
45
6
7
8
9
10
11
<sou<rlcaen>gstring xml:lang=“x-none”>LOMv1.0</langstring>
</source>
<value>
<langstring xml:lang=“x-none”>Educational Objective</langstring>
</value>
</vocabulary>
</purpose>
12 </classification>
<source> Element
Description: This data element defines the source of the value, for instance through a URI.
Multiplicity: The <source> element occurs 0 or 1 time within its parent element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <source> element. However, each langstring is required to contain a different xml:lang attribute).
<value> Element
Description: This data element defines the vocabulary.
Multiplicity: The <value> element occurs 0 or 1 time within its parent element.
Attributes:
None
Elements:
<langstring> - (The <langstring> element can be repeated 1 or more times within the <value> element. However, each langstring is required to contain a different xml:lang attribute).
Electronic Business Card Elements
vCard automates the exchange of personal information typically found on a traditional business card. There are at least 3 elements that require entity information: elements lifecycle.contribute.centity, metametadata.contribute.centity, and annotation.person. These elements specify the vCard specification as the source for representing their data. The vCard specification allows for a rich set of information to be captured as the example below illustrates.
Vcard
Description: The vCard specification defines a “virtual” electronic business card. vCards can store information such as a name, address, telephone number, email address, and so on.
Multiplicity: Varies – see parent element.
Attributes:
None
Elements:
None. At this point, ADL has not chosen a vCard schema for defining the XML structure for vCards.
1 <vcard>
2
3
4
6
begin:vcard fn:Joe Student
addr:111 Elm Street end:vcvard
7 </vcard>
Example:
XML Extension Mechanism
The IMS Learning Resource Meta-data Specification allows for communities to place their own namespaced meta-data elements throughout an IMS Meta-data record. All elements that are labeled as container elements in the Information Model allow for the capability to add extensions. The SCORM carries this practice forward but warns against this practice due to interoperability issues. In the future there may be a need for ADL to extend the IMS Learning Resource Meta-data Information Model. A SCORM Version
1.2 meta-data instance shall not be deemed invalid if it contains proprietary extensions. A conforming system that reads such a meta-data instance may ignore XML elements that are not part of the schema defined in SCORM Version 1.2. The ADL community is asked to provide any potential additions to the meta-data information model. The ADL technical team will pursue these additions through the correct specifications groups.
The SCORM Meta-data Application Profiles
The SCORM Meta-data Application Profiles describe the integration of the IMS Learning Resource Meta-data Version 1.2 Specification within the ADL environment. The application profiles further define the types of meta-data and how they are applied to the content aggregation model described in Section 2.1. The SCORM identifies three types of learning content meta-data: Content Aggregation, SCO and Asset. The following section defines these meta-data application profiles.
Within the SCORM, the SCORM Meta-data Application Profiles are specializations of the IMS Learning Resource Meta-data Specification Version 1.2. The SCORM imposes additional constraints on the application of the specification. Because of this specialization, the SCORM Meta-data Application Profiles fit nicely into the IMS Content Packaging Specification in all of the places that the IMS Content Packaging Specification already accounts for the use of meta-data.
Within the SCORM there are two main types of meta-data: context specific and context independent. Context specific meta-data describes learning content in a particular context – usually, this is a ‘learning’ context within a larger unit of content. Context independent meta-data is meta-data describing learning content in a context (or use) independent manner. The distinction between context specific and context independent meta-data is further specified in Section 2.3 Content Packaging.
The SCORM Version 1.1 contained three application profiles of meta-data: Raw Media, Content and Course. The SCORM Version 1.2 changes the names for the meta-data application profiles to better align with changes to the Content Aggregation Model for the SCORM Version 1.2 and in general with the IMS Content Packaging nomenclature. The name change will harmonize meta-data with packaging to help clear up any confusion.
At this time the requirements for which meta-data elements are mandatory for each application profile will stay the same. The table below shows the SCORM Version 1.1 Meta-data application profiles and the Content Aggregation Model components where the meta-data would be used. The table also shows the mapping to the new SCORM Version
1.2 Meta-data application profile names.
SCORM Version 1.1 Meta-data Application Profile Name | SCORM Version 1.1 Content Aggregation Model Components | SCORM Version 1.2 Meta-data Application Profile Name | SCORM Version 1.2 Content Aggregation Model Components |
Course Meta-data | Course | Content Aggregation Meta-data | Content Aggregation |
Content Meta-data | Block | Content Aggregation Meta-data | Content Aggregation |
Content Meta-data | SCO | SCO Meta-data | SCO |
Raw Media Meta-data | Asset | Asset Meta-data | Asset |
Table 2.2.4.b: The SCORM Meta-data Application Profile Mapping
Content Aggregation Meta-data
Content Aggregation Meta-data is meta-data that describes a content aggregation. This meta-data is used to facilitate reuse and discoverability within a content repository and to provide descriptive information about the content aggregation. Content Aggregation meta-data is:
Information about a content aggregation as a whole that describes what it is for, who can use it, who controls it, etc; and
Information that can be searched externally such as the content aggregation title, description and version.
Sharable Content Object Meta-data
SCO Meta-data is meta-data that can be applied to a SCO that provides descriptive information about the learning resource independent of a particular context. This meta- data is used to facilitate reuse and discoverability of such learning resources within, for example, a content repository. SCO meta-data is:
Meta-data that describes a SCO and;
Meta-data that is not related to a specific content aggregation structure (i.e., context independent meta-data) and;
Information that can be searched externally such as content title, description, date of creation and version.
Asset Meta-data
Asset Meta-data is meta-data that can be applied to Assets such as illustrations, documents, or media streams that provides descriptive information about the Assets independent of learning content. This meta-data is used to facilitate reuse and discoverability principally during learning content creation of such Assets within, for example, a content repository. Asset meta-data is:
Meta-data that describes Assets in a non-context specific way and;
Information that can be searched externally such as Asset title, description, date of creation and version and;
Information that can be used to create a searchable repository of sharable Assets.
The SCORM Meta-data Application Profile Requirements
The following table (Table 2.2.4.4a) defines the requirements for each of the above mentioned meta-data application profiles. Each of the meta-data application profiles are listed with the corresponding requirements for each of the meta-data elements. Note that these requirements do not imply that every Content Aggregation, SCO or Asset must be
described by meta-data. However, the requirements do apply whenever meta-data is used to describe a Content Aggregation, SCO or Asset. An “M” indicates that the element is Mandatory. An “O” indicates that the element is Optional. An “R” indicates that the element is Reserved and should not be used.
Name | Content Aggregation | SCO | Asset |
1.0 general | M | M | M |
1.1 identifier | R | R | R |
1.2 title | M | M | M |
1.3 catalogentry | M | M | O |
1.3.1 catalog | M | M | O |
1.3.2 entry | M | M | O |
1.4 language | O | O | O |
1.5 description | M | M | M |
1.6 keyword | M | M | O |
1.7 coverage | O | O | O |
1.8 structure | O | O | O |
1.9 aggregationlevel | O | O | O |
2.0 lifecycle | M | M | O |
2.1 version | M | M | O |
2.2 status | M | M | O |
2.3 contribute | O | O | O |
2.3.1 role | O | O | O |
2.3.2 centity | O | O | O |
2.3.3 date | O | O | O |
3.0 metametadata | M | M | M |
3.1 identifier | R | R | R |
3.2 catalogentry | O | O | O |
3.2.1 catalog | O | O | O |
3.2.2 entry | O | O | O |
3.3 contribute | O | O | O |
3.3.1 role | O | O | O |
3.3.2 centity | O | O | O |
3.3.3 date | O | O | O |
3.4 metadatascheme | M | M | M |
3.5 language | O | O | O |
4.0 technical | M | M | M |
4.1 format | M | M | M |
4.2 size | O | O | O |
4.3 location | M | M | M |
4.4 requirement | O | O | O |
4.4.1 type | O | O | O |
4.4.2 name | O | O | O |
4.4.3 minimumversion | O | O | O |
4.4.4 maximumversion | O | O | O |
4.5 installationremarks | O | O | O |
4.6 otherplatformrequirements | O | O | O |
4.7 duration | O | O | O |
5.0 educational | O | O | O |
5.1 interactivitytype | O | O | O |
5.2 learningresourcetype | O | O | O |
5.3 interactivitylevel | O | O | O |
5.4 semanticdensity | O | O | O |
5.5 intendedenduserrole | O | O | O |
5.6 context | O | O | O |
5.7 typicalagerange | O | O | O |
5.8 difficulty | O | O | O |
5.9 typicallearningtime | O | O | O |
5.10 description | O | O | O |
5.11 language | O | O | O |
6.0 rights | M | M | M |
6.1 cost | M | M | M |
6.2 copyrightsandotherrestrictions | M | M | M |
6.3 description | O | O | O |
7.0 relation | O | O | O |
7.1 kind | O | O | O |
7.2 resource | O | O | O |
7.2.1 identifier | R | R | R |
7.2.2 description | O | O | O |
7.2.3 catalogentry | O | O | O |
7.2.3.1 catalog | O | O | O |
7.2.3.2 entry | O | O | O |
8.0 annotation | O | O | O |
8.1 person | O | O | O |
8.2 date | O | O | O |
8.3 description | O | O | O |
9.0 classification | M | M | O |
9.1 purpose | M | M | O |
9.2 taxonpath | O | O | O |
9.2.1 source | O | O | O |
9.2.2 taxon | O | O | O |
9.2.2.1 id | O | O | O |
9.2.2.2 entry | O | O | O |
9.3 description | M | M | O |
9.4 keyword | M | M | O |
Table 2.2.4.4a: SCORM Meta-data Application Profile Requirements
SCORM Meta-data Best Practice
This section describes a collection of best practices collected by the ADL Technical Team. It is important to note that the SCORM does not provide specific guidance beyond vocabularies and formatting restrictions pertaining to the use of the meta-data elements.
It is left to organizations and communities to provide specific guidance on how the meta- data elements are to be applied within their organization and community. Any examples provided present one view of how the element can be used.
Use of Vocabularies
The SCORM Version 1.2 has two concepts of vocabularies: Restricted and Best Practice. Restricted, as the name applies, indicates that SCORM meta-data records must adhere to the listed vocabularies. Best practice indicates that ADL recommends the vocabularies listed, however it is not mandatory that the SCORM meta-data records use the vocabularies. With the integration of the IMS Learning Resource Meta-data Version 1.2, an individual’s organization has a defined way of using the organization’s vocabulary for those meta-data elements that are identified as Best Practice. For those elements that are typed as Vocabulary, the following structure is applied:
<source>
<langstring xml:lang=”x-none”>ADL</langstring>
</source>
<value>
<langstring xml:lang=”x-none”>Directed Graphs</langstring>
</value>
The example above illustrates the mechanism for defining and using an organization’s vocabulary. The source element indicates the source of the vocabulary. This can be either a URI or a label identifying the source of the vocabulary. The xml:lang attribute should be set to x-none. This is the value defined in the IMS Learning Resource Meta- data specification to indicate that the value is a token. A token indicates that this is the exact spelling and language to represent the string.
Stand-Alone XML Meta-data Documents
It is expected that each of the three categories of the SCORM meta-data (Asset, SCO and Content Aggregation) will take the form of stand-alone XML documents that conform to the IMS Learning Resource Meta-data XML Binding Specification22.
SCORM meta-data documents are expected to be valid and well-formed XML documents based on the XML Schema Definition (XSD) referenced by the IMS Learning Resource Meta-data XML Binding Specification22.
XML Examples
See the ADLNet (http://www.adlnet.org/) for SCORM Meta-data XML document examples.
Content Packaging
Overview
The purpose of Content Packaging is to provide a standardized way to exchange digital learning resources between different systems or tools. Content Packaging also can define the structure (or organization) and the intended behavior of a collection of learning resources. Content Packaging defines, among other things:
A Manifest file describing the package itself and which contains:
Meta-data about the package and;
An optional Organization section that defines content structure and behavior and;
A list of references to the resources in the package
How to create an XML-based Manifest
Directions for packaging the Manifest and all related physical files into a zip file or on a CD-ROM, etc.
Content packages are expected to be used to move digital learning resources or collections of learning resources between Learning Management Systems (LMS), development tools and content repositories. The Content Packaging specification provide a common “input/output” format that any system can support.
SCORM Content Packaging is a set of specific use examples, or application profiles, of the IMS Content Packaging Specification20. SCORM packaging adheres strictly to the IMS Content Packaging Specification but provides additional explicit implementation guidance for packaging digital learning resources (Assets, Sharable Content Objects and Content Aggregations).
This section is organized as follows:
Content Structure defines a mechanism that can be used to aggregate learning resources into a cohesive unit of instruction (e.g., course, chapter, module, etc.), apply structure and associate learning taxonomies. The Content Structure uses the same information model that existed in SCORM Version 1.1 but is now implemented in Content Packaging. The functionality of the now deprecated “Content Structure Format” in earlier SCORM versions is defined here and implemented in the organization portion of Content Packaging.
IMS Package Description provides an overview of the IMS Content Packaging Structure
The SCORM Content Packaging Information Model defines the information model for packages based directly on the IMS Content Packaging Specification, but augmented with SCORM specific elements (principally in the organization section where SCORM Content Structure is located).
The SCORM Content Package XML Binding also based directly on the IMS Content Packaging XML Binding specification, this defines how to encode the information model into an XML document. This section includes SCORM specific namespaced elements defined in section 2.3.4.
SCORM Content Packaging Application Profiles defines specifically how to create SCORM conformant packages that contain assets, sharable content objects, and content aggregations (courses or topics).
Content Structure
The purpose of content structure is to provide the content developer with the means to author collections of learning resources into a cohesive unit of instruction, apply structure and associate specific behaviors that can be uniformly reproduced across LMS environments.
The content structure can be considered the map used to sequence/navigate through the learning resources defined in the content package. The content structure contains not only the structure of the learning resources, but also all behaviors to be applied to the learning experience.
Content Structure does not define LMS functionality. It is assumed that an LMS may have a private, unique representation for content elements and structure, and that the LMS can export a content structure, within a content package, that can then be imported by another LMS and stored in its local format. The content structure is not intended to place the requirement that LMS systems adopt the content structure model or structure internally.
Content Structure in this document is derived from the Aviation Industry Computer- Based Training Committee (AICC) Computer Managed Instruction4. The AICC specifications define an information model for course structure, properties and objectives. This model was chosen as a starting point since key components of course representation have already been defined by the AICC. The SCORM Content Structure is a modified sub-set of the AICC work.
The Content Structure Information Model contained in this version of the SCORM extracts the element definitions from the SCORM Version 1.1. With this version of the SCORM, the XML “Content Structure Format” defined in the SCORM Version 1.1 is now deprecated. The Content Information Model has been completely mapped into the organization section of Content Packaging. Existing XML CSF files can (and henceforth should) be converted to “organizations” using these Content Packaging specifications.
The IMS Content Packaging Specification provides a framework that includes most of the information that exists within the now deprecated CSF, as well as logical places in which extensions can be added to capture the rest of the information from the content structure.
The IMS Content Packaging model also provides a clean way to inventory and bundle all of the physical files required to deliver the learning resources, as well as to identify relationships between files that belong to one or more learning resources, including externally referenced resources that are not contained as physical files within a package. The IMS Content Packaging Specification separates learning resources from the way those resources are organized, allowing for one or more uses of the same learning resources within different contexts or uses.
As anticipated in the SCORM Version 1.1, the availability of the content packaging specification that entirely subsumes the CSF has caused ADL to deprecate the standalone CSF XML binding. All current CSF elements have been mapped one-to-one to IMS organization elements, to new SCORM namespaced elements or have entirely been moved into the SCORM Meta-data.
Authoring Content and Content Collections
Content Structure provides a means to represent the structure for collections of learning resources. This is a relatively new approach to designing learning content. In the past, CBT authoring tools provided the means to create parts of a course as well as how and when those parts were to be presented to the learner. The creation of content and the content structure were usually developed using the same tools and proprietary data formats. The shift to Internet-based technologies and the notion of building reusable content objects changed the authoring process considerably.
Within the SCORM, it is the LMS that determines the order (sequence) that content is to be provided to a learner. That means that the LMS must know how and when a designer intended learning resources to be presented to the learner. Content Structure, which is located in the organization section of the Content Packaging allows the designer to provide the LMS with this information. This means that authoring a unit of instruction consists of authoring learning resources and also authoring collections of learning resources – perhaps using completely different authoring tools.
In the SCORM there are two distinct products of authoring: authored learning resources that are launched in a browser environment, and authored Content Structure information that is taken in by the LMS and processed during run time. Unlike the older CBT model, the structure information is separate from content and is now fully exposed and standardized so that content collections can run across different LMS environments.
Representing Content Structure
There are multiple parts of Content Structure each intended to define specific aspects of an authored collection of learning resources:
Content Hierarchy: Defines a tree-based representation, much like a table of contents, that groups learning resources into a logical order. In many cases, but not all, this hierarchical tree represents the default order that an author intends for the learner to progress through the material.
Context Specific Meta-data: When learning resources are authored, the developer hopefully also creates associated meta-data for the learning resource describing its purpose, description, name, etc. This learning resource specific meta-data is context independent of where the learning resource might end up being used. When a collection of learning resources is authored, there may be context specific meta-data that describes how the learning resource is to be used in a particular collection. Content Structure provides for optional context specific meta-data.
Sequencing and Navigation: This provides an LMS with the information it needs to determine what learning resource is to be presented to the learner and when. It also should provide the LMS with information for how to present choices to users to navigate through learning resources. For example, the simplest sequencing information could direct the LMS to simply traverse the content tree, one learning resource after the other. More complex sequencing could be based on the completion status of certain learning resources (perhaps those defined as prerequisites), or on more complex computation of user preferences or assessment results. This version of SCORM provides only very simple sequencing capabilities. Work is underway to provide more sophisticated sequencing that supports conditional branching and will be incorporated into the next release of the SCORM.
The Content Structure is intended to represent a wide variety of content aggregation approaches. The content structure can represent a content aggregation ranging from very, very small learning resources – as simple as a few lines of Hypertext Markup Language (HTML) or a short media clip – to highly interactive learning resources that are tracked by an LMS. The Content Structure is neutral about the complexity of content, the number of hierarchical levels of a particular course (i.e., taxonomy) and the instructional methodology employed to design a course.
The following table (Table 2.3.2.2a) depicts examples of several possible curricular taxonomy models.
Model: Army | Model: Air Force | Model: Marine Corps | Model: Canadian |
Course | Course | Course | Course |
Module | Block | Phase | Performance Objective |
Lesson | Module | SubCourse (Annex) | Enabling Objective |
Learning Objective | Lesson | Lesson | Teaching Point |
Learning Step | Learning Objective | Task | O |
Learning Objective | O | ||
Learning Step | O |
Table 2.3.2.2a: Example Curricular Taxonomy Models
Understanding the learning design methodology used during content construction and understanding the different approaches to content aggregation will assist in content reuse and will provide additional information to an LMS when content is moved.
In the SCORM Version 1.1, the curricular taxonomy was represented in the Content Structure Format (CSF). Since the CSF has been deprecated for the SCORM Version 1.2 the curricular taxonomy should be identified in the meta-data describing the content aggregation. The Classification section of the Meta-data can be used to describe the curricular taxonomy.
Content Hierarchy
content
block
sco sco
block
block
sco sco
Authoring a collection of learning resources into a logical structure involves, among other things, organizing the learning resources into a hierarchy. In previous versions of the SCORM, collections of SCOs were grouped into “Blocks”. Blocks could also be grouped together under other blocks. Blocks could be nested any number of levels.
Figure 2.3.2.3a: SCORM Version 1.1 Content Hierarchy Terminology
Depending on the design methodology, this hierarchical grouping might be used to represent concepts like Course, Chapter, Topic, or similar terms that represent how the content is aggregated from smaller individual parts.
organization
item
item
resource
SCO
item
Asset
item
item
item
resource
Asset
item
SCO
resource
resource
During the development of the IMS Content Packaging Specification, it was noted that both the SCORM Content Structure Format and the IMS Packaging Specification shared the same concept of content hierarchy, but different terms were used. In IMS terms, the same hierarchical structure illustrated above might look like:
Figure 2.3.2.3b: SCORM Version 1.2 Content Hierarchy Terminology
The content hierarchy used in older versions of the SCORM in the Content Structure Format maps directly into the organization portion of the IMS specification. The old CSF terms content and block are replaced with the IMS term item. Otherwise, the representation of the hierarchy is the same with one exception: in the older SCORM CSF, only leaf nodes (lowest items in a tree containing no other item) were permitted to point to SCOs. Now any level can optionally point to a learning resource.
Context Specific Meta-data
When learning resources are created, hopefully the author also creates a meta-data document that describes the learning resource so that it can be located and reused elsewhere. Such meta-data is considered context independent since it describes the
learning resource independent of a particular collection that comprises a specific learning strategy. For example, imagine a simple SCO that teaches how to thread a needle. Meta- data describing the SCO might describe the skill to be acquired – inserting thread through the eye of a needle – and might further describe that a simulation is part of the learning experience. This meta-data does not, however, describe how the needle might be used.
When a teaching strategy for a particular topic is created, the author might choose to contextually describe the learning resource for a particular purpose. For example, in a course about dress making, the needle-threading object might use local meta-data to describe the object as an “ancillary reference skill”. Or, in a sail making course the object might be described as a “prerequisite sail making skill”.
Meta-data that is specific to a particular learning strategy is called context specific meta- data and is incorporated in the content hierarchy. Context independent meta-data usually refers to immutable, stand-alone meta-data records for digital assets, content objects, or collections of objects.
Developing and applying meta-data to learning resources and collections of learning resources is a very new concept. Best practices have yet to be developed. In some cases meta-data’s principle role is for discovery and reuse of content. In other cases it is strictly informational and provides authors with design information and intent. Some have theorized that meta-data could be provided to the learner to help them navigate through content. No common usage of meta-data has so far emerged, but provisions have been made in these specifications for a variety of potentially valuable uses of meta-data.
Sequencing and Navigation
Sequencing and navigation are the rules that an LMS must follow in order to present a specific learning experience. The content developer is responsible for defining the rules to which an LMS must adhere. These rules are expressed within Content Structure and encoded in the organization section of Content Packaging. Through this means, the intended behavior of a collection of learning resources may be moved with a package from one LMS environment to another.
Sequencing and navigation is intended to provide, among other things, the means to conditionally branch from one learning resource to other learning resources depending on whether the learner has completed certain material, or, perhaps, attained an acceptable score. Navigation information can inform the LMS as to how a learner might be permitted to select content based on similar information.
In the past, stand-alone Computer Based Training (CBT) authoring tools typically provided proprietary sequencing and navigation features that were encoded in proprietary data formats. The move to browser-based content delivered by an LMS created the need to standardize how sequencing and navigation is defined and encoded so that content aggregations can be moved, used and reused across multiple LMS environments.
However, the standardization process for sequencing and navigation has proved difficult due to the multiplicity of design approaches that are desired by various developer communities.
Thus far, the SCORM has provided limited sequencing and navigation capabilities because it is a difficult and complex subject. There are many, and often divergent, requirements in the learning design community. Few approaches have been shown to solve everyone’s design case. Therefore, ADL is addressing sequencing and navigation in measured increments.
ADL is well aware of the need to define robust sequencing and navigation capabilities within the SCORM. Accordingly, ADL is working with a number of organizations, principally through the IMS Global Learning Consortium, to “fast track” specifications that can be added to the SCORM and thereby provide needed functionality. The following are descriptions of the current “state of the art” as well as anticipated work to be added to the next release of the SCORM.
Sequencing/Navigation Today
The SCORM provides an optional means to sequence through the learning resources using prerequisites. The use of prerequisites is derived from the work done by the AICC4 (see the next section on new work that is underway).
The content package allows for the Item structures to include a sub-element called prerequisites. This element provides a field that can be used to algorithmically represent the sequences of navigation through a content aggregation. This element mirrors certain tracked data elements in the Run-Time Environment Data Model described in the SCORM Run-Time Environment book. The data model provides a means for learning resources to report to an LMS when a particular part of the learning resource is “complete” or “incomplete.” An LMS can then evaluate the statements in prerequisites to determine what learning resource the student should be delivered next. The prerequisites element defines what other parts of the content must have been completed before starting the content aggregation or item. This allows an LMS to compute multiple paths through the learning content.
The statements that are evaluated in prerequisites are determined by the cmi.core.lesson_status data model element of a SCO (see Section 3.4.4 of the SCORM Run-Time Environment book). The lesson_status value works on a per SCO basis. For instance, a content aggregation’s status is determined by the individual members (item) contained within the content aggregation. To state that a content aggregation’s status is complete actually means that all of the members forming the content aggregation are complete. The cmi.core.lesson_status data model element has a restricted vocabulary with the following values:
passed
completed
browsed
failed
not attempted
incomplete
The following table, which is extracted from the AICC CMI001 Guidelines for Interoperability4 document, defines the operators of a prerequisite scripting language called “aicc_script”. These operators define the allowed representation of the logic to be computed by an LMS, and define the way that the logic is to be encoded in the prerequisite elements located in the organization part of Content Packaging.
And & | All elements separated by an & must be compete for the expression to be evaluated as complete. S34 & S36 & S38 SCOs number S34, S36 and S38 must all be complete (“passed” or “completed”) for the group to be considered complete. |
Or | | If any of the elements separated by an | are complete (“passed” or “completed”) the expression is considered true. S34=”passed” | S36=”passed” | S38=”passed” If any one of the SCOs, S34, S36, or S38, are passed then the group is considered complete. |
Not ~ | An operator that returns incomplete (false) if the following element or expression is complete, and returns complete (true) if the following element or expression is incomplete (false). Element Identifier: S34 Requirement: ~S35 The student may enter SCO S34 as long as SCO S35 has not been completed (that is, the status of S35 must be “incomplete”, “failed”, or “not attempted”). If SCO S35 is complete, the student may not enter SCO S34. |
Equals = | An operator that returns true when representations on both sides of the symbol have the same values. Element Identifier: S34 Requirement: S33=”passed” The student may enter SCO S34 if he has passed SCO S33. |
Not equals <> | An operator that returns true when elements on both sides of the symbol have different values. Element Identifier: S34 Requirement: S35<>”passed” The student may enter SCO S34 as long as he or she has not passed SCO S35. Notice the difference between this expression and the example for the not operator. The equivalent of ~S35 is (S35<>”passed” & S35<>”completed”) |
Set {} | A list of learning content elements (SCO or Block) separated by commas and surrounded by curly brackets -- { }. A set differs from a Block, in that the set is defined only for purposes of the prerequisite file. A set has no effect on the structure of the learning content. {S34, S36, S37, S39} SCOs S34, S36, S37 and S39 are part of a set. |
Separator , | The comma is used to separate the members of a set. Each member of the set can be evaluated as a Boolean element – complete or incomplete. {S34, S36, S37, S39} SCOs S34, S36, S37 and S39 are each separated by a comma in this set. |
X* | X is an integer number. This operator means that X or more members of the set that follows must be complete for the expression to be complete (true). Element Identifier: S38 Requirement: 3*{S34, S36, S37, S39} Any three or more of the following SCOs – S34, S36, S37, S39 -- must be complete (“passed” or “completed”) before the student can enter SCO S38. |
Precedence () | The expression inside the parenthesis ( ) must be evaluated before combining its results with other parts of the logical statement. Parentheses may be nested. (Operator precedence is the same as in the C programming language – including the use of parenthesis.) Element Identifier: S39 Requirement: S34 & S35 | S36 In this statement, completing S36 all by itself enables the student to enter S39. Element Identifier: S39 Requirement: S34 & (S35 | S36) Adding the parenthesis, makes it necessary to complete (“passed” or “completed”) at least two units (S36 all by itself is no longer enough) to enter unit S39. |
Figure 2.3.2.3.5a: AICC Scripting Language
In this example the AICC scripting language defined above is in use. This example which uses the AICC scripting language (the only defined language as of this release) illustrates a prerequisite where Items I1 and I2 must have been completed before the Item with these prerequisites may be launched by the LMS. This example is based on the XML binding described in Section 2.3.5
<item identifier=”I0”>
<item identifier=”I1” identifierref=”R_I1”>
<item identifier=”I2” identifierref=”R_I2”>
<item identifier=”I3” identifierref=”R_I3”>
<adlcp:prerequisites type=”aicc_script”> I1&I2</adlcp:prerequisites>
</item>
</item>
Sequencing/Navigation Preview
ADL is currently collaborating with industry, government and academic partners to develop a specification that will enable robust sequencing and navigation information to be associated with sets of packaged learning resources by extending the current content structure described in a content package. This specification will define a method for expressing rules, events and conditions as well as run-time behaviors associated with various sequencing and navigation methods.
This specification will enable systems to deliver learning resources in a predictable manner, while reacting consistently to learners’ interactions with learning resources. The intended approach will foster reusability of learning resources by allowing content developers to define sequencing and navigation behavior externally from, rather than embedded within the actual learning resources. Sequencing and navigation information will be encoded within a content package manifest allowing learning resources to be reused in multiple contexts ( i.e. multiple different manifests, each having their own set of sequencing and navigation information).
ADL will develop and publish Technical Papers that will preview the sequencing and navigation specification. Upon completion and trial implementation of this specification, it is anticipated that the SCORM Version 1.3 will reference this specification.
IMS Package Description
The IMS Content Packaging Specification describes data structures that are used to provide interoperability of Internet-based content with content creation tools, Learning Management Systems (LMS), and run-time environments. The objective of the IMS Content Packaging Specification is to define a standardized set of structures that can be used to exchange content. The scope of the IMS Content Packaging Specification is focused on defining interoperability between systems that wish to import, export, aggregate, and disaggregate packages of learning content.
Content Packaging Overview
An IMS Content Package contains two major components:
A (required) special XML document describing the content organization and resources of the package. The special file is called the Manifest file (imsmanifest.xml) because package content and organization is described in the context of manifests.
The physical files referenced in the Manifest.
Package Interchange File
Manifest
Manifest File
Physical Files
(The actual Content, Media, Assessment, Collaboration And other files)
The following figure (Figure 2.3.3.1a) is a conceptual diagram that illustrates the components of an IMS Content Package.
Meta-data |
Organizations |
Resources |
(sub)Manifest(s) |
Figure 2.3.3.1a: Content Packaging Conceptual Diagram
Package
A package represents a unit of usable (and reusable) content. This may be part of a course that has instructional relevance outside of a course organization and can be delivered independently, as an entire course or as a collection of courses. Once a package arrives at its destination to a run-time service, such as an LMS, the package must allow itself to be aggregated or disaggregated into other packages. A package must be able to stand-alone; that is, it must contain all the information needed to use the packaged contents for learning when it has been unpacked.
Manifest
A Manifest is a description in XML of the resources comprising meaningful instruction. A Manifest may also contain zero or more static ways of organizing the instructional resources for presentation.
The scope of “manifest” is elastic. A Manifest can describe part of a course that can stand by itself outside of the context of a course (an “instructional object”), an entire course, or a collection of courses. It is left up to content developers to describe their content in the way they want it to be considered for aggregation or disaggregation. The general rule is that a package always contains a single top-level Manifest that may contain one or more sub-manifests. The top-level Manifest always describes the package. Any nested sub-manifests describe the content at the level at which the sub-manifest is scoped, such as: course, “instructional object”, or other.
Meta-data
Meta-data is data about data. It is used to describe components in the IMS Content Package at various levels. The meta-data depicted in Figure 2.3.3.1a is used to describe the package as a whole. Meta-data may also exist to describe organizations and resources and would exist as sub-components of these components.
Organizations
The organizations component is used to provide structure to the content. Typically, this structure is provided in the form of a learning taxonomy hierarchy. The IMS Content Packaging Specification does not bind the user to any particular structure. The organizations component provides the means to describe any number of different taxonomies that may be required.
Resources
The resources component can describe external resources, as well as the physical files that the package consists of. These files may be media files, text files, assessment objects or other pieces of data in electronic form. Conceptual groupings and relationships between files can be represented within the resources component. The combination of resources is generally categorized as “content”. The resources are referred to at various points within the organizations component, which provides the structure for the resources.
Physical Files
The physical files component represents the actual files referenced in the resources component. These files may be local files that are actually contained within the content package, or they can be external files that are referenced by a Universal Resource Indicator (URI).
Package Interchange File
The Package Interchange File (PIF) is a representation of the content packaging components within an archive format such as zip, jar, cab, tar, etc. It is not mandatory that a content package be archived as a PIF. The PIF provides a concise Web delivery format that can be used to transport content packages between systems.
The SCORM Content Packaging Information Model
This section presents the SCORM Content Packaging Information Model in the form of a table. The SCORM Content Packaging Information model describes the available data elements that are permitted to build SCORM conformant packages.
Important Note: This information model adheres strictly to the IMS Content Packaging Information Model but extends it to include elements that were formerly defined in the SCORM Version 1.1 Content Structure Information Model. These ADL-specific elements are noted in the explanation field with the notation “ADL Note: This is an ADL extension to the IMS Content Packaging Information Model.” SCORM conforming packages must adhere to the usage of these extensions as defined in the table below, and in the XML binding definitions in section 2.3.5.
The SCORM Content Packaging Information Model | ||||
Nr | Name | Explanation | Multiplicity | Data Type |
1 | Manifest | The first, outermost <manifest> element in the Manifest encloses all the reference data. Subsequent occurrences of the <manifest> elements inside the outermost <manifest> are used to compartmentalize files, meta-data, and organization structure for aggregation, disaggregation, and reuse. All namespace declarations should be declared inside the <manifest> element. | 1 and only 1 | Container |
1.1 | Identifier | An identifier, provided by an author or authoring tool, that is unique within the Manifest. | 1 and only 1 | ID |
1.2 | Version | Identifies the version of the Manifest. | 1 and only 1 | String (smallest permitted maximum: 20 characters) |
2 | Metadata | This element contains context specific meta- data that is used to describe the content of the overall package (Package level meta-data). If meta-data is provided, the meta-data must be valid IMS Learning Resource Meta-data. | 0 or 1 | Container |
2.1 | Schema | Describes the schema that defines the meta- data. This element is optional, however if present it must contain the value of “ADL SCORM”. | 0 or 1 | String (smallest permitted maximum: 100 characters) |
2.2 | Schema Version | Describes the version of the schema that defines the meta-data. This element is optional, however if present it must contain the value of “1.2”. | 0 or 1 | String (smallest permitted maximum: 20 characters) |
2.3 | Location | This element describes the location where the meta-data describing the package may be found. This may be a Universal Resource Indicator (URI). ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. This element can be used to reference a file that contains the meta-data. Either the meta- data is included in-line within the <metadata> element, or this element is used to provide the file location. ADL allows two mechanisms for placing meta-data in a manifest. The choice is up to the content package developer.
| 0 or 1 | String (smallest permitted maximum: 2000 characters) |
2.4 | {Meta-data} | This is where meta-data is placed. ADL Note: ADL allows two mechanisms for placing meta-data in a manifest. The choice is up to the content package developer.
| 0 or 1 | Inline Meta- data Record |
3 | Organizations | Describes one or more structures or organizations for this package. When defining a SCORM Resource Package, this element is required to be empty. When defining a SCORM Content Aggregation Package, this element is required to contain at least one organization sub-element. | 1 and only 1 | Container |
3.1 | Default | Identifies to the system the default organization to use. The value for this field should be an ID Reference to an ID of an Organization. If the Organizations element contains more than one Organization element and the Default element is not provided, the first Organization element encountered is assumed to be the default. | 0 or 1 | IDRef |
3.2 | Organization | This element describes a particular organization. Different views or organizational paths through the content can be described using multiple instances of the Organization element. ADL Note: This element replaces the outermost <block> element defined in the SCORM Version 1.1 CSF. At least one organization element is required for a SCORM Content Aggregation Package. The organization element is not permitted to be present for a SCORM Resource Package. | 0 or more | Container |
3.2.1 | Identifier | An identifier, provided by an author or authoring tool, that is unique within the Manifest. | 1 and only 1 | ID |
3.2.2 | Structure | Has a default value of “hierarchical” for describing the shape of an organization. | 0 or 1 | String (smallest permitted maximum: 200) |
3.2.3 | Title | Title of the organization. ADL Note: This element replaces the <title> sub-element of the outermost <block> element within the SCORM Version 1.1 CSF. | 1 and only 1 | String (smallest permitted maximum: 200) |
3.2.4 | Item | This element describes a node within the organization structure. ADL Note: This element is used to represent <block> and <sco> elements that are defined in the SCORM Version 1.1 CSF. The identifierref attribute is required to be empty (“”) for items that represent <block> elements. A <block> element is just a container for other <block> elements and <sco> elements and does not contain actual content and therefore does not need to reference a resource. The identifierref attribute for items that represent <sco> elements is required to reference a resource that defines a SCO. The parameters attribute of this element replaces the <parameterString> SCORM Version 1.1 CSF element. | 0 or More | Container |
3.2.4.1 | Identifier | An identifier, provided by an author or authoring tool, that is unique within the Manifest. | 1 and only 1 | ID |
3.2.4.2 | Identifier Ref | A reference to a <resource> identifier (within the same package or a submanifest) that is used to resolve the ultimate location of the file. If no identifierref is supplied, it is assumed that there is no content associated with this entry in the organization. | 0 or 1 | String (smallest permitted maximum: 2000 characters) |
3.2.4.3 | Is Visible | Indicates whether or not the title of the item is displayed by the LMS navigation mechanism. If not present, value is assumed to be “true”. | 0 or 1 | Boolean |
3.2.4.4 | Parameters | Static parameters to be passed to the content file at launch time. The parameters attribute of this element replaces the <parameterString> SCORM Version 1.1 CSF element. | 0 or 1 | String (smallest permitted maximum: 1000 characters) |
3.2.4.5 | Title | Title of the item. | 1 and only 1 | String (smallest permitted maximum: 200 characters) |
3.2.4.6 | Item | A sub-node within this item. This is a sub- item and repeats all the parts of 3.2.4 Item. | 0 or More | Container |
3.2.4.7 | Metadata | This element contains context specific meta- data that is used to describe the item. If meta-data is provided, the meta-data must be valid SCORM Content Aggregation Meta- data. | 0 or 1 | Container |
3.2.4.7.1 | Schema | Describes the schema that defines the meta- data. ADL Note: This element is optional, however if present it must contain the value of “ADL SCORM”. | 0 or 1 | String (smallest permitted maximum: 100 characters) |
3.2.4.7.2 | Schema Version | Describes the version of the schema that defines the meta-data. ADL Note: This element is optional, however if present it must contain the value of “1.2”. | 0 or 1 | String (smallest permitted maximum: 20 characters) |
3.2.4.7.3 | Location | This element describes the location where the meta-data describing the organization may be found. This may be a URI. ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. If meta-data is provided, the meta-data must be valid SCORM Content Aggregation Meta- data. This element can be used to reference a file that contains the meta-data. Either the meta- data is included in-line within the <metadata> element, or this element is used to provide the file location. ADL allows two mechanisms for placing meta-data in a manifest. The choice is up to the content package developer.
| 0 or 1 | String (smallest permitted maximum: 2000 characters) |
3.2.4.7.4 | {Meta-data} | This is where meta-data is placed. If meta- data is provided, the meta-data must be valid SCORM Content Aggregation Meta-data. ADL Note: ADL allows two mechanisms for placing meta-data in a manifest. The choice is up to the content package developer.
|
3.2.4.8 | Prerequisites | This element defines what other parts of the learning content must have been completed before starting the Block/SCO. This allows an LMS to compute multiple paths through the learning content. ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. | 0 or 1 | String (smallest permitted maximum: 200) |
3.2.4.8.1 | Type | Defines the scripting language used to represent the prerequisites. ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. Vocabulary List:
| 0 or 1 | Vocabulary (Restricted) |
3.2.4.9 | Max Time Allowed | This element defines the amount of time a student is allowed to have in the current attempt of the SCO represented by the item. ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. This element is only allowed to exist if the parent item element is representing a SCO and not a Block. This element was a sub- element of the <timeLimit> element defined within the SCORM Version 1.1 CSF. The <timeLimit> container element was removed. | 0 or 1 | Timespan |
3.2.4.10 | Time Limit Action | This element defines the action that should be taken when the max time allowed in the current attempt of the SCO represented by the <item> is exceeded. Vocabulary List:
ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. This element is only allowed to exist if the parent item element is representing a SCO and not a Block. This element was a sub- element of the <timeLimit> element defined within the SCORM Version 1.1 CSF. The <timeLimit> container element was removed. | 0 or 1 | Vocabulary (Restricted) |
3.2.4.11 | Data From LMS | This element provides a place for initialization data expected by the SCO represented by the item after launch. This data is unconstrained and undefined. Usage of this element is not yet well defined and should be used with caution. ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. This element is only allowed to exist if the parent item element is representing a SCO and not a Block. This element was a sub- element of the <launch> element defined within the SCORM Version 1.1 CSF. The <launch> container element was removed. | 0 or 1 | String (smallest permitted maximum: 255 characters) |
3.2.4.12 | Mastery Score | This element establishes the passing score for this SCO represented by the <item>. Note that what is considered a passing score often depends on the context of a SCO within the learning content. Some learning content may set the mastery score for a SCO higher than in others. The mastery score should be a normalized value between 0 and 100. ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. This element assumes that the SCO has some content that will report score (such as a test) via the SCORM Run-Time Environment API and data model defined in the SCORM. This element is only allowed to exist if the parent item element is representing a SCO and not a Block. | 0 or 1 | String (smallest permitted maximum: 200) |
3.2.5 | Metadata | This element contains context specific meta- data that is used to describe the organization. If meta-data is provided, the meta-data must be valid SCORM Content Aggregation Meta- data. | 0 or 1 | Container |
3.2.5.1 | Schema | Describes the schema that defines the meta- data. ADL Note: This element is optional, however if present it must contain the value of “ADL SCORM”. | 0 or 1 | String (smallest permitted maximum: 100 characters) |
3.2.5.2 | Schema Version | Describes the version of the schema that defines the meta-data. ADL Note: This element is optional, however if present it must contain the value of “1.2”. | 0 or 1 | String (smallest permitted maximum: 20 characters) |
3.2.5.3 | Location | This element describes the location where the meta-data describing the organization may be found. This may be a URI. ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. If meta-data is provided, the meta-data must be valid SCORM Content Aggregation Meta- data. This element can be used to reference a file that contains the meta-data. Either the meta- data is included in-line within the <metadata> element, or this element is used to provide the file location. ADL allows two mechanisms for placing meta-data in a manifest. The choice is up to the content package developer.
| 0 or 1 | String (smallest permitted maximum: 2000 characters) |
3.2.5.4 | {Meta-data} | This is where meta-data is placed. If meta- data is provided, the meta-data must be valid SCORM Content Aggregation Meta-data. ADL Note: ADL allows two mechanisms for placing meta-data in a manifest. The choice is up to the content package developer.
| 0 or 1 | Inline Meta- data Record |
4 | Resources | A collection of references to resources. There is no assumption of order or hierarchy. | 1 and only 1 | Container |
4.1 | Resource | A reference to a resource. | 0 or More | Container |
4.1.1 | Identifier | An identifier, provided by an author or authoring tool, that is unique within the Manifest. | 1 and only 1 | ID |
4.1.2 | Type | A string that identifies the type of resource. The only current type is “webcontent”, defined as content that can be hosted in or launched by an Internet Browser. This includes:
| 1 and only 1 | String (smallest permitted maximum: 1000 characters) |
4.1.3 | Href | A reference to the “entry point” of this resource. ADL Note: This value will be used as the launch location when Resources are launched. | 1 and only 1 | String (smallest permitted maximum: 2000 characters) |
4.1.4 | SCORM Type | Defines the type of the resource. ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. Vocabulary List:
| 1 and only 1 | Vocabulary (Restricted) |
4.1.5 | Metadata | This element contains context independent meta-data that is used to describe the resource. If the Resource is a SCO, then the meta-data must be valid SCO Meta-data. If the Resource is an Asset, then the meta-data must be valid Asset Meta-data. If the Resource is anything other than a SCO or an Asset, then the meta-data must be valid IMS Learning Resource Meta-data. | 0 or 1 | Container |
4.1.5.1 | Schema | Describes the schema that defines the meta- data. ADL Note: This element is optional, however if present it must contain the value of “ADL SCORM”. | 0 or 1 | String (smallest permitted maximum: 100 characters) |
4.1.5.2 | Schema Version | Describes the version of the schema that defines the meta-data. ADL Note: This element is optional, however if present it must contain the value of “1.2”. | 0 or 1 | String (smallest permitted maximum: 20 characters) |
4.1.5.3 | Location | This element describes the location where the meta-data describing the organization may be found. This may be a URI. ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. If the Resource is a SCO, then the meta-data must be valid SCO Meta-data. If the Resource is an Asset, then the meta-data must be valid Asset Meta-data. If the Resource is anything other than a SCO or an Asset, then the meta-data must be valid IMS Learning Resource Meta-data. This element can be used to reference a file that contains the meta-data. Either the meta- data is included in-line within the <metadata> element, or this element is used to provide the file location. | 0 or 1 | String (smallest permitted maximum: 2000 characters) |
4.1.5.4 | {Meta-data} | This is where meta-data is placed. If the Resource is a SCO, then the meta-data must be valid SCO Meta-data. If the Resource is an Asset, then the meta-data must be valid Asset Meta-data. If the Resource is anything other than a SCO or an Asset, then the meta- data must be valid IMS Learning Resource Meta-data. ADL Note: ADL allows two mechanisms for placing meta-data in a manifest. The choice is up to the content package developer.
| ||
4.1.6 | File | Identifies one or more local files that this resource is dependent on. ADL Note: This element can only be present if the parent resource element is describing a locally referenced SCO or Asset. In the case of the file representing a SCO, the href value must refer to the launch location of a SCO, and this value will be used to run the SCORM Run-Time Environment test. | 0 or More | Container |
4.1.6.1 | Href | A reference to the location of this file. | 0 or 1 | String (smallest permitted maximum: 2000 characters) |
4.1.6.2 | Metadata | This element contains context independent meta-data that is used to describe the file (Asset). If meta-data is provided, the meta- data must be valid SCORM Asset Meta-data. | 0 or 1 | Container |
4.1.6.2.1 | Schema | Describes the schema that defines the meta- data. ADL Note: This element is optional, however if present it must contain the value of “ADL SCORM”. | 0 or 1 | String (smallest permitted maximum: 100 characters) |
4.1.6.2.2 | Schema Version | Describes the version of the schema that defines the meta-data. ADL Note: This element is optional, however if present it must contain the value of “1.2”. | 0 or 1 | String (smallest permitted maximum: 20 characters) |
4.1.6.2.3 | Location | This element describes the location where the meta-data describing the file (Asset) may be found. This may be a URI. ADL Note: This is an ADL extension to the IMS Content Packaging Information Model. If meta-data is provided, the meta-data must be valid SCORM Asset Meta-data. This element can be used to reference a file that contains the meta-data. Either the meta- data is included in-line within the <metadata> element, or this element is used to provide the file location. ADL allows two mechanisms for placing meta-data in a manifest. The choice is up to the content package developer.
| 0 or 1 | String (smallest permitted maximum: 2000 characters) |
4.1.6.3 | {Meta-data} | This is where meta-data is placed. If meta- data is provided, the meta-data must be valid SCORM Asset Meta-data. ADL Note: ADL allows two mechanisms for placing meta-data in a manifest. The choice is up to the content package developer.
| 0 or 1 | Inline Meta- data Record. |
4.1.7 | Dependency | This element contains a reference to a single resource that can act as a container for multiple files that resources may be dependent on. | 0 or More | Empty Element |
4.1.7.1 | Identifier Ref | A reference to the resource. | 1 and only 1 | IDRef |
5 | Manifest | A reusable unit of instruction. Encapsulates meta-data, organizations, and resource references. Mechanism for using (sub)manifests. The structure of this element is represented the same as 1. Manifest. | 0 or More | Container |
The SCORM Content Packaging XML Binding
This section describes the eXtensible Markup Language (XML) binding for the SCORM Content Packaging Information Model. There are some specific rules that have guided the creation of this XML binding:
The XML binding will adhere to the XML 1.0 specification27 of the W3C; and
The XML binding must maintain the definitional structure of the SCORM Content Packaging Information Model.
An XML Schema (XSD) that implements this abstract can be found on ADLNet. The elements of the XML Schema definition are described in each of the following subsections. Figures containing diagrams showing hierarchical views of the elements described by the XSD are included with the descriptions of the elements. These diagrams use a hierarchical notation to show parent/child relationships between elements. The following table describes the symbols within the diagrams.
The following table shows symbols that denote the contents of the element. Elements may contain other elements, or they may be “leaf nodes” and contain data. This table also shows symbols that relate directly to the “Multiplicity” specified for each element. This describes the number of times the element can occur within its parent element, or in the case of the top most element in the document, how many times the element occurs in the XML document.
Symbol | Meaning |
This symbol denotes that the element has one or more child elements. | |
This symbol denotes that the element contains data. | |
This text denotes the XML Schema Definition (XSD) type assigned to the element. | |
(no symbol) | When no multiplicity symbol is present, this denotes that the element may exist one and only one time. |
+ | The plus sign denotes that the element may occur one or more times within its parent element. |
? | The question mark denotes that the element may occur zero or one time within its parent element. |
* | The asterisk denotes that the element may occur zero to many times within its parent element. |
Table 2.3.5a: XML Binding Symbols
The following table (Table 2.3.5b) lists the data types that are used to represent the elements and attributes inside of an imsmanifest.xml record.
Data Type | Description |
Container | This type is used to indicate that the element contains sub-elements and does not actually contain any data value. |
String | A set of characters. The smallest permitted maximum will also be specified. |
Timespan | A length of time in hours, minutes and seconds shown in the following numerical format: HHHH:MM:SS.SS. Hours has a minimum of 2 digits and a maximum of 4 digits. Minutes shall consist of exactly 2 digits. Seconds shall contain 2 digits, |
with an optional decimal point and 1 or 2 additional digits. | |
ID | Element used to uniquely identify an object within an XML instance document. |
IDRef | A reference to an ID. |
Boolean | A string with two values: “true” or “false”. |
Vocabulary | A restricted vocabulary list exists for the element. The element data value must be a value from the vocabulary list. Vocabulary words must be complete and exact matches to the list. |
Table 2.3.5b: Element and Attribute Data Types
<manifest> Elements
Description: The first, outermost <manifest> element in the Manifest encloses all the reference data. Subsequent occurrences of the <manifest> elements inside the outermost
<manifest> are used to compartmentalize files, meta-data and organization structure for aggregation, disaggregation and reuse.
All namespace declarations should be declared inside the <manifest> element.
Data Type: This element is a container element and only contains other elements. Multiplicity: The manifest element is the top-level element for content package. Attributes:
identifier (required) – An identifier, provided by an author or authoring tool, that is unique within the Manifest.
version (optional) – Identifies the version of the Manifest. It is used to distinguish between manifests with the same identifier.
xml:base (optional). This provides a relative path offset for the files contained in the manifest. The usage of this element is defined in the XML Base Working Draft from the W3C. Data type = String.
Elements:
<metadata>
<organizations>
<resources>
<manifest>
Example:
<manifest identifier=”Manifest" version="1.1" xmlns="http://www.imsproject.org/xsd/imscp_rootv1p1p2" xmlns:adlcp="http://www.adlnet.org/xsd/adl_cp_rootv1p1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.imsproject.org/xsd/imscp_rootv1p1p2 imscp_rootv1p1p2.xsd http://www.imsproject.org/xsd/imsmd_rootv1p2 ims_md_rootv1p1.xsd http://www.adlnet.org/xsd/adl_cp_rootv1p1 adl_cp_rootv1p1.xsd">
<!-- imsmanifest contents -->
</manifest>
<metadata> Element
Description: This element contains context specific meta-data that is used to describe the content of the overall package (Package level meta-data). Implementers are free to choose from any of the meta-data elements defined in the IMS Learning Resource Meta- data Specification Version 1.2.
Data Type: This element is a container element and only contains other elements.
Multiplicity: The <metadata> element may occur 0 or 1 time within the <manifest> element.
Attributes:
None
Elements:
<schema>
<schemaversion>
<adlcp:location>
IMS Meta-data
Example:
<metadata>
<schema>ADL SCORM</schema>
<schemaversion>1.2</schemaversion>
<imsmd:lom>
<imsmd:general>
<imsmd:title>
<imsmd:langstring xml:lang="en-US">Simple Manifest</imsmd:langstring>
</imsmd:title>
</imsmd:general>
</imsmd:lom>
</metadata>
<organizations> Element
Description: This element describes one or more structures or organizations for this package.
Data Type: This element is a container element and only contains other elements. When defining a SCORM Resource Package, this element is required to be empty. When defining a SCORM Content Aggregation Package, this element is required to contain at least one organization sub-element.
Multiplicity: The organizations element may occur 0 or 1 time within a <manifest> element.
Attributes:
default (required). Identifies the default organization to use. Data type = IDRef.
Elements:
<organization>
1 <organizations default="TOC1">
2
3
4
5
<organization identifier="TOC1" structure="hierarchical">
<title>default</title>
<item identifier="ITEM1" identifierref="RESOURCE1" isvisible="true">
<title>Lesson 1</title>
<item identifier="ITEM2" identifierref="RESOURCE2" isvisible="true">
<title>Introduction 1</title>
</item>
<item identifier="ITEM3" identifierref="RESOURCE3"
isvisible="true"> 10
11
<title>Content 1</title>
</item>
<item identifier="ITEM4" identifierref="RESOURCE4" isvisible="true">
<title>Summary 1</title>
</item>
</item>
<item identifier="ITEM5" identifierref="RESOURCE5" isvisible="false">
Example:
18
<ittietmle>iLdenstoinfie2r<=/"tIiTtElMe6>" identifierref="RESOURCE6"
isvisible="false">
19
20
21
<title>Introduction 2</title>
</item>
<item identifier="ITEM7" identifierref="RESOURCE7"
isvisible="false"> 22
23
<title>Content 2</title>
</item>
<item identifier="ITEM8" identifierref="RESOURCE8" isvisible="false">
<title>Summary 2</title>
</item>
</item>
<item identifier="ITEM9" identifierref="RESOURCE9" isvisible="true">
<title>Lesson 3</title>
<item identifier="ITEM10" identifierref="RESOURCE10" isvisible="true" parameters="foo">
<title>Introduction 3</title>
</item>
<item identifier="ITEM11" identifierref="RESOURCE11" isvisible="true">
<title>Content 3</title>
</item>
<item identifier="ITEM12" identifierref="RESOURCE12" isvisible="true">
<title>Summary 3</title>
</item>
</item>
</organization>
</organizations>
<resources> Element
Description: A collection of references to resources. There is no assumption of order or hierarchy.
Data Type: This element is a container element and only contains other elements.
Multiplicity: The <resources> element occurs 1 and only 1 time within the <manifest> element.
Attributes:
xml:base (optional). This provides a relative path offset for the content file(s). The usage of this element is defined in the XML Base Working Draft from the W3C. Data type = String.
Elements:
<resource>
Example:
<resources>
<resource identifier="RESOURCE1" type="webcontent" href="lesson1.htm">
<file href="lesson1.htm"/>
</resource>
<resource identifier="RESOURCE2" type="webcontent" href="intro1.htm">
<file href="intro1.htm"/>
</resource>
<resource identifier="RESOURCE3" type="webcontent" href="content1.htm">
<file href="content1.htm"/>
</resource>
<resource identifier="RESOURCE4" type="webcontent" href="summary1.htm">
<file href="summary1.htm"/>
</resource>
</resources>
<metadata> Element
This section defines the make up, attributes and elements, of the <metadata> element. The section also defines any additional ADL requirements defined for the <metadata> Element. See the containing element (<manifest>, <organization>, <item>, <resource> and <file>) for more information on the conformance rules that the meta-data must follow.
<schema> Element
Description: This element describes the schema that defines the meta-data. Data Type: String (smallest permitted maximum of 100 characters) Multiplicity: This element may occur 0 or 1 time within a <metadata> element. Attributes:
None
Elements:
None
Example:
<metadata>
<schema>IMS Metadata</schema>
<schemaversion>1.2</schemaversion>
<imsmd:lom>
<!--IMS Meta-data Elements -->
</imsmd:lom>
</metadata>
<schemaversion> Element
Description: This element describes the version of the schema that defines the meta- data. This element is optional, however if present it must contain the value of “1.2”
Data Type: String (smallest permitted maximum of 100 characters)
Multiplicity: This element may occur 0 or 1 time within a <metadata> element.
Attributes:
None
Elements:
None
Example:
<metadata>
<schema>IMS Metadata</schema>
<schemaversion>1.2</schemaversion>
<imsmd:lom>
<!--IMS Meta-data Elements -->
</imsmd:lom>
</metadata>
<adlcp:location>
Description: This element describes the location where the meta-data describing the Content Packaging component may be found. This may be a Universal Resource Indicator (URI). This is an ADL namespaced element extension to the IMS Content Packaging Specification. The meta-data creator has two options for expressing meta-data in a Content Package. The creator can either use the <adlcp:location> element to express the location of the meta-data record or place the meta-data inline within the Manifest file.
Data Type: String (smallest permitted maximum of 2000 characters) Multiplicity: This element may occur 0 or 1 time within a <metadata> element. Attributes:
None
Elements:
None
1 <metadata>
2
3
4
<schema>IMS Metadata</schema>
<schemaversion>1.2</schemaversion>
<adlcp:location>course/metadata/course.xml</adlcp:location>
5 </metadata>
Example:
{Meta-data}
Description: This is the second option for the meta-data creator for expressing meta- data in a Manifest. The meta-data creator can select to follow the XML Binding for the IMS Learning Resource Meta-data to place the meta-data inline.
Example:
<metadata>
<schema>IMS Metadata</schema>
<schemaversion>1.2</schemaversion>
<imsmd:lom>
<!--IMS Meta-data Elements -->
5 </imsmd:lom>
7 </metadata>
<organizations> Element
This section defines the make up, attributes and elements, of the <organizations> element. The section also defines any additional ADL requirements defined for the
<organizations> element.
<organization>
Description: This element describes a particular organization.
Data Type: This element is a container element and only contains other elements.
Multiplicity: The <organization> element may occur 0 or more times within an
<organizations> element. At least one organization element is required for a SCORM Content Aggregation Package. The organization element is not permitted to be present for a SCORM Resource Package.
Attributes:
identifier (required). An identifier, provided by an author or authoring tool, that is unique within the Manifest. Data type = ID
structure (optional). Assumes a default value of “hierarchical,” such as is common with a tree view or structural representation of data. Data type = String
Elements:
<title>
<item>
<metadata>
Example:
<organization identifier="TOC1">
<title>default</title>
<item identifier="ITEM1" identifierref="RESOURCE1" isvisible="true">
<title>Lesson 1</title>
</item>
<item identifier="ITEM2" identifierref="RESOURCE2" isvisible="true">
78
</it<etmi>tle>Introduction 1</title>
9 </organization>
<title>
Description: This data element describes the title of the organization. Data Type: String (smallest permitted maximum of 100 characters) Multiplicity: The <title> element must occur 1 and only 1 time within an
<organization> element.
Attributes:
None
Elements:
None
Example:
<organization identifier="TOC1">
<title>Some Title</title>
<item>
Description: This element describes a node within the organization structure.
Data Type: This element is a container element and only contains other elements.
Multiplicity: The <item> element may occur 0 or More times within the <organization> element and/or 0 or More times within an <item> element. The <item> element can be nested any number of levels deep inside of another <item> element.
Attributes:
identifier (required). An identifier that is unique within the Manifest. Data type = ID.
identifierref (optional). A reference to a <resource> identifier (within the same package) or a (sub)Manifest that is used to resolve the ultimate location of the file. If no identifierref is supplied, it is assumed that there is no content associated with this entry in the organization. Data type = String.
isvisible (optional). Indicates whether or not the title of the item is displayed by the LMS navigation mechanism. If not present, value is assumed to be “true”. Data type = Boolean
parameters (optional). Static parameters to be passed to the content file at launch time. Data type = String.
Elements:
<title>
<item>
<metadata>
<adlcp:prerequisites>
<adlcp:maxtimeallowed>
<adlcp:timelimitaction>
<adlcp:datafromlms>
<adlcp:masteryscore>
Example:
<item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">
<title>Content 1</title>
</item>
<title> Element
Description: This data element describes the title of the item.
Data Type: String (smallest permitted maximum of 200 characters)
Multiplicity: The <title> element must occur 1 and only 1 time within an <item> element.
Attributes:
None
Elements:
None
Example:
<item identifier="ITEM1">
<title>Some Title for the Item</title>
<item> Element
Description: The <item> element can be nested any number of levels deep within any other <item> element. See Section 2.3.5.3.1.2 for details on the <item> element.
<metadata> Element
Description: The <metadata> element contains context specific meta-data that is used to describe the item. See Section 2.3.5.2 for the details on the <metadata> element.
The meta-data for any <item> element must be conformant SCORM Content Aggregation Meta-data.
<adlcp:prerequisites> Element
Description: This element defines what other parts of the learning content must have been completed before starting the <item>. This allows an LMS to compute multiple paths through the learning content. This is an ADL extension to the IMS Content Packaging Information Model.
Data Type: String (smallest permitted maximum: 200)
Multiplicity: The <adlcp:prerequisites> element may occur 0 or 1 time within an <item> element.
Attributes:
type (required) - Defines the scripting language used to represent the prerequisites. This is an ADL extension to the IMS Content Packaging Information Model.
Vocabulary List:
aicc_script
Elements: None
Example:
<item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">
<title>Content 1</title>
<adlcp:prerequisites type=”aicc_script”>R1&R2</adlcp:prerequisites>
</item>
<adlcp:maxtimeallowed> Element
Description: This element defines the amount of time a student is allowed to have in the current attempt of the <item>.
This is an ADL extension to the IMS Content Packaging Information Model.
This element is only allowed to exist if the parent <item> element is representing a SCO and not a Block. This element was a sub-element of the <timeLimit> element defined within the SCORM Version 1.1 CSF
Data Type: Timespan
Multiplicity: The <adlcp:maxtimeallowed> element may occur 0 or 1 time within an
<item> element.
Attributes:
None.
Elements:
None
Example:
<item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">
<title>Content 1</title>
<adlcp:maxtimeallowed>00:30:00</adlcp:maxtimeallowed>
</item>
<adlcp:timelimitaction> Element
Description: This element defines the action that should be taken when the max time allowed in the current attempt of the <item> is exceeded.
Vocabulary List:
exit,message
exit,no message
continue,message
continue,no message
This is an ADL extension to the IMS Content Packaging Information Model.
This element is only allowed to exist if the parent item element is representing a SCO and not a Block. This element was a sub-element of the <timeLimit> element defined within the SCORM Version 1.1 CSF.
Data Type: Vocabulary (restricted)
Multiplicity: The <adlcp:timelimitaction> element may occur 0 or 1 time within the
<item> element.
Attributes:
None
Elements:
None
Example:
<item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">
<title>Content 1</title>
<adlcp:timelimitaction>exit,no message</adlcp:timelimitaction>
</item>
<adlcp:datafromlms> Element
Description: This element provides a place for initialization data expected by the resource represented by the <item> after launch. This data is unconstrained and undefined. Usage of this element is not yet well defined and should be used with caution.
ADL Note: This is an ADL extension to the IMS Content Packaging Information Model.
This element is only allowed to exist if the parent item element is representing a SCO and not a Block. This element was a sub-element of the <launch> element defined within the SCORM Version 1.1 CSF.
Data Type: String (smallest permitted maximum of 255 characters)
Multiplicity: The <adlcp:datafromlms> element may occur 0 or 1 time within an <item> element.
Attributes:
None
Elements:
None
Example:
<item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">
<title>Content 1</title>
<adlcp:datafromlms>Some information about the learning resource</adlcp:datafromlms>
</item>
<adlcp:masteryscore> Element
Description: This element establishes the passing score for the <item>. Note that what is considered a passing score often depends on the context of a <item> within the learning content. Some learning content may set the mastery score for an <item> higher than in others. The mastery score should be a normalized value between 0 and 100.
This is an ADL extension to the IMS Content Packaging Information Model.
This element assumes that the <item> has some content that will report score (such as a test) via the SCORM Run-Time Environment API and data model defined in the SCORM.
This element is only allowed to exist if the parent item element is representing a SCO and not a Block.
Data Type: String (smallest permitted maximum of 200 characters)
Multiplicity: The <adlcp:masteryscore> element may occur 0 or 1 time within an
<item> element.
Attributes:
None
Elements:
None
Example:
<item identifier="ITEM3" identifierref="RESOURCE3" isvisible="true">
<title>Content 1</title>
<adlcp:masteryscore>90</adlcp:masteryscore>
</item>
<metadata> Element
Description: The <metadata> element contains context specific meta-data that is used to describe the organization. See Section 2.3.5.2 for the details on the <metadata> element.
The meta-data for any <organization> element must be conformant SCORM Content Aggregation meta-data.
<resources> Elements
This section defines the make up, attributes and elements, of the <resources> element. The section also defines any additional ADL requirements defined for the <resources> Element
<resource> Element
Description: This element describes a specific content file.
Data Type: This element is a container element and only contains other elements.
Multiplicity: The <resource> element may occur 0 or more times within the
<resources> element.
Attributes:
identifier (required). An identifier, provided by the author or authoring tool, that is unique within the Manifest.
type (required). A string that identifies the type of resource. This specification defines only type “webcontent”.
adlcp:scormtype (required). Defines the type of the SCORM resource. This is an ADL extension to the IMS Content Packaging Information Model. Data Type: Restricted vocabulary of either “sco” or “asset”.
href (required). A reference to the “entry point” of this resource. External fully- qualified URIs are also permitted.
xml:base (optional). This provides a relative path offset for the content file(s). The usage of this element is defined in the XML Base Working Draft from the W3C. Data type = string.
Elements:
<metadata>
<file>
<dependency>
Example:
1 <resources>
2
<resource identifier="R_A2" type="webcontent" adlcp:scormtype=”sco”
3href="sco1<.mhetald"a>ta/>
4
5
6
<file href="sco1.html"/>
</resource>
<resource identifier="R_A5" type="webcontent" adlcp:scormtype=”asset”
href="pics\distress_sigs_add.jpg">
<metadata/>
<file href="pics\distress_sigs_add.jpg"/>
</resource>
</resources>
<metadata> Element
Description: The <metadata> element contains context independent meta-data that is used to describe the resource. See Section 2.3.5.2 for the details on the <metadata> element.
The meta-data for any <resource> element must be conformant to the following:
If the <resource> is a SCO, then the meta-data must be conformant to the SCO meta-data.
If the <resource> is an Asset, then the meta-data must be conformant to the SCORM Asset meta-data.
If the <resource> is not a resource identified by the SCORM Content Aggregation Model, then the meta-data must be conformant IMS Learning Resource Meta- data.
<file> Element
Description: Identifies one or more local files that this resource is dependent on.
Data Type: The <file> element is a Container
Multiplicity: The <file> element may occur 0 or more times within a <resource> element.
Attributes:
href (required). URL of the file. This implies that the file is locally stored within the package. Data Type – String (smallest permitted maximum of 2000 characters).
Elements:
<metadata>
Example:
1. <file href="topics/index.htm"/>
<metadata> Element
Description: The <metadata> element contains context independent meta-data that is used to describe the individual file. See Section 2.3.5.2 for the details on the <metadata> element.
The meta-data for any <file> element must be conformant with the SCORM Asset Meta- data.
<dependency> Element
Description: This element contains a reference to a single resource that can act as a container for multiple files that resources may be dependent on.
Data Type: This element should be represented as an empty element (<dependency identifierref=”ID111”/>
Multiplicity: The <dependency> element may occur 0 or more times within a
<resource> element.
Attributes:
identifierref (required). An identifier for other resources to reference. Data Type – IDRef
Elements:
None
1 <resources>
2
<resource identifier="R_A2" type="webcontent" adlcp:scormtype=”sco”
href="sco1.html">
3
4
5
6
<metadata/>
<file href="sco1.html"/>
<dependency indentiferref="R_A5"/>
</resource>
<resource identifier="R_A5" type="webcontent" adlcp:scormtype=”asset” href="pics\distress_sigs_add.jpg">
<metadata/>
<file href="pics\distress_sigs_add.jpg"/>
</resource>
</resources>
Example:
<manifest> Elements
Description: Subsequent occurrences of the <manifest> elements inside the outermost
<manifest> are used to compartmentalize files, meta-data, and organization structure for aggregation, disaggregation, and reuse.
All namespace declarations should be declared inside the <manifest> element.
Data Type: This element is a container element and only contains other elements.
Multiplicity: The manifest element is the root element for content package.
Attributes:
identifier (required) – An identifier, provided by an author or authoring tool, that is unique within the Manifest.
version (optional) – Identifies the version of the Manifest. It is used to distinguish between manifests with the same identifier.
Elements:
<metadata>
<organizations>
<resources>
<manifest>
XML Extension Mechanism
The IMS Content Packaging allows for communities to place their own namespaced elements throughout the imsmanfiest XML record. The SCORM carries this practice forward but warns against this practice due to interoperability issues. In the future there may be a need for ADL to extend, additionally, the IMS Content Packaging Information model. A SCORM 1.2 manifest shall not be deemed invalid if it contains proprietary extensions. A conforming system that reads such a manifest may ignore XML elements that are not part of the schema defined in SCORM 1.2. The ADL community is asked to provide any potential additions to the Content Packaging Information Model. The ADL technical team will pursue these additions through the correct specifications groups.
Content Packaging Application Profiles
The SCORM Packaging Application Profiles describe how the IMS Content Packaging Specification will be applied within the overall context of the SCORM. They provide practical guidance for implementers and define the SCORM conformance requirements. The IMS Content Packaging Specification will be used as the basis for packaging SCORM conformant content. However, the SCORM will impose additional packaging requirements to ensure sufficient information is included in each package. This will enable SCORM conformant learning systems to import and export packages that can be used by other SCORM conformant learning systems.
The SCORM introduces the Content Aggregation Model (Section 2.1.2) which defines a generalized framework for object based learning content. The components are Assets, Sharable Content Objects (SCOs) and Content Aggregations. There are currently two SCORM Packaging Application Profiles, which describe how to package Content Aggregation Model components, identified: Resource Packages and Content Aggregation
Packages. The following sections describe the application profiles, the constraints imposed by SCORM and a set of recommended best practice recommendations.
Resource Package
Learning content in its most basic form is composed of Assets that are electronic representations of media, text, images, sound, Web pages, assessment objects or other pieces of data that can be delivered to a Web client.
A SCO is a collection of one or more Assets that utilizes the SCORM Run-Time Environment to communicate with LMSs. A SCO represents the lowest level of content granularity that is tracked by an LMS using the SCORM Run-Time Environment.
The SCORM Resource Package Application Profile defines a mechanism for packaging learning resources (for example, Assets and SCOs) without having to provide a specific organization, learning context, or curricular taxonomy. Packaging learning resources provides a common medium for exchange. The SCORM Content Package is merely a collection of reusable learning resources that can be transferred between learning systems.
In many cases an Asset or a SCO will be comprised of a single file. However, there are cases where Assets and SCOs could be comprised of multiple files. The SCORM Resource Package Application Profile allows for packaging Assets and SCOs comprised of single or multiple files. Also, Assets and SCOs may be included locally in the package or may be referenced externally. Locally packaged files will be included as physical files within the overall package. When externally referenced, the Assets and SCOs will not be included as physical files within the package, but will instead be referenced by an URL.
The following figures depict several resource packages. The examples show a sample imsmanifest.xml record and how Assets and SCOs could be represented. Figure 2.3.6.1a shows an example of an Asset being represented as a <file> element in a imsmanifest.xml instance.
<manifest>
<organizations>
<organization>
<title>
<item>
<title>
<item>
<item>
<item>
</item>
</organization>
</organizations>
<resources>
<resource href=“sco01.htm” adlcp:scormtype=“sco” identifier=“sco01_01”>
<file href=“image1.jpg”>
<metadata>
<schema>ADL SCORM</schema>
<schemaversion>1.2</schemaversion>
<adlcp:location>image1.xml</adlcp:location>
</metadata>
Asset
</file>
Asset Meta-data
</resource>
</resources>
</manifest>
Figure 2.3.6.1a: Example of an Asset represented as a <file> element
Figure 2.3.6.1b shows an example of an Asset being represented as a <resource> element in an imsmanifest.xml instance.
<manifest>
<organizations>
<organization>
<title>
<item>
<title>
<item>
<item>
<item>
</item>
</organization>
</organizations>
<resources>
<resource href=“index.htm”
adlcp:scormtype=“asset” identifier=“R_01”>
<metadata>
<schema>ADL SCORM</schema>
<schemaversion>1.2</schemaversion>
<adlcp:location>R_01.xml</adlcp:location>
</metadata>
<file href=“image1.jpg”>
<metadata>
<schema>ADL SCORM</schema>
<schemaversion>1.2</schemaversion>
<adlcp:location>image1.xml</adlcp:location>
</metadata>
</file>
</resource>
</resource>
</resources>
</manifest>
Asset
Asset Meta-data
Figure 2.3.6.1b : Example of an Asset represented as a <resource> element
Figure 2.3.6.1c shows an example of a SCO being represented as a <resource> element in an imsmanifest.xml instance.
<manifest>
<organizations>
<organization>
<title>
<item>
<title>
<item>
…
</item>
</organization>
</organizations>
<resources>
<resource href=“sco01.htm” adlcp:scormtype=“sco” identifier=“sco01_01”>
<metadata>
<schema>ADL SCORM</schema>
<schemaversion>1.2</schemaversion>
SCO
</metadata>
<file href=“image1.jpg”>
<metadata>
<schema>ADL SCORM</schema>
<schemaversion>1.2</schemaversion>
SCO
Meta-data
Asset
</metadata>
</file>
</resource>
…
</resources>
</manifest>
Asset Meta-data
<adlcp:location>image1.xml</adlcp:location>
<adlcp:location>sco01.xml</adlcp:location>
Figure 2.3.6.1c : Example of a SCO represented as a <resource> element
Content Aggregation Package
The old SCORM Version 1.1 CSF provided a means to represent the structure and curricular taxonomy for courses, or portions of courses built from SCOs. The SCORM does not impose any particular structure for content aggregation. Individual content developers are free to aggregate content into any structure that provides value to them. The SCORM Version 1.1 CSF was, however, not appropriate for content packaging. The IMS Content Packaging Specification Version 1.1 model provides a framework that includes most of the information that exists within the CSF, as well as logical places in which ADL extensions can be added to capture the rest of the information from the CSF. Additionally, the IMS packaging model also provides a clean way to inventory and bundle all of the physical files required to deliver the content, as well as to identify relationships between files that belong to one or more content "resources", including externally referenced resources that are not contained as physical files within a package.
The IMS Content Packaging Specification also enables a separation of content resources from the way those resources can be organized, allowing for one or more uses of the same content resources within different contexts or uses. The SCORM defines a mechanism for packaging the files and providing the structure.
Figure 2.3.6.2a shows an example of a Content Aggregation being represented in an imsmanifest.xml instance.
<manifest>
<organizations>
<organization>
<title>
<item>
…
</item>
</organization>
</organizations>
<resources>
<resource href=“index.htm” adlcp:scormtype=“sco” identifier=“R_01”>
<metadata>
<schema>ADL SCORM</schema>
<schemaversion>1.2</schemaversion>
<adlcp:location>R_01.xml</adlcp:location>
</metadata>
<file href=“index.htm”/>
<file href=“image1.jpg”>
<metadata>
<schema>ADL SCORM</schema>
<schemaversion>1.2</schemaversion>
<adlcp:location>image1.xml</adlcp:location>
</metadata>
</file>
</resource>
…
</resources>
</manifest>
SCO
Asset
Content Structure Information Model
Figure 2.3.6.2a : Content Aggregation Package
Recommended Best Practice
Packaging Multiple Courses
There may be situations where a content developer would like to package multiple distinct course for delivery into a system. This situation can be done by bundling each course up in separate (sub)manifests.
If a content developer wants to move multiple courses in a Package (a curriculum), the content developer would use a top-level manifest to contain each course level manifest and any instructional object manifests that each course might contain.
Multiple Organizations for a Single Course
The content package allows for representations of multiple organizations for its resources. These muliple organizations, however, must be different views or organizational paths through the resources. If content developers would like to package up and move multiple courses, then those courses should be created in separate sub(manifests).
Packaging Learning Content for Reuse
The scope of a manifest is elastic. A manifest can describe part of a course that can by itself outside of the context of a course (an instructional object), an entire course, or a collection of courses. This decision is given to content developers to describe their content in the way they want it to be considered for aggregation or dissaggregation.
The general rule is that a Package always contains a single top-level manifest that may contain one or more (sub)manifests. The top-level manifest always describes the Package. Any nested (sub)manifests describe the content at the level to which the (sub)manifest is scoped, such as a course, instructional object, or other.
For example, if all content comprising a course is tightly couple that no part of it may be presented out of the course context, a content developer would want to use a single manifest to describe that course’s resources and organization. However, content developers who create ‘instructional objects’ that could be recombined with other ‘instructional objects’ to create different course presentations would want to describe each ‘instructional object’ in its own manifest, then aggregate those manifests into a higher level manifest containing a course organization.
XML Examples
See the ADLNet (http://www.adlnet.org/) for SCORM Content Packaging examples.
This page intentionally left blank.
ACRONYM LIST
This page intentionally left blank.
ADL | Advanced Distributed Learning |
AICC | Aviation Industry CBT Committee |
API | Application Program Interface |
ARIADNE | Alliance of Remote Instructional Authoring & Distribution Networks for Europe |
ASCII | American Standard Code for Information Interchange |
AU | Assignable Unit |
AWT | Abstract Window Toolkit |
CBI | Computer-Based Instruction |
CBT | Computer-Based Training |
CDATA | Character Data |
CMI | Computer Managed Instructions |
COTS | Commercial Off-The-Shelf |
CSF | Content Structure Format |
DC | Dublin Core |
DoD | Department of Defense |
DOL | Department of Labor |
DTD | Document Type Definition |
HTML | Hypertext Markup Language |
HTTP | HyperText Transfer Protocol |
IDA | Institute for Defense Analyses |
IEEE | Institute of Electrical and Electronics Engineers |
ISO | International Organization for Standardization |
ITS | Intelligent Tutoring Systems |
LMS | Learning Management System |
LOM | Learning Objects Metadata |
LTSC | Learning Technology Standards Committee |
MIME | Multipurpose Internet Mail Extensions |
NGB | National Guard Bureau |
OSTP | Office of Science and Technology Policy |
PCDATA | Parsable Character Data |
SCO | Sharable Content Object |
SCORM | Sharable Content Object Reference Model |
URI | Universal Resource Identifier |
URL | Universal Resource Locator |
W3C | World Wide Web Consortium |
WWW | World Wide Web |
XML | eXtensible Markup Language |
This page intentionally left blank.
REFERENCES
This page intentionally left blank.
Aviation Industry CBT (Computer-Based Training) Committee. (http://www.aicc.org/)
Institute of Electrical and Electronics Engineers (IEEE) Learning Technology Standards Committee (LTSC). (http://ltsc.ieee.org/)
IMS Global Learning Consortium, Inc. (http://www.imsglobal.org/)
AICC/CMI CMI001 Guidelines for Interoperability Version 3.4. October 23, 2000. Includes: AICC Course Structure Format, AICC CMI Data Model
Executive Order 13111 1999 January 12: Using Technology To Improve Training Opportunities for Federal Government Employees.
Gettinger, M. (1984) Individual differences in time needed for learning: A review of the literature. Educational Psychologist, 19,15-29.
Graesser, A. C., & Person, N. K. (1994). Question asking during tutoring. American Educational Research Journal, 31, 104-137.
Bloom, B.S. (1984). The 2 sigma problem: The search for methods of group instruction as effective as one-to-one tutoring. Educational Researcher, 13, 4-16.
Fletcher, J. D. (in press) Evidence for Learning from Technology-Assisted Instruction. In H. F. O’Neil Jr. and R. Perez (Eds.) Technology Applications in Education: A Learning View. Hillsdale, NJ: Lawrence Erlbaum Associates.
Alliance of Remote Instructional Authoring and Distribution Networks for Europe (ARIADNE). (http://www.ariadne-eu.org/)
Gibbons, A.S. & Fairweather, P.G. Computer-based Instruction. (2000) In, S. Tobias and J.D. Fletcher (Eds.), Training and Retraining: A Handbook for Business, Industry, Government, and the Military. New York: Macmillan Gale Group.
Suppes, P. (1964) Modern learning theory and the elementary-school curriculum. American Educational Research Journal, 1, 79-93.
Carbonell, J. R., “AI in CAI: An Artificial Intelligence Approach to Computer- Assisted Instruction,” IEEE Transactions on Man-Machine Systems, Vol. 11, 1970,
pp. 190-202.
Sleeman, D, & Brown, J. S. (Eds.) (1982) Intelligent Tutoring Systems. New York, NY: Academic Press, 1982.
Woolf, B.P., & Regian, J.W. (2000). Knowledge-based training systems and the engineering of instruction. In S. Tobias and J. D. Fletcher (Eds.), Training and retraining: A handbook for business, industry, government, and the military (339- 356). New York: Macmillan Reference.
Gibbons, A.S. & Fairweather, P.G. (1998) Computer-based Instruction: Design and Development. Englewood-Cliffs, NJ: Educational Technology Publications.
Gibbons, A.S. & Fairweather, P.G. (2000) op. cit.
IMS Content Packaging Specification Version 1.1.2 Available at: http://www.imsglobal.org/.
IEEE Information Technology - Learning Technology - Learning Objects Metadata LOM: Working Draft v6.1 (2001-05-03) As referenced by the IMS Learning Resource Meta-data Specification Version 1.2.
IMS Learning Resource Meta-data Specification Version 1.2.
Includes: IMS Learning Resource Meta-data Information Model, IMS Learning Resource Meta-data XML Binding Specification, and IMS Learning Resource Meta- data Best Practice and Implementation Guide
ISO 639: This is an international standard for the representation of languages. Version 1 uses two-letter language codes, e.g. ’en’ for English, ’fr’ for French, ’nl’ for Dutch, etc. These language codes are a basis for the IETF registry of language tags, as specified in RFC 1766: Tags for the identification of languages.
ISO 3166: This is an international standard for the representation of country names,
e.g. ’BE’ for Belgium, ’CA’ for Canada, ’FR’ for France, ’GB’ for United Kingdom, ’US’ for United States, etc.
vCard: This standard defines how contact details for people and organizations can be represented.
ISO 8601: This is an international standard that specifies numeric representations of date and time.
World Wide Web Consortium (W3C). http://www.w3c.org/
Includes: Universal Resource Locator, Universal Resource Identifier, Extensible Markup Language Version 1.0, Document Object Model (DOM) Specification.
REVISION HISTORY
This page intentionally left blank.
SCORM Version | Release Date | Description of Change |
1.1 | 16-Jan-2001 | Meta-data changes
1.1 DTD CSF changes
|
1.2 | 01-Oct-2001 | Section 2.1 (Content Aggregation Model) changes: Removed old Section 2.1.1 – Content Terminology Inconsistencies and replaced with replaced with Meta-data (section 2.1.3 in previous version) and Content Packaging (2.1.5 in previous version). Updated Figures 2.1.2a and 2.1.2c. The rest of this section contains grammar enhancements and refinements. Section 2.2 (Meta-Data) changes: This section has been broken up into 5 main subsections:
|
|
practice vocabulary list. This element is now a Vocabulary type. It no longer allows a maximum of |
1024 characters, bound within a langstring element.
|
from 8 to 10 items supported.
|
practice vocabulary list. This element is now a Vocabulary type. It no longer allows a maximum of 128 characters, bound within a langstring element.
|