Advanced Distributed Learning Initiative


Sharable Content Object Reference Model (SCORMTM)

Version 1.2

The SCORM Content Aggregation Model

October 1, 2001


This page intentionally left blank.


Advanced Distributed Learning Sharable Content Object Reference Model

Version 1.2

The SCORM Content Aggregation Model


Available at ADLNet (http://www.adlnet.org/)


For questions and comments visit the ADL Help & Info Center at ADLNet.


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.


Table of Contents

SECTION 2 The SCORMTM Content Aggregation Model 2-1

    1. The SCORMTM Content Aggregation Model 2-3

      1. The SCORM Content Model Components 2-3

        1. Assets 2-3

        2. Sharable Content Object (SCO) 2-4

        3. Content Aggregation 2-6

      2. The SCORM Meta-data Components 2-8

        1. Content Aggregation Meta-data 2-8

        2. Sharable Content Object (SCO) Meta-data 2-8

        3. Asset Meta-data 2-8

    2. Meta-Data 2-11

      1. Overview 2-12

        1. The History of the SCORM Meta-data 2-12

      2. The SCORM Meta-data Information Model 2-12

      3. The SCORM Meta-data XML Binding 2-30

        1. <lom> Element 2-32

          1. <general> Element 2-33

          2. <lifecycle> Element 2-40

          3. <metametadata> Element 2-46

          4. <technical> Element 2-54

          5. <educational> Element 2-63

          6. <rights> Element 2-73

          7. <relation> Element 2-75

          8. <annotation> Element 2-82

          9. <classification> Element 2-84

        2. Common Element Types 2-89

          1. LangString Element 2-90

          2. Date Type 2-90

          3. Vocabulary Type 2-91

        3. Electronic Business Card Elements 2-92

          1. Vcard 2-93

        4. XML Extension Mechanism 2-93

      4. The SCORM Meta-data Application Profiles 2-94

        1. Content Aggregation Meta-data 2-95

        2. Sharable Content Object Meta-data 2-95

        3. Asset Meta-data 2-95

        4. The SCORM Meta-data Application Profile Requirements 2-95

      5. SCORM Meta-data Best Practice 2-99

        1. Use of Vocabularies 2-99

        2. Stand-Alone XML Meta-data Documents 2-99

      6. XML Examples 2-100

    3. Content Packaging 2-101

      1. Overview 2-101

      2. Content Structure 2-102

        1. Authoring Content and Content Collections 2-103

        2. Representing Content Structure. 2-103

        3. Content Hierarchy 2-105

        4. Context Specific Meta-data 2-106

        5. Sequencing and Navigation 2-107

          1. Sequencing/Navigation Today 2-108

          2. Sequencing/Navigation Preview 2-110

      3. IMS Package Description 2-111

        1. Content Packaging Overview 2-111

          1. Package 2-112

          2. Manifest 2-112

          3. Meta-data 2-112

          4. Organizations 2-112

          5. Resources 2-112

          6. Physical Files 2-113

          7. Package Interchange File 2-113

      4. The SCORM Content Packaging Information Model 2-113

      5. The SCORM Content Packaging XML Binding 2-124

        1. <manifest> Elements. 2-126

          1. <metadata> Element 2-127

          2. <organizations> Element 2-128

          3. <resources> Element 2-130

        2. <metadata> Element 2-131

          1. <schema> Element 2-132

          2. <schemaversion> Element 2-132

          3. <adlcp:location> 2-133

          4. {Meta-data} 2-133

        3. <organizations> Element 2-134

          1. <organization> 2-134

        4. <resources> Elements 2-142

          1. <resource> Element 2-142

          2. <metadata> Element 2-144

          3. <file> Element 2-144

          4. <dependency> Element 2-145

        5. <manifest> Elements. 2-145

        6. XML Extension Mechanism 2-146

      6. Content Packaging Application Profiles 2-146

        1. Resource Package 2-147

        2. Content Aggregation Package 2-150

        3. Recommended Best Practice 2-151

          1. Packaging Multiple Courses 2-151

          2. Multiple Organizations for a Single Course 2-151

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


SECTION 2

The SCORMTM Content Aggregation Model


This page intentionally left blank.


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


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


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


        1. 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:

See the SCORM Run-Time Environment Book for more details.


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


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


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


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


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


    1. 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:

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


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


      2. 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:

        1. The General category groups the general information that describes the resource as a whole.

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

        3. The Meta-metadata category groups information about the meta-data record itself (rather than the resource that the record describes).

        4. The Technical category groups the technical requirements and characteristics of the resource.

        5. The Educational category groups the educational and pedagogic characteristics of the resource.

        6. The Rights category groups the intellectual property rights and conditions of use for the resource.

        7. The Relation category groups features that define the relationship between this resource and other targeted resources.

        8. The Annotation category provides comments on the educational use of the resource and information on when and by whom the comments were created.

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

            1. :Technical.Requirements.Typ e = ’Operating System’

              • PC-DOS

              • MS-Windows

              • MacOS

              • Unix

              • Multi-OS

              • Other

              • None

        • If

            1. :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)


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


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


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


                      1. <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).

                        1. <general>

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


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

              1. <general>

              2. <catalogentry>

              3

              4

              5

              6

              7

              <catalog>ISBN</catalog>

              <entry>

              <langstring>2-7342</langstring>

              </entry>

              </catalogentry>

              8 </general>

              Example:



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



              2. <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).

                  1. <general>

                  2. <catalogentry>

                  3

                  4

                  5

                  6

                  7

                  <catalog>ISBN</catalog>

                  <entry>

                  <langstring>2-7342</langstring>

                  </entry>

                  </catalogentry>

                  8 </general>

                  Example:



            2. <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:


              1. <general>

              2. <language>en</language>

              3. <language>fr</language>

              4. </general>


            1. <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).

              1. <general>

              2. <description>

              3

              4

              5

              <langstring xml:lang=”en”>Description in English</langstring>

              <langstring xml:lang=”fr”>Description in French</langstring>

              </description>

              6 </general>

              Example:



            2. <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:


              1. <general>

              2. <keyword>

              3. <langstring xml:lang=”en”>metadata</langstring>

              4. <langstring xml:lang=”nl”>metadata</langstring>

              5. <langstring xml:lang=”fr”>metadonnees</langstring>

              6. </keyword>

              7. <keyword>

              8. <langstring xml:lang=”en”>learning object</langstring>

              9. <langstring xml:lang=”nl”>leerobject</langstring>

              10. <langstring xml:lang=”fr”>objet d’apprentissage</langstring>

              11. </keyword>

              12. <keyword>

              13. <langstring xml:lang=”en”>education</langstring>

              14. </keyword>

              15. <general>


            1. <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).

              1. <general>

              2. <coverage>

              3

              4

              <langstring xml:lang=”en”>Circa, 16th century France</langstring>

              </coverage>

              5 <general>

              Example:



            2. <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:


              1. <general>

              2. <structure>

              3. <vocabulary>

              4. <source>

              5. <langstring xml:lang=”x-none”>LOMv1.0</langstring>

              6. </source>

              7. <value>

              8. <langstring xml:lang=”x-none”>Collection</langstring>

              9. </value>

              10. </vocabulary>

              11. </structure>

              12. </general>


            1. <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:

Elements:

Example:


  1. <general>

  2. <aggregationlevel>

  3. <vocabulary>

  4. <source>

  5. <langstring xml:lang=”x-none”>LOMv1.0</langstring>

  6. </source>

  7. <value>

  8. <langstring xml:lang=”x-none”>1</langstring>

  9. </value>

  10. </vocabulary>

  11. </aggregationlevel>

  12. </general>


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


            1. <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:



              1. <lifecycle>

              2. <version>

              3

              4

              <langstring xml:lang=”en”>1.0.alpha</langstring>

              </version>

              5 </lifecycle>

            2. <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:


              1. <lifecycle>

              2. <status>

              3. <vocabulary>

              4. <source>

              5. <langstring xml:lang=”x-none”>LOMv1.0</langstring>

              6. </source>

              7. <value>

              8. <langstring xml:lang=”x-none”>Final</langstring>

              9. </value>

              10. </vocabulary>

              11. </status>

              12. </lifecyle>


            1. <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:


              1. <lifecycle>

              2. <contribute>

              3. <role>

              4. <vocabulary>

              5. <source>

              6. <langstring xml:lang=”x-none”>LOMv1.0</langstring>

              7. </source>

              8. <value>

              9. <langstring xml:lang=”x-none”>Author</langstring>

              10. </value>

              11. </vocabulary>

              12. </role>

              13. <centity>

              14. <vcard>

              15. begin:vcard

              16. fn: Joe Author

              17. end:vcard

              18. </vcard>

              19. </centity>

              20. <date>

              21. <datetime>2000-12-12</datetime>

              22. <description>

              23. <langstring>Date Description</langstring>

              24. </description>

              25. </date>

              26. </contribute>

              27. </lifecycle>


              1. <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:


                1. <lifecycle>

                2. <contribute>

                3. <role>

                4. <vocabulary>

                5. <source>

                6. <langstring xml:lang=”x-none”>LOMv1.0</langstring>

                7. </source>

                8. <value>

                9. <langstring xml:lang=”x-none”>Author</langstring>

                10. </value>

                11. </vocabulary>

                12. </role>

                13. <centity>

                14. <vcard>

                15. begin:vcard

                16. fn: Joe Author

                17. end:vcard

                18. </vcard>

                19. </centity>

                20. <date>

                21. <datetime>2000-12-12</datetime>

                22. <description>

                23. <langstring>Date Description</langstring>

                24. </description>

                25. </date>

                26. </contribute>

                27. </lifecycle>


              1. <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:


                1. <lifecycle>

                2. <contribute>

                3. <role>

                4. <vocabulary>

                5. <source>

                6. <langstring xml:lang=”x-none”>LOMv1.0</langstring>

                7. </source>

                8. <value>

                9. <langstring xml:lang=”x-none”>Author</langstring>

                10. </value>

                11. </vocabulary>

                12. </role>

                13. <centity>

                14. <vcard>

                15. begin:vcard

                16. fn: Joe Author

                17. end:vcard

                18. </vcard>

                19. </centity>

                20. <date>

                21. <datetime>2000-12-12</datetime>

                22. <description>

                23. <langstring>Date Description</langstring>

                24. </description>

                25. </date>

                26. </contribute>

                27. </lifecycle>


              1. <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:


                1. <lifecycle>

                2. <contribute>

                3. <role>

                4. <vocabulary>

                5. <source>

                6. <langstring xml:lang=”x-none”>LOMv1.0</langstring>

                7. </source>

                8. <value>

                9. <langstring xml:lang=”x-none”>Author</langstring>

                10. </value>

                11. </vocabulary>

                12. </role>

                13. <centity>

                14. <vcard>

                15. begin:vcard

                16. fn: Joe Author

                17. end:vcard

                18. </vcard>

                19. </centity>

                20. <date>

                21. <datetime>2000-12-12</datetime>

                22. <description>

                23. <langstring>Date Description</langstring>

                24. </description>

                25. </date>

                26. </contribute>

                27. </lifecycle>


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


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

            2. <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:



              1. <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. <metametadata>

                2. <catalogentry>

                3

                4

                5

                6

                7

                <catalog>ISBN</catalog>

                <entry>

                <langstring>2-7342</langstring>

                </entry>

                </catalogentry>

                8 </metametadata>

                Example:



              2. <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).

                1. <metametadata>

                2. <catalogentry>

                3

                4

                5

                6

                7

                <catalog>ISBN</catalog>

                <entry>

                <langstring>2-7342</langstring>

                </entry>

                </catalogentry>

                8 </metametadata>

                Example:


            3. <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:


              1. <metametadata>

              2. <contribute>

              3. <role>

              4. <vocabulary>

              5. <source><source>

              6. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

              7. </source>

              8. <value>

              9. <langstring xml:lang=“x-none”>Creator</langstring>

              10. </value>

              11. </vocabulary>

              12. </role>

              13. <entity>

              14. <vcard>

              15. begin:vcard

              16. fn: Joe Creator

              17. end:vcard

              14 </vcard>

              1. </entity>

              2. <date>

              3. <datetime>2000-12-12</datetime>

              4. <description>

              5. <langstring>Date Description</langstring>

              6. </description>

              7. </date>

              8. </contribute>

              9. </metametadata>


              1. <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:


                1. <metametadata>

                2. <contribute>

                3. <role>

                4. <vocabulary>

                5. <source>

                6. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

                7. </source>

                8. <value>

                9. <langstring xml:lang=“x-none”>Creator</langstring>

                10. </value>

                11. </vocabulary>

                12. </role>

                13. <entity>

                14. <vcard>

                15. begin:vcard

                16. fn: Joe Creator

                17. end:vcard

                18. </vcard>

                19. </entity>

                20. <date>

                21. <datetime>2000-12-12</datetime>

                22. <description>

                23. <langstring>Date Description</langstring>

                24. </description>

                25. </date>

                26. </contribute>

                27. </metametadata>


              1. <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:


                1. <metametadata>

                2. <contribute>

                3. <role>

                4. <vocabulary>

                5. <source>

                6. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

                7. </source>

                8. <value>

                9. <langstring xml:lang=“x-none”>Creator</langstring>

                10. </value>

                11. </vocabulary>

                12. </role>

                13. <entity>

                14. <vcard>

                15. begin:vcard

                16. fn: Joe Creator

                17. end:vcard

                18. </vcard>

                19. </entity>

                20. <date>

                21. <datetime>2000-12-12</datetime>

                22. <description>

                23. <langstring>Date Description</langstring>

                24. </description>

                25. </date>

                26. </contribute>

                27. </metametadata>


              1. <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:


                1. <metametadata>

                2. <contribute>

                3. <role>

                4. <vocabulary>

                5. <source>

                6. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

                7. </source>

                8. <value>

                9. <langstring xml:lang=“x-none”>Creator</langstring>

                10. </value>

                11. </vocabulary>

                12. </role>

                13. <entity>

                14. <vcard>

                15. begin:vcard

                16. fn: Joe Creator

                17. end:vcard

                18. </vcard>

                19. </entity>

                20. <date>

                21. <datetime>2000-12-12</datetime>

                22. <description>

                23. <langstring>Date Description</langstring>

                24. </description>

                25. </date>

                26. </contribute>

                27. </metametadata>


            1. <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:



            2. <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:


              1. <metametadata>

              2. <language>en</language>

              3. </metametadata>


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


            1. <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:



            2. <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:


              1. <technical>

              2. <size>568</size>

              3. </technical>


            1. <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:



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

                          1. <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:


                              1. <technical>

                              2. <requirement>

                              3. <type>

                              4. <vocabulary>

                              5. <source>

                              6. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

                              7. </source>

                              8. <value>

                              9. <langstring xml:lang=“x-none”>Browser</langstring>

                              10. </value>

                              11. </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>

              1. <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:


                  1. <technical>

                  2. <requirement>

                  3. <type>

                  4. <vocabulary>

                  5. <source>

                  6. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

                  7. </source>

                  8. <value>

                  9. <langstring xml:lang=“x-none”>Browser</langstring>

                  10. </value>

                  11. </vocabulary>

                  12. </type>

                  13. <name>

                  14. <vocabulary>

                  15. <source>

                  16. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

                  17. </source>

                  18. <value>

                  19. <langstring xml:lang=“x-none”>Microsoft Internet Explorer</langstring>

                  20. </value>

                  21. </vocabulary>

                  22. </name>

                  23. <minimumversion>4.0</minimumversion>

                  24. <maximimversion>5.0</maximumversion>

                  25. </requirement>

                  26. </technical>


              1. <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:



                  1. <technical>

                  2. <requirement>

                  3. <type>

                  4. <vocabulary>

                  5. <source>

                  6. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

                  7. </source>

                  8. <value>

                  9. <langstring xml:lang=“x-none”>Browser</langstring>

                  10. </value>

                  11. </vocabulary>

                  12. </type>

                  13. <name>

                  14. <vocabulary>

                  15. <source>

                  16. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

                  17. </source>

                  18. <value>

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

              2. <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:


  1. <technical>

  2. <requirement>

  3. <type>

  4. <vocabulary>

  5. <source>

  6. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

  7. </source>

  8. <value>

  9. <langstring xml:lang=“x-none”>Browser</langstring>

  10. </value>

  11. </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>

            1. <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:


              1. <technical>

              2. <installatinremarks>

              3. <langstring>Installation remakes placed here</langstring>

              4. </installationremarks>

              5. </technical>


            1. <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:


              1. <technical>

              2. <otherplatformrequirements>

              3. <langstring>Other platform requirements placed here</langstring>

              4. </otherplatformrrequirements>

              5. </technical>


            1. <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:


              1. <technical>

              2. <duration>

              3. <date>

              4. <datetime>00:00:15</datetime>

              5. <description>

              6. <langstring>Length of time to play the simulation</langstring>

              7. </description>

              8. </date>

              9. </duration>

              10. </technical>


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


            1. <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:


              1. <educational>

              2. <interactivitytype>

              3. <vocabulary>

              4. <source>

              5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

              6. </source>

              7. <value>

              8. <langstring xml:lang=“x-none”>Active</langstring>

              9. </value>

              10. </vocabulary>

              11. </interactivitytype>

              12. </educational>


            1. <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:


              1. <educational>

              2. <learningresourcetype>

              3. <vocabulary>

              4. <source>

              5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

              6. </source>

              7. <value>

              8. <langstring xml:lang=“x-none”>Simulation</langstring>

              9. </value>

              10. </vocabulary>

              11. </learningresourcetype>

              12. </educational>


            1. <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:


              1. <educational>

              2. <interactivitylevel>

              3. <vocabulary>

              4. <source>

              5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

              6. </source>

              7. <value>

              8. <langstring xml:lang=“x-none”>very high</langstring>

              9. </value>

              10. </vocabulary>

              11. </interactivitylevel>

              12. </educational>


            1. <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:


              1. <educational>

              2. <semanticdensity>

              3. <vocabulary>

              4. <source>

              5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

              6. </source>

              7. <value>

              8. <langstring xml:lang=“x-none”>very high</langstring>

              9. </value>

              10. </vocabulary>

              11. </semanticdensity>

              12. </educational>


            1. <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:


              1. <educational>

              2. <intendedenduserrole>

              3. <vocabulary>

              4. <source>

              5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

              6. </source>

              7. <value>

              8. <langstring xml:lang=“x-none”>Learner</langstring>

              9. </value>

              1. </vocabulary>

              2. </intendedenduserrole>

              3. </educational>


            1. <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:


              1. <educational>

              2. <context>

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

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

              1. </typicalagerange>

              2. </educational>

              Example:



            2. <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:


              1. <educational>

              2. <difficulty>

              3. <vocabulary>

              4. <source>

              5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

              6. </source>

              7. <value>

              8. <langstring xml:lang=“x-none”>medium</langstring>

              9. </value>

              10. </vocabulary>

              11. </difficulty>

              12. </educational>


            1. <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:


              1. <educational>

              2. <typicallearningtime>

              3. <datetime>01:30:00</datetime>

              4. </typicallearningtime>

              5. </educational>

            1. <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:


              1. <educational>

              2. <description>

              3. <langstring>Used for training on in-flight refueling</langstring>

              4. </description>

              5. </educational>


            1. <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:


              1. <educational>

              2. <language>en</language>

              3. </educational>

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


            1. <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:


              1. <rights>

              2. <cost>

              3. <vocabulary>

              4. <source>

              5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

              6. </source>

              7. <value>

              8. <langstring xml:lang=“x-none”>no</langstring>

              9. </value>

              10. </vocabulary>

              11. </cost>

              12. </rights>


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

            2. <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:


              1. <rights>

              2. <description>

              3. <langstring xml:lang=”en”>LOMv1.0</langstring>

              4. </description>

              5. </rights>


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


                      1. <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:


                            1. <relation>

                            2. <kind>

                            3. <vocabulary>

                            4. <source>

                            5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

                            6. </source>

                            7. <value>

                            8. <langstring xml:lang=“x-none”>Requires</langstring>

                            9. </value>

                            10. </vocabulary>

                            11. </kind>

                            12. <resource>

                            13. <description>

                            14. <langstring>Description of resource</langstring>

                            15. </description>

                            16. </resource>

                            17. <catalogentry>

                            18. <catalog>ISBN</catalog>

                            19. <entry>

                            20. <langstring>2-7342</langstring>

                            21. </entry>

                            22. </catalog>

                            23. </catalogentry>

                            24. </relation>


            1. <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:


                1. <relation>

                2. <kind>

                3. <vocabulary>

                4. <source>

                5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

                6. </source>

                7. <value>

                8. <langstring xml:lang=“x-none”>Requires</langstring>

                9. </value>

                10. </vocabulary>

                11. </kind>

                12. <resource>

                13. <description>

                14. <langstring>Description of resource</langstring>

                15. </description>

                16. </resource>

                17. <catalogentry>

                18. <catalog>ISBN</catalog>

                19. <entry>

                20. <langstring>2-7342</langstring>

                21. </entry>

                22. </catalog>

                23. </catalogentry>

                24. </relation>


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

              2. <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:


  1. <relation>

  2. <kind>

  3. <vocabulary>

  4. <source>

  5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

  6. </source>

  7. <value>

  8. <langstring xml:lang=“x-none”>Requires</langstring>

  9. </value>

  10. </vocabulary>

  11. </kind>

  12. <resource>

  13. <description>

  14. <langstring>Description of resource</langstring>

  15. </description>

  16. </resource>

  17. <catalogentry>

  18. <catalog>ISBN</catalog>

  19. <entry>

  20. <langstring>2-7342</langstring>

  21. </entry>

  22. </catalog>

  23. </catalogentry>

  24. </relation>


            1. <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:

Example:


  1. <relation>

  2. <kind>

  3. <vocabulary>

  4. <source>

  5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

  6. </source>

  7. <value>

  8. <langstring xml:lang=“x-none”>Requires</langstring>

  9. </value>

  10. </vocabulary>

  11. </kind>

  12. <resource>

  13. <description>

  14. <langstring>Description of resource</langstring>

  15. </description>

  16. </resource>

  17. <catalogentry>

  18. <catalog>ISBN</catalog>

  19. <entry>

  20. <langstring>2-7342</langstring>

  21. </entry>

  22. </catalog>

  23. </catalogentry>

  24. </relation>


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

              2. <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:


  1. <relation>

  2. <kind>

  3. <vocabulary>

  4. <source>

  5. <langstring xml:lang=“x-none”>LOMv1.0</langstring>

  6. </source>

  7. <value>

  8. <langstring xml:lang=“x-none”>Requires</langstring>

  9. </value>

  10. </vocabulary>

  11. </kind>

  12. <resource>

  13. <description>

  14. <langstring>Description of resource</langstring>

  15. </description>

  16. </resource>




17

18

<catalogentry>

<catalog>ISBN</catalog>

19

20

21

22

23

<entry>

<langstring>2-7342</langstring>

</entry>

</catalog>

</catalogentry>

24 </relation>

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


            1. <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:


              1. <annotation>

              2. <person>

              3. <vcard>

              4. begin:vcard

              5. org: IMS

              6. end:vcard

              7. </vcard>

              8. </person>

              9. </annotation>


            1. <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:


              1. <annotation>

              2. <date>

              3. <datetime>2001-04-17</datetime>

              4. </date>

              5. </annotation>


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

              1. </description>

              2. </annotation>

              Example:



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


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

              1. <classification>

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



            2. <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:


              1. <classification>

              2. <taxonpath>

              3. <source>

              4. <langstring>DDC</langstring>

              5. <source>

              6. </taxonpath>

              7. </classification>


              1. <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:


                1. <classification>

                2. <taxonpath>

                3. <source>

                1. <source>

                2. </taxonpath>

                3. </classification>

                4 <langstring>DDC</langstring>



              2. <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:


                1. <classification>

                2. <taxonpath>

                3. <taxon>

                4 <id>912</id>

                1. <taxon>

                2. </taxonpath>

                3. </classification>


                1. <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:


                    1. <classification>

                    2. <taxonpath>

                    3. <taxon>

                    4 <id>912</id>

                    1. <taxon>

                    2. </taxonpath>

                    3. </classification>


                1. <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:


                    1. <classification>

                    2. <taxonpath>

                    3. <taxon>

                    4. <entry>simulation</entry>

                    5. <taxon>

                    6. </taxonpath>

                    7. </classification>


                1. <taxon> Element

                  Description: See Section 2.2.3.1.9.2.2 for the details on the <metadata> element.

            1. <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:


              1. <classification>

              2. <description>

              3. <langstring xml:lang=”en”>

              4. Electronic, computer generated simulation

              1. </langstring>

              2. </description>

              3. </classification>


            1. <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:


              1. <classification>

              2. <keyword>

              3. <langstring xml:lang=”en”>simulation</langstring>

              4. </keyword>

              5. </classification>


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

          1. 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:


            1. <classification>

            2. <keyword>

            3. <langstring xml:lang=”en”>simulation</langstring>

            4. </keyword>

            5. </classification>


          1. Date Type

            Description: This data element defines the structure of a Date Type.

            Multiplicity: Varies – see parent element.

            Attributes:

            • None

              Elements:

            • <datetime>

            • <description>

            Example:


            1. <datetime>00:00:20</datetime>

            2. <description>

            3. <langstring>Description of Date</langstring>

            4. </description>


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

            2. <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).

          1. 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:


            1. <classification>

            2. <purpose>

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

            1. <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).

            2. <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).


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

          1. 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:


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


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

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


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


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


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


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


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


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


      1. XML Examples

See the ADLNet (http://www.adlnet.org/) for SCORM Meta-data XML document examples.


    1. Content Packaging


      1. 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:

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

            2. IMS Package Description provides an overview of the IMS Content Packaging Structure

            3. 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).

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

            5. 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).


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


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


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


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


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


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

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


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

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


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