IMS Logo

IMS Meta-data Best Practice Guide for IEEE 1484.12.1-2002 Standard for Learning Object Metadata

Version 1.3 Public Draft

Copyright © 2004 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Meta-data Best Practice Guide for IEEE 1484.12.1-2002 Standard for Learning Object Metadata
Revision: 20 May 2004 

Date Issued:
20 May 2004
Latest version:
http://www.imsglobal.org/metadata/mdv1p3pd/imsmd_bestv1p3pd.html
Register comments or implementations:
http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=3
Description:
Resolves the drift between the IMS Meta-data and the IEEE LOM standard, which began as a combination of IMS Meta-data and ARIADNE collaboration.

IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © IMS Global Learning Consortium 2006. All Rights Reserved.

If you wish to distribute this document or use this document to implement a product or service, you must complete a valid license registration with IMS and receive an email from IMS granting the license. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.

This document may be copied and furnished to others by Licensee organizations registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS work group.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/metadata/mdv1p3pd/mdv1p3pdspeclicense.html.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.




Table of Contents


1. Introduction
     1.1 Background
     1.2 Scope
     1.3 Nomenclature

2. Meta-data
     2.1 Overview
     2.2 IEEE Meta-data Elements and Structure
     2.3 Datatypes and Value Spaces of LOM Elements
           2.3.1 Repertoire of ISO/IEC 10646-1:2000 Value Space
           2.3.2 LanguageID Value Space
           2.3.3 MIME Types Value Space
           2.3.4 vCard Value Space
           2.3.5 CharacterString Datatype
           2.3.6 LangString Datatype
           2.3.7 Vocabulary Datatype
           2.3.8 DateTime Datatype
           2.3.9 Duration Datatype
     2.4 Data Model Changes from IMS Learning Resource Meta-data v1.2.2
     2.5 Conformance
           2.5.1 Meta-data Instance Conformance
           2.5.2 Application Profile Conformance
           2.5.3 Smallest Permitted Maximum
     2.6 Extensions

3. Taxonomies, Vocabularies, and the LOM

4. Implementation and Application Profiles
     4.1 Planning
     4.2 Application Profiles
           4.2.1 General
           4.2.2 Current Practice
           4.2.3 Reference Implementations and Registries
           4.2.4 Recommendations for Application Profiles
           4.2.5 Vocabularies and Classification Schemata
           4.2.6 Translations
           4.2.7 Mapping Semantics
     4.3 Implementation
           4.3.1 Strict Implementation of the LOM Conceptual Data Schema
           4.3.2 Extending the LOM Conceptual Data Schema
     4.4 Exposing Meta-data
           4.4.1 IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata
           4.4.2 Application Profile Bindings and Conformance
           4.4.3 Migration from IMS LRM XML Binding v1.2.1 to the IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata
           4.4.4 Creating XML LOM Instances

Appendix A - Additional Resources

Appendix B - Mapping to Simple Dublin Core

Appendix C - IMS LRM v1.2.1 to IEEE LOM 1.0 Transform

About This Document
     List of Contributors

Revision History

Index

1. Introduction

The purpose of this document is to provide users and implementers of the IMS Learning Resource Meta-data1 v1.3 Specification with a narrative description of the data model along with guidelines on its use, including the creation of application profiles. This Best Practice and Implementation Guide also provides a brief description of IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata plus guidelines on binding meta-data instances. Designers and developers of online learning materials have an enormous variety of software tools at their disposal for creating learning resources. These tools range from simple presentation software packages to more complex authoring environments. They can be very useful in allowing developers the opportunity to create learning resources that might otherwise require extensive programming skills. Unfortunately, the wide variety of software tools available from a wide variety of vendors produce instructional materials that do not share a common mechanism for finding and using these resources.

Descriptive labels can be used to index learning resources making them easier to find and use. Such labels are "data about data" and when they are formally declared, or structured according to some specification, they are referred to as "meta-data". An example of meta-data is the label on a can of soup, which describes the can's ingredients, weight, cost, and so forth, usually in a small table with labels that are recognizable. Another example is a card in a library's card catalog, which describes a book, its author, subject, location within the library, and so forth.

A meta-data specification aims to make the process of finding and using a learning resource more efficient by providing a structure of defined elements that describe, or catalog, the learning resource and requirements about how the elements are to be used and represented.

1.1 Background

In 1997, the IMS Project, initiated by the non-profit EDUCOM consortium (now EDUCAUSE) of US institutions of higher education and their vendor partners, established an effort to develop open market-based standards for online learning, including specifications for learning content meta-data.

Also in 1997, groups within the US National Institute for Standards and Technology (NIST) and the IEEE P.1484 study group (now the IEEE Learning Technology Standards Committee - LTSC) began similar efforts. The NIST effort merged with the IMS effort and IMS began collaborating with the ARIADNE Project, a European project with an active meta-data remit.

In 1998, IMS and ARIADNE submitted a joint proposal and specification to the IEEE LTSC, which formed the basis of the IEEE LTSC Working Group 12 work on a draft standard for Learning Object Metadata (LOM). The standard developed by this working group is a multi-part standard: part one being a conceptual data schema (which corresponds to the IMS Learning Resource Meta-data Information Model), parts two, three, and four being bindings of this schema in ISO/IEC11404, XML and RDF respectively.

As a result of significant worldwide interest, the IMS Project was incorporated as the IMS Global Learning Consortium in 1999, publicizing the IEEE work through its stakeholder community in the US, UK, Europe, Australia, and Singapore. This evolving stakeholder community has contributed feedback into the ongoing specification development process. In August 1999, IMS released its Learning Resource Meta-data Specification v1.0 to the public, with minor revisions being released periodically up to v1.2.2 in November 2001. Each of these specification releases was based on updates of the IEEE LOM conceptual data schema with an accompanying XML Binding and Best Practice and Implementation Guide produced by IMS.

On June 12th 2002, the conceptual data schema of the LOM was approved by the IEEE Standards Association as IEEE 1484.12.1 - 2002 Standard for Learning Object Metadata (IEEE LOM), and at the time writing the associated XML binding standard was in the process of being balloted for approval as IEEE 1484.12.3 Standard for Extensible Markup Language (XML) Schema Definition Language Binding for LOM.

IMS Meta-data v1.2.2 specification was based on working draft 6.1 of the IEEE LOM standard. The IEEE standard finally published in June 2002 was based on working draft 6.4 of the LOM. With the release of this specification, IMS Meta-data v1.3, the Information Model of the IMS specification has been realigned with the published IEEE standard. The XML Binding of the IMS Meta-data specification has also been realigned, given changes in the IEEE information model and to allow stricter checking of meta-data instances using an XML schema. The intention is that the IMS Meta-data Specification v1.3 will align to the IEEE 1484.12.1 and 1484.12.3 standards.

At the same time as changing its meta-data Information Model and XML Binding, IMS is releasing this Best Practice and Implementation Guide and tools (in the form of an XSL transform) to assist developers and implementers who are using previous versions of the specification.

1.2 Scope

The IEEE LOM standard defines a set of meta-data elements that can be used to describe learning resources. This includes the element names, definitions, datatypes, and field lengths. The standard is known as a multi-part standard and defines both a conceptual model for the meta-data and an XML binding. The standard includes conformance statements for how meta-data documents must be organized and how applications must behave in order to be considered IEEE-conformant.

The IMS Best Practice and Implementation Guide for the IEEE Standard for LOM therefore references:

This Best Practice and Implementation Guide for the 1484.12.1 - 2002 IEEE Standard for LOM provides general guidance about how an application may use LOM elements. The IEEE P1484.12.3 draft standard is accompanied by XML schemata to assist developers with their meta-data implementations. None of these IEEE or IMS documents address details of meta-data implementation such as approaches to architectures, programming languages and data storage.

Use of the XSL transform is not covered in this document, separate guidance on its use is available from the IMS Public Website at http://www.imsglobal.org/metadata/mdv1p1p3pd/xslt.

1.3 Nomenclature

ARIADNE
ARIADNE European Foundation
DC
Dublin Core
DCMI
Dublin Core Metadata Initiative
IEEE
Institute of Electronic & Electrical Engineering
IMC
Internet Mail Consortium
ISO
International Standards Organization
LOM
Learning Object Metadata (usually used in "IEEE LOM")
LTSC
Learning Technology Standards Committee
NIST
US National Institute for Standards and Technology
RDF
Resource Description Framework
RFC
Request for Comment
UKEC
UK Educational Contexts
W3C
World Wide Web Consortium
XML
Extensible Mark-up Language

2. Meta-data

2.1 Overview

The IEEE conceptual data schema for meta-data definitions is hierarchical. At the base of the hierarchy is the "root" element. The root element contains many sub-elements. If a sub-element itself contains additional sub-elements it is called a "branch". Sub-elements that do not contain any sub-elements are called "leaves". This entire hierarchical model is called the "tree structure" of a document. The relationship between the root, branches, and leaves is depicted in Figure 2.1 using sample elements from the IEEE LOM standard.

Root to leaf

Figure 2.1 - Root to leaf "tree view" of meta-data.

Each element in the meta-data hierarchy has a specific definition, datatype, and value space. Complete details about each meta-data element can be found in the conceptual data schema for IEEE 1484.12.1 - 2002 Standard for LOM. Further information about the activities of the IEEE LOM Working Group is available at http://ltsc.ieee.org/wg12/index.html.

2.2 IEEE Meta-data Elements and Structure

The IEEE LOM standard conceptual data schema lists all the meta-data elements in tabular format. To complement this table, Figure 2.2 below presents a graphical illustration of the elements in the data schema, which shows how the elements are divided into nine top level categories: General, Life Cycle, Meta-Metadata, Technical, Educational, Rights, Relation, Annotation, and Classification. Each of these branches comprises several elements, some of which are leaves, others are sub-branches which lead to leaves. Not shown in Figure 2.2 are the leaf elements associated with the element types such as "LangString", "Vocabulary", "DateTime" and "Duration", which are described below in section 2.3. The reader is referred to the IEEE LOM conceptual data schema for a full account of the types and value spaces of each element.

The elements and structure of the LOM conceptual data schema (some elements are of data types which give rise to leaf elements below the level of those shown in this diagram)

Figure 2.2 - The elements and structure of the LOM conceptual data schema (some elements are of data types which give rise to leaf elements below the level of those shown in this diagram).

2.3 Datatypes and Value Spaces of LOM Elements

Each leaf element in the LOM conceptual data schema has a datatype and a value space that defines the encoding of the data for that element. These datatypes and value spaces sometimes restrict how an element may be used, for example by specifying a restricted vocabulary, and may also provide the facility to encode extra information, such as multilingual entries. Value spaces that are LOM vocabularies are not listed here; they are described in the IEEE LOM conceptual data schema and are discussed in section 3 of this guide.

2.3.1 Repertoire of ISO/IEC 10646-1:2000 Value Space

ISO/IEC 10646-1:2000 is also known as Unicode 3.0.1. This value space allows the use of an extensive list of international letters, glyphs, and other characters.

2.3.2 LanguageID Value Space

Values for LanguageID take the form Langcode(-Subcode) where the value space for Langcode is defined by ISO 639:1988, which specifies two and three letter codes for languages and the value space for Subcode is defined by ISO 3166-1:1997, which specifies two letter codes for countries. This allows for regional variations to be recorded where they are significant, for example UK, Australian, and US English can be distinguished as en-UK, en-AU, and en-US respectively. The LOM conceptual data schema gives examples of further regionalization such as en-US-philadelphia. The schema states that this approach is in accordance with (IETF) RFC1766:1995, which specifies that where a two letter language code is available it should be used in preference to the three letter code. This RFC also allows the use of the codes x- and i- in place of ISO 639:1988 language codes for extensions. The value i- is reserved for extensions that have been registered with IANA, the value x- allows unregistered private extensions. A point of divergence between RFC 1766:1995 and the LOM LanguageID value space is that "none" is an acceptable value in LOM usage.

2.3.3 MIME Types Value Space

MIME types allow the encoding of the digital format of a resource. A full listing of registered types can be found at http://www.iana.org/assignments/media-types/ and procedures for creating and registering new types are described in RFC 2048:1998.

2.3.4 vCard Value Space

IMC vCard is a structured text string that encodes information similar to that found on a business card. The technical details are given in RFC2425 and RFC2426 and a more general overview is available at http://www.imc.org/pdi/.

2.3.5 CharacterString Datatype

This is the most basic LOM datatype, being a string of characters conforming to the value space of the relevant element.

2.3.6 LangString Datatype

The LangString datatype allows multiple semantically equivalent entries of the information about the characteristic described by the LOM element. Each entry is in two parts: String and Language. String contains the information describing the characteristic, and Language specifies the language in which this is recorded. This allows the same information to be given in several languages in a single LOM element. For example, even though a LOM record can have only one instance of 1.2 General.Title, this instance is a LangString allowing the title to be given in other relevant languages. Where the Strings are semantically different, multiple instances of the LOM element should be used (for example, when providing several alternative keywords in English for element 1.5 General.Keyword).

2.3.7 Vocabulary Datatype

Many LOM elements take their entry from a value space which is a limited choice of words or phrases, i.e. a restricted vocabulary. For most of these elements, the LOM conceptual data schema provides a default vocabulary. For all such elements the entry is encoded as a Vocabulary datatype, which comprises two parts: the Source of the restricted vocabulary and the Value. Where the default vocabulary is used, the Source would be "LOMv1.0" but other vocabularies could be used, in which case they should be identified by a similar abbreviation or by a URI.

2.3.8 DateTime Datatype

The DateTime datatype allows a point in time to be encoded numerically or described textually. There are two parts to each element of this datatype: the DateTime and a Description. The DateTime allows the date and time of day to be specified according to ISO 8601:2000, for example 2003-07 (July 2003). The Description part is useful for dates which cannot be specified in this way, for example "late June 1966" or "about 2 million years BC". The description is given as a LangString (see above).

2.3.9 Duration Datatype

The duration datatype allows periods of time to be encoded numerically or described textually. There are two parts to each element of this type: the Duration and a Description. The Duration provides the length of the period according to ISO8601:2000, for example P3M for three months, P3m58s for three minutes 58 seconds. A description of the Duration can be provided for periods that are not well described by this scheme, for example "about half an hour". The description is given as a LangString (see above).

2.4 Data Model Changes from IMS Learning Resource Meta-data v1.2.2

This section summarizes the differences between the IMS Learning Resource Meta-data Information Model v1.2.2 and the IEEE LOM conceptual data schema, which forms the Information Model for IMS Meta-data v1.3.

The changes from the IEEE LOM draft v6.1 to the final standard can be found in IEEE 1484.12.1 Standard for LOM Summary of Changes document which can be found at http://ltsc.ieee.org/wg12/files/LOMChangesSummary_2.pdf. Since IMS Learning Resource Meta-data v1.2.2 was based on the IEEE LOM draft v6.1this Summary of Changes serves as an account of the differences between Learning Resource Meta-data v1.2.2 and v1.3, with two classes of exception:

  1. IMS Learning Resource Meta-data v1.2.2 was based on draft v6.1 of the IEEE LOM, however some small changes were made in this process (these were the renaming of LOM element names "keywords" and "requirements" to "keyword" and "requirement" in IMS Learning Resource Meta-data v1.2.2). These changes were incorporated into the final version of the IEEE LOM. Thus, while these are listed in the IEEE Summary of Changes, they are not points of difference between IMS Learning Resource Meta-data v1.2.2 and v.1.3.
  2. There are differences between IMS Learning Resource Meta-data Information Model v1.2.2 and the IEEE LOM standard that are not accounted for in the IEEE Summary of Changes. These are:
  3. The vocabulary type in IMS Meta-data comprised source and value elements that were LangStrings. In the LOM version 1.0 they became CharacterStrings.
  4. Some other LangStrings became CharacterStrings, namely the entry part of an IMS CatalogEntry / LOM identifier (elements IMS 1.3.1 / LOM 1.1.2 and IMS 3.2.2 / LOM 3.1.2, IMS 7.2.3.1 / LOM 7.2.1.2).
  5. The Educational category changed from being a single instance to having a smallest permitted maximum of 100.

An XSLT has been written and is publicly available at: http://www.imsglobal.org/metadata/mdv1p1p3pd/xslt. The XSLT provides information on transforming from IMS LRM v1.2.1 to IEEE LOM 1.0. For more information, see Appendix C.

2.5 Conformance

The conceptual data schema of IEEE 1484.12.1 - 2002 Standard for LOM defines levels of conformance for meta-data instances. A definition of instance conformance is provided below which is the same as that provided for IMS LRM v1.2.2.

2.5.1 Meta-data Instance Conformance

The IEEE LOM defines instance conformance as follows:

  • A strictly conforming LOM metadata instance shall consist solely of LOM data elements.
  • A conforming LOM metadata instance may contain extended data elements.
  • A LOM instance that contains no value for any of the LOM data elements is a conforming instance.

In order to maximize semantic interoperability, extended data elements should not replace data elements in the LOM structure. This means that an organization should not introduce new data elements of its own that replace LOM data elements. As an example, an organization should not introduce a new data element "name" that would replace 1.2:General.Title.

Note: "In order to maximize semantic interoperability, users of this Standard are encouraged to carefully map their metadata information to the data elements of this Standard. For example, the user should not map an element to describe the fonts used in the document to the data element 1.2:General.Title." IEEE 1484.12.1 - 2002 Standard for Learning Object Metadata, p6-7

.

2.5.2 Application Profile Conformance

For further guidelines regarding application profile conformance see section 4.4.2 Application Profile Bindings and Conformance and the IMS International Conformance Program's draft Application Profile Guidelines document.

2.5.3 Smallest Permitted Maximum

The smallest permitted maximum is the smallest number of occurrences of an element that an application must be able to handle or manage. This means that for meta-data instances the smallest permitted maximum is the maximum number of occurrences of an element that can be guaranteed to pass from one system to another For example, the smallest permitted maximum for the Annotation category is 30 items, however a meta-data instance may contain 40 occurrences of the Annotation category. A conforming LOM application receiving this instance may import only 30 of these occurrences. It is therefore important that the originator of the meta-data instance is aware that ten occurrences of the annotation may not be displayed by all systems. Since the Annotation category is unordered there is no way of knowing which occurrences will not be represented. Other LOM elements are ordered (for example 5.2 Education.Learning Resource Type) with the most dominant values being recorded first, in such instances the less dominant values that exceed the smallest permitted maximum may not be represented.

2.6 Extensions

The IEEE LOM conceptual data schema is designed in such a way as to facilitate extensions to the schema. Such extensions may take the form of new terms for existing vocabularies, new vocabularies for existing elements or new elements. Extensions to the LOM must retain the data types and must not delete values from the value spaces of existing LOM v1.0 base schema data elements. New values may be added to an existing LOM v1.0 value space but must be identified as coming from a source other than LOM v1.0 when they are used in an instance. As vocabularies can act as qualifiers for elements, vocabulary extensions should be chosen to provide semantic consistency with the LOM conceptual data schema element with which they are used. Guidelines on how to extend the LOM are provided in sections 4.3.2 Extending the LOM Conceptual Data Schema and 4.4.2 Application Profile Bindings and Conformance.

3. Taxonomies, Vocabularies, and the LOM

Taxonomies and vocabularies are structured collections of terms that can serve as values for meta-data elements. They are part of the IEEE LOM conceptual data schema and are subject to best practice policies. This section outlines current IMS best practice for taxonomies and vocabularies.

Just as meta-data elements must accurately describe resources, the taxonomies and vocabularies that are their corresponding values also need to be precise. In addition, the taxonomies must be familiar both to developers and consumers of learning resources. Useful and usable meta-data elements and taxonomies help to facilitate interoperability and the sharing of learning resources. Hence, best practice considerations are as relevant to taxonomies and vocabularies as to other aspects of the LOM.

It is recognized that no single controlled vocabulary will be acceptable to all communities, however it is best practice to use widely accepted vocabularies in preference to home grown schemes in order to facilitate interoperability.

The following factors should be considered when selecting an appropriate vocabulary:

For further guidance on using taxonomies and vocabularies with the LOM see the IMS LRM Best Practice and Implementation Guide v1.2.1 at http://www.imsglobal.org/metadata/ and the CEN/ISSS Learning Technologies Workshop draft CEN Workshop Agreement Controlled Vocabularies for Learning Object Metadata at
http://www.cenorm.be/cenorm/businessdomains/businessdomains/informationsocietystandardizationsystem/elearning/learning+technologies+workshop/learning+technologies+workshop.asp.

4. Implementation and Application Profiles

4.1 Planning

One of the first steps in planning a meta-data implementation is to identify all the meta-data elements the implementation will need to support. This can be done in several ways. One approach is to imagine how to label the learning resources that the implementation will describe. What kind of information should the resources carry with them? It may be useful to try this exercise without first looking through the IEEE LOM standard conceptual data schema. An alternative approach is to go through the LOM conceptual data schema checking off each element that will be required to serve the needs of the implementation. It is important to keep end users in mind when listing these meta-data elements. Implementers should evaluate whether an element is critical to the implementation or whether it is just "nice to have". Meta-data elements are similar to features of a modern software application. Just as software engineers must be wary of "feature creep", so should meta-data implementers be wary of "meta-data creep". In a worst case scenario, the requirement may be for a convenient means of easily describing online learning materials but the application may demand considerable resources in terms of time and cataloguing expertise.

4.2 Application Profiles

4.2.1 General

For education and training stakeholders the standardization during 2002-2003 of the two international meta-data standards (IEEE LOM and Dublin Core) represents a significant milestone. Officially known as IEEE 1484.12.1-2002 Standard for Learning Object Metadata (LOM), and ISO 15836 (the Dublin Core Metadata Element Set) these data models provide important reference points for implementers building and managing systems that support e-learning.

In practice, organizations and communities will find it necessary to implement the LOM in ways that meet their specific requirements. To do this, they create "application profiles", a term that has been adopted by the broader meta-data community to describe meta-data element sets that are either abbreviated versions of complete standards or are a heterogeneous mix of elements drawn from different meta-data schemata. Typically, application profiles are developed to meet the needs of a specific application, within a specific community. For example, to exchange meta-data records among higher education institutions within a country; to ensure that content coming to a government agency from a variety of external sources can be incorporated into the catalog supported by the agencies learning management system; or, to support the distributed development of learning resource material by learning teams within a corporation. However, there is currently diverse practice relating to the definition and implementation of application profiles. While the development of application profiles provides the opportunity for implementer communities to meet their local needs, balancing interoperability with local requirements can be a significant challenge.

To facilitate interoperability, the LOM standard specifies ways in which application profiles can be created. As a further aid, this Best Practice and Implementation Guide includes additional guidelines that represent current thinking. Additional references are provided below.

4.2.2 Current Practice

The IMS Meta-data Special Interest Group recognizes that the IMS community implements a variety of meta-data specifications and standards. Two approaches to the development of application profiles are currently emerging. One involves combining elements from different meta-data schemata and the other constrains and extends a single schema.

As an example of the first approach, the DCMI community defines its position as follows:

An Application Profile (AP) is a declaration of which metadata terms an organization, information resource, application, or user community uses in its metadata. Moreover

  • By definition, an AP cannot "declare" new metadata terms and definitions; it only "reuses" terms from existing element sets.
  • The ideal element set will use URIs to uniquely identify its terms within XML namespaces As of 2002, however, this cannot be required.
  • By definition, any new term coined for use in an AP must first be declared in a form citable in the AP.

An AP may also provide additional documentation on how the terms used are constrained, encoded, or interpreted for particular purposes. (Baker, 2003)

Typically, however, a number of communities have interpreted application profiles as a means to also incorporate their own specific local requirements and terminology. For example, the SCHEMAS Registry provides examples of such usage and defines an application profile in the following simple terms: "an application profile selects elements from one or more namespace schemas." (SCHEMAS)

As an example of the second approach, Clifford Lynch, of the Coalition for Networked Information, defines profiles as "customizations of the standard to particular communities of implementers with common applications requirements" (Lynch, 1997). This second approach focuses on a single meta-data standard and its elements. The LOM for example, is typically implemented by creating application profiles that restrict the elements used, designate certain elements as mandatory or optional, specify vocabulary usage and interpretation, and add organization or community specific classification schemes. Implementers may also constrain the data model by dictating the way in which elements are used and repeated. Examples include the UK LOM Core, SingCore, and the SCORM 1.3 Profile of LOM.

A pragmatic approach has been developed through the collaborative efforts of IEEE LTSC and DCMI, whose position on application profiles was articulated as a result of the Ottawa Communiqué (2001). A jointly authored paper, Metadata Principles and Practicalities (Duval et al, 2002), was released following the Ottawa Communiqué. This paper defines application profiles in the following terms:

No single metadata element set will accommodate the functional requirements of all applications, and as the Web dissolves access boundaries, it becomes increasingly important to be able to also cross discovery boundaries. Application profiles will facilitate this by allowing designers to 'mix and match' schemas as appropriate.

An application profile is an assemblage of metadata elements selected from one or more metadata schemas and combined in a compound schema. Application profiles provide the means to express principles of modularity and extensibility. The purpose of an application profile is to adapt or combine existing schemas into a package that is tailored to the functional requirements of a particular application, while retaining interoperability with the original base schemas. Part of such an adaptation may include the elaboration of local metadata elements that have importance in a given community or organization, but which are not expected to be important in a wider context.

One of the benefits of this approach is that communities of practice are able to focus on standardizing community-specific metadata in ways that can be preserved in the larger metadata architectures of the Web. It will be possible to snap together such community-specific modules to form more complex metadata structures that will conform to the standards of the community while preserving cross-community interoperability. (Duval et al 2002)

4.2.3 Reference Implementations and Registries

With the proliferation of meta-data application profiles also comes the need for registries. A number of important registries for meta-data schemata and associated vocabularies have already been implemented. These include:

Like namespaces, registries provide an authoritative role in facilitating data sharing and interchange. Registries also provide a forum for schema validation and comparative analysis, informing stakeholders of rules and protocols associated with data sharing. Registries can reference a diverse array of information including entire standards or specifications, their components, bindings, data elements, vocabularies, reference implementations, guidelines and best practices. From an interoperability perspective, registries are useful because they provide a common method for representing the characteristics of the items (schemata, application profiles, vocabularies, etc.) that are registered.

IMS recommends that implementers adopting the application profile approach to meta-data schema development should consider the role that registries play and register their profiles accordingly. Example application profiles are listed in Appendix A.

4.2.4 Recommendations for Application Profiles

To successfully create an application profile it is necessary to:

For further information concerning application profiles, please refer to the IMS International Conformance Program's draft Application Profile Guidelines document found on the IMS Website at http://www.imsglobal.org.

4.2.5 Vocabularies and Classification Schemata

ISO defines a vocabulary as "a dictionary of terms related to a particular subject field" (ISO 5127/2-1983).

The LOM conceptual data schema uses different kinds of vocabularies that serve different needs. The following types of vocabularies may be used to qualify LOM elements:

For further discussion regarding Taxonomies, Vocabularies, and the LOM, refer to section 3 above.

Only simple vocabularies and value lists are typically used in relation to the LOM vocabulary datatype. The vocabulary datatype is a combination of two parts: the first identifies the source of the vocabulary or list of values, the second identifies the values of the vocabulary or list. Vocabulary values are typically terms, short strings, or integers. The source of the vocabulary is generally a namespace, URI, or URL. Ideally, this source namespace, URI or URL should provide a list of acceptable values and their definitions. Elements that are subject to the vocabulary datatype should cite openly referenced and maintained value sets.

Particular communities may find LOM based vocabularies insufficient and may achieve increased specificity in describing their learning resources by using terms that have high semantic value within that community. However implementers should be aware that this approach compromises interoperability when records created using different application profiles are exchanged. Consequently, it is advisable that local or customized vocabularies should be used in conjunction with the vocabularies recommended by the LOM conceptual data schema. (Note: this technique is based on the LOM recommendations for 5.6:Educational.Context: "Suggested good practice is to use one of the values of the value space and to use an additional instance of this data element for further refinement.")

  1. Use one of the vocabulary values recommended by the LOM. If no clearly suitable value is available, use the LOM value that, by virtue of its generality, connotative meanings or other attributes, is closest in meaning and most accurate.
  2. Repeat the metadata element and provide both the source location and appropriate value(s) for the locally developed or custom controlled vocabulary. Where this technique is not possible (e.g., only one instance of the element is permitted), implementers are encourage to use the LOM vocabulary; however, the use of alternative vocabularies may sometimes be unavoidable.

If it is necessary to create new vocabulary terms, they should be chosen from a recognized source, or where no appropriate terms or vocabularies exist, new terms may be created and a source identified (see IMS Vocabulary Definition Exchange (VDEX) Best Practice and Implementation Guide Specification section 2). For further guidelines for selecting appropriate vocabularies see section 3 of this document above. When using a term from a vocabulary other than those declared in the LOM, the specific vocabulary being used must be identified in the source element of the vocabulary item, suggested best practice is to use identifiers that are likely to be unique over their expected lifetime, preferably URIs based on registered names. For example, if the vocabulary for 5.2 Educational.Learning Resource Type has been supplemented with the term "MotivatingExample" from a hypothetical vocabulary (URI http://www.vocabularies.org/LearningResourceType) then a fragment of a LOM instance might look like this:

 <context>
<source>LOMv1.0</source>
<value>narrative text</value>
</context>
<context>
<source>http://www.vocabularies.org/LearningResourceType</source>
<value>MotivatingExample</value>
</context>

If the element is not repeatable, implementers may choose to use their own customized vocabulary but should be aware that customized vocabularies may not be recognized by other conforming applications.

4.2.6 Translations

There are a number of considerations that are important to bear in mind when implementing the LOM in non-English or multilingual contexts:

The CEN/ISSS WS-LT (Work Shop on Learning Technologies; http://www.cenorm.be/isss/Workshop/lt/) has undertaken translation of the LOM conceptual data schema (element titles and vocabulary values) into a variety of European languages. At the time of writing, most of these translations have not been made publicly available in finalized form.

In the context of XML bindings for the LOM, LOM element names and vocabulary values should not be translated. In an XML schema document or XML-formatted record, the original English versions of these names and values should be regarded as linguistically neutral strings or tokens. Equivalents in alternative languages should be provided through the user interface or any other mechanisms through which these element titles and vocabulary values are presented to end-users. The failure of applications to present different labels in their user interfaces from those stored in the actual XML files is a considerable inconvenience for those that cannot or do not want to expose their users to the English token values.

Identifying equivalents for elements and vocabulary values can be challenging and may present barriers to semantic interoperability. For example, the common French translation for "Publisher" is éditeur, a word that, along with the French rédacteur, can be taken to mean "editor". This difference in emphasis and association may create problems for the translation and use of French terms for the vocabulary values associated with 2.3.1 Lifecycle.Contribute.Role. Whenever possible, translated element titles and values should be accompanied with definitions that clarify their meaning.

The CEN/ISSS WS-LT has released two CEN Workshop Agreements (CWAs) providing further guidance for the use of the LOM in multilingual contexts:

CWA14643 "Internationalisation of the IEEE Learning Object Metadata"
http://www.cenorm.be/cenorm/businessdomains/businessdomains/informationsocietystandardizationsystem/published+cwas/cwa14643.pdf

CWA 14645 "Availability of alternative language versions of a learning resource in IEEE LOM"
http://www.cenorm.be/cenorm/businessdomains/businessdomains/informationsocietystandardizationsystem/published+cwas/cwa14645.pdf

4.2.7 Mapping Semantics

It is also possible to create meta-data application profiles through the refinement or mapping of the semantics implicitly and explicitly indicated in the data model. As in the case of the LOM conceptual data schema, the semantics of the element titles and vocabulary values are often not defined explicitly or in great detail. The precision of the meanings of these data elements can be increased in two ways.

Firstly, the LOM element or value may be mapped to a more precisely defined element or term in a related schema or element set. The more detailed or explicit definition from this related schema can then be applied to the LOM element or value. In addition, best or common practices associated with that element in the related schema can also be applied to the equivalent or associated LOM element or value. For example, definitions and practices established in the MARC community for the title of a published resource can be applied and adapted for use with the LOM General.Title element.

Secondly, the meaning of the LOM element or value can be defined through reference to best and common practices in the LOM community, or through use and interpretation of definitions provided in the Oxford English Dictionary, Second Edition, as recommended by the LOM conceptual data schema itself. In some meta-data communities (e.g., Dublin Core), the product of these mapping and refinement activities is known as a "guidelines" document. In addition, if such refinements and mappings are created in the form of an application profile they can contribute to other profiling activities that focus more exclusively on the definition of element subsets and related constraints or extensions. An example of such a refinement and mapping activity relating directly to the LOM is provided by CanCore (http://www.cancore.org/).

4.3 Implementation

4.3.1 Strict Implementation of the LOM Conceptual Data Schema

Meta-data creators may find their needs met by one or more of the existing conceptual data schema categories and its family of elements and vocabulary terms. These implementers do not need to go beyond the conceptual data schema as strict implementation meets their needs. This ensures the highest levels of semantic interoperability when exchanging meta-data instances between systems.

A strictly conforming LOM instance will only contain elements drawn from the LOM conceptual data schema schema and will not contain extensions. This does not imply that all LOM elements must be used in a strictly conforming instance.

Note that the conceptual data schema category Classification provides a mechanism for extending LOM as long as the information can be represented as a taxon path and does not introduce semantic ambiguity.

4.3.2 Extending the LOM Conceptual Data Schema

The LOM conceptual data schema intentionally provides elements and element groups that can be adapted for different purposes. It is recommended that elements should be adapted as per the LOM conceptual data schema rather than added as extensions. For example, instead of adding an element to accommodate thumbnail images of full size images, the elements in the Relation category can be adapted and used to meet this requirement. It is also recommended that the Classification category should be used to accommodate requirements that might otherwise be addressed by extensions. For example, the set of vocabulary terms in the Educational category cannot be expected to cover the diversity of educational practice globally. For attributes that cannot be covered in the Educational category, the Classification category may be used. However users should note that using the Classification category in this way might have a significant impact on semantic interoperability.

If community requirements cannot be accommodated within the data types and structures of the LOM conceptual data schema it may be necessary to create extensions. However implementers should recognize that extensions are, by their nature, community specific and consequently will have a significant impact on both semantic and syntactic interoperability. While extensions will have meaning within a community of practice they are unlikely to be of relevance outside this community. Following the recommendations outlined in this section will help to maximize the interoperability of community specific meta-data extensions.

There are a variety of recommended methods for creating and managing LOM extensions. New elements or element categories may be created, element repetitions may be increased by altering the smallest permitted maximum and the length of CharacterStrings and LangStrings may be extended. In addition, vocabulary terms may be supplemented and new vocabularies created. Guidelines for extending vocabularies are outlined in section 4.2.5 above.

If it is deemed necessary to create a new element or elements, then they should not replicate the coverage of existing elements. For example an "ISBN" element for encoding the ISBN of a resource should not be created, as this would replicate the General.Identifier.Entry element with General.Identifier.Catalog set to "ISBN".

In certain instances implementers may wish to describe categories of information that are not covered in detail by the LOM. The number of possible examples of such categories2 raises the prospect of an already large meta-data element set growing to an unmanageable size. Best advice at this time is that implementers should create a new element set describing the category of information that may be used independently or in conjunction with elements from the LOM and other meta-data schemata. New element sets should comprise elements from existing recognized meta-data standards or, where no appropriate elements exist, new elements may be created.

4.4 Exposing Meta-data

The IEEE LOM conceptual data schema says nothing about how meta-data should be stored and managed within a standalone environment. However, in order to facilitate interoperability, it is necessary for machine readable instances of meta-data to be exposed. To meet this requirement, the IEEE LTSC is publishing standards for binding LOM instances in various formats as part of the Standard for LOM. This section is concerned with the XML binding, IEEE 1484.12.3.

4.4.1 IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata

Within the IMS community, XML is the preferred encoding syntax for binding conceptual data schemata. At the time of writing, the section of the IEEE Standard for LOM dealing with the XML binding (that is, IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata) had not been ratified. However, a draft had been produced. Information on the progress of the standard for XML binding can be found at the IEEE LTSC WG12 website (http://ltsc.ieee.org/wg12).

In conjunction with the normative IEEE standard for XML binding, the IEEE LTSC will release an informative XML schema that conforms to this standard. Implementers of the XML schema can choose from a variety of options each of which reflect different design preferences. It should be noted that implicit or explicit choices must be made when binding a conceptual model such as the LOM conceptual data schema to an XML schema. For example, the LOM conceptual data schema requires that extension elements should not duplicate elements that are already part of the LOM. Conditions like this cannot be validated against an XML schema alone. As another example, some implementations assume that elements in a meta-data record appear in the order that they are listed in the LOM conceptual data schema. Such ordering may be built into a schema but such a schema would impose restrictions that do not exist in the LOM data model. A technical discussion of these issues appears in the IEEE standard for XML binding.

4.4.2 Application Profile Bindings and Conformance

Strictly conforming LOM instances must consist solely of LOM elements, they must conform to IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata and should validate against the XML schema, lomStrict.xsd, that accompanies the draft standard. In addition to validating against the IEEE XML schema, implementers may choose to create their own schema for the sake of performance gains or in order to include any additional restrictions that they have placed on the data schema in the validation.

Customized LOM instances may include extensions of the type outlined in section 4.3.2 above. Elements, element sets or vocabularies that are used to extend the LOM should be identified by their own namespaces. Within the context of meta-data implementation a namespace may be defined as "a formal collection of terms managed according to a policy or algorithm" (Duval et al, 2002). While identifying community specific extensions using namespaces helps to maximize potential interoperability, it should be noted that, in general, extensions have a negative impact on interoperability. Namespaces allow the identification of elements and vocabularies from sources outside the LOM conceptual data schema. When an application processes meta-data and encounters an extension namespace it may choose to read, store or ignore the community specific information depending on its capabilities

As meta-data is frequently stored in local databases that are only accessed by dedicated local applications, it is not necessary to mandate the form of the internal representation of the meta-data. However, if meta-data is going to be exposed for the purpose of data interchange, then specific commonly understood syntax is required and commonly adhered-to protocols imposed if this interchange is to be conducted as runtime transactions. Conforming LOM instances, including extensions, should adhere to the rules outlined in IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata which is expected to be ratified by the IEEE LTSC in 2004. In order to facilitate interoperability, it is recommended that conforming instances should validate against both the schema produced to accommodate the specific extensions of the application profile and, to enable data interchange, with the XML schemata that accompany the IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata.

If extensions are created that do not adhere to the rules of IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata the instance will be non-confroming.

4.4.3 Migration from IMS LRM XML Binding v1.2.1 to the IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata

An XML Style Sheet Transformation (XSLT) has been created to facilitate the translation of existing IMS LRM XML Binding v1.2.1 Final Specification to the draft IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata. Note that at the time of writing this guide, the IEEE P1484.12.3 Draft Standard for Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata, is a draft document. It is expected that IMS will update this XSLT when the final binding is released.

For more information see Appendix C - IMS LRM v1.2.1 to IEEE LOM 1.0 Transform.

4.4.4 Creating XML LOM Instances

LOM instances are expressed and bound in XML to provide a common and standardized means of facilitating functions such as search and discovery and for management in a distributed environment. The following practices are recommended for producing XML instances of LOM:

Appendix A - Additional Resources

IEEE Standard for Learning Object Metadata (LOM)

1484.12.1 IEEE Standard for Learning Object Metadata (LOM) conceptual data schema can be found at: http://standards.ieee.org/

Information relating to the IEEE 1484.12.3 Draft Standard for eXtensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata can be found at: http://ltsc.ieee.org/wg12/par1484-12-3.html

Further information about the IEEE Learning Object Metadata Working Group is available at: http://ltsc.ieee.org/wg12/index.html

IMS Meta-data Documents

The IMS Learning Resource Meta-data specifications versions 1.0 - 1.3 can be found at: http://www.imsglobal.org/metadata/

vCard Information

A variety of vCard related links can be found at: http://www.imc.org/pdi/

XML Resources

The XML specification and additional links can be found at: http://www.w3.org/XML/

Information about the XML Namespaces recommendation can be found at: http://www.w3.org/TR/1999/REC-xml-names-19990114/

Application Profiles

Baker, T. (2003) DCMI Usage Board Review of Application Profiles, Dublin Core Metadata Initiative
http://dublincore.org/usage/documents/profiles/

CORES Registry
http://www.cores-eu.net/registry/schema/

Duval, E., Hodgins, W., Sutton, S., & Weibel, S. (2002) Metadata Principles and Practicalities, D-Lib Magazine, Vol 8 (4)
http://www.dlib.org/dlib/april02/weibel/04weibel.html

Friesen, N., Mason, J. and Ward, N. (2002) Building Educational Metadata Application Profiles, Proceedings of the International Conference on Dublin Core and Metadata for e-Communities pp. 63-69, Florence: Firenze University Press
http://www.bncf.net/dc2002/program/ft/paper7.pdf

Kotok, A. (2002) Metadata Rules: A report from the Open Forum on Metadata Registries
http://www.webservices.org/index.php/article/articleview/922/1/24/

Ottawa (2001) The Ottawa Communique
http://www.ischool.washington.edu/sasutton/dc-ed/Ottawa-Communique.rtf

SC32/WG2 Home Page - Metadata Standards
http://metadata-stds.org

SCHEMAS Registry
http://www.schemas-forum.org/registry/desire/appprofile.php3

Guides to the LOM and Examples of Use

CanCore http://www.cancore.ca/
The CanCore Profile is intended to facilitate the interchange of records describing educational resources and the discovery of these resources both in Canada and beyond its borders. CanCore is fully compatible with the IEEE LOM standard and provides best practice recommendations for all LOM elements.

CELEBRATE http://www.eun.org/eun.org2/eun/en/index_celebrate.cfm
CELEBRATE is outlining a pedagogy for eLearning in European schools based on a vision of what 'content' (resources + services + communication spaces) may look like in the future and how this will be created and delivered in online environments.

CETIS Metadata and Digital Repositories SIG http://metadata.cetis.ac.uk/
The UK Centre for Educational Technology Interoperability Standards meta-data advisory site. The SIG provides information on relevant specifications and standards, promotes the uptake of these specifications and standards, facilitates discussion among people using these specifications and standards and provides feedback to developers of future specifications and standards.

European Treasury Browser http://www.eun.org/eun.org2/eun/en/etb/sub_area.cfm?sa=441
The aim of the ETB project is to build a Web educational resource Metadata Networking infrastructure for schools in Europe, to link together existing national repositories, encourage new publication, and provide a reliable level of quality and structure.

The Le@rning Federation http://www.thelearningfederation.edu.au/repo/cms2/tlf/published/8519/Metadata_Application_Profile_1_3.pdf
The goal of The Le@rning Federation is for Australian education systems to collaboratively develop and provide a continuing supply of high quality online educational content.

MERLOT http://www.merlot.org/
MERLOT (Multimedia Educational Resource for Learning and Online Teaching) is a free and open resource designed primarily for faculty and students of higher education. Links to online learning materials such as learning objects are catalogued along with annotations such as peer reviews and assignments.

SCORM http://www.adlnet.org/
The Sharable Content Object Reference Model (SCORM) is a collection of specifications adapted from multiple sources to provide a comprehensive suite of e-learning capabilities that enable interoperability, accessibility and reusability of Web-based learning content.

UK LOM Core http://www.cetis.ac.uk/profiles/uklomcore
The UK LOM Core is an application profile of the IEEE LOM that has been optimized for use within the context of UK education. It provides a set of guidelines have been drafted to inform UK practitioners on the implementation of a minimum common core of LOM elements and associated vocabularies.

Appendix B - Mapping to Simple Dublin Core

Annex B to IEEE 1484.12.1 - 2002 Standard for LOM conceptual data model includes a mapping from the IEEE LOM to "Unqualified Dublin Core". The Dublin Core Metadata Element Set3 contains 15 simple, unqualified elements, which can be found at http://dublincore.org/documents/dces/. This element set has been formally endorsed by ISO, NISO, and a CEN Workshop Agreement, details of which are provided on the Dublin Core Metadata Initiative website. The elements in this set are stable and expected to remain so, however it should be noted that whereas Annex B of the LOM lists the DC element OtherContributer the stable Dublin Core element set uses Contributor.

The semantics of the unqualified Dublin Core elements are intentionally rather broad. It should be noted that the mapping is a one-way mapping, from the LOM to Dublin Core and that transforming meta-data from the IEEE LOM to unqualified Dublin Core will result in the loss of information. For example, the Dublin Core Date element could mean the date of authoring or the date of publication. The ability to populate an Unqualified Dublin Core record from an IEEE LOM instance will however remain useful to those who wish to interoperate with systems where Unqualified Dublin Core is recommended, for example those using Open Archives Initiative Protocol for Metadata Harvesting4.

The Dublin Core Metadata Initiative has developed Qualified Dublin Core which does not demand the losses described above. Dublin Core Metadata is also frequently included in Application Profiles. Specifically, some communities use special Dublin Core domain specific application profiles that are recommended by the DCMI Usage Board. The DC Education Application profile was developed with the LOM in mind and includes both DC and LOM originating elements.

Appendix C - IMS LRM v1.2.1 to IEEE LOM 1.0 Transform

An XSL Transform (XSLT) for transforming IMS Learning Resource Meta-data Information Model v1.2.1 Final Specification to IEEE 1484.12.1 - 2002 Standard for Learning Object Metadata has been written in conjunction with the work on this document. It includes numerous support files designed to help ensure the transformation suits the needs of any particular user, as well as, to illustrate the operation of the transform.

It does not address best practices for transforming large numbers of documents, for deciding how and when to transition from IMS Learning Resource Meta-data Information Model v1.2.1 Final Specification to IEEE 1484.12.1 - 2002 Standard for Learning Object Metadata, or for archiving old IMS LRM instances. It addresses the transform itself and how users may modify the transform to ensure that it addresses their needs.

Note that the XSLT itself is a technical program and assumes knowledge of XML. It may be necessary to augment or edit the transform to suit the specific needs of the user.

You will find the XSLT and supporting document at: http://www.imsglobal.org/metadata/mdv1p1p3pd/xslt.

About This Document

Title
IMS Meta-data Best Practice Guide for IEEE 1484.12.1-2002 Standard for Learning Object Metadata
Editor
Phil Barker, Lorna M. Campbell, Anthony Roberts
Version
1.3
Version Date
20 May 2004
Status
Public Draft
Summary
This document provides updated information regarding IMS Meta-data Best Practice and Implementation Guide
Revision Information
May 2004
Purpose
This document has been approved by the IMS Technical Board and is made available for pubic review and comment.
Document Location
http://www.imsglobal.org/metadata/mdv1p3pd/imsmd_bestv1p3pd.html

To register any comments to the Meta-data Project Group about this Public Draft release, please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=3

List of Contributors

The following individuals contributed to the development of this document:

Name Organization Name Organization
Phil Barker
CETIS
Mikael Nilsson
CID, Royal Institute of Technology, Stockholm
Martin Koning Bastiaan
Center for Distributed Learning
Solvig Norman
Open School BC / Industry Canada
Lorna M. Campbell
CETIS
Claude Ostyn
Click2learn, Inc.
Norm Friesen
Athabasca University
Mariano Sanz Prieto
European Schoolnet
Pierre Gorissen
SURF / SIX
Dan Rehak
Carnegie Mellon University
Jon Mason
DEST - Australia
Toni Roberts
TeleEducationNB
Liddy Nevile
DEST - Australia
Robby Robson
IEEE / LTSC
Boyd Nielsen
NETg
Schawn Thropp
ADL

Revision History

Version No. Release Date Comments
Final 1.0
20 August 1999
The version 1.0 of the IMS Learning Resource Meta-data Best Practice and Implementation Guide.
Final 1.1
5 May 2000
All element names changed to lower case only. Comments on namespace use changed.
Public Draft 1.2
20 April 2001
a) Updated IEEE LTSC LOM elements tables to latest version of LOM Working Draft 6.1.
b) Changed root element from <record> to <lom>.
c) Deprecated the IMS "Core" or "Standard Extension Library" or LOM elements.
Final 1.2
17 May 2001
a) Deprecated the <vocabulary> element.
b) Renamed <keywords> and <requirements> to <keyword> and <requirement>, respectively.
c) Added "ANY" function to allow extensibility on terminal node elements or those that don't already allow sufficient extensibility through the LOM data type.
d) Added a Possible Futures Directions Appendix.
Final 1.2.1
28 September 2001
a) Corrected minor discrepancies between element descriptions in the IMS Meta-data XML Binding and Information Model.
Public Draft 1.3
20 May 2004
a) IMS LRM Information Model v1.2.1 Final Specification is realigned with the IEEE Std 1484.12.1 - 2002, IEEE Standard for Learning Object Metadata.
b) IMS LRM Information Model v1.2.2 Public Draft is realigned with the IEEE 1484.12.1 - 2002 Learning Object Metadata
c) IMS LRM Best Practice and Information Guide v1.2.1 is revised.
d) IMS LRM XML Binding is realigned with the IEEE 1484.12.3 - 2002 Standard for XML Binding for LOM Data Model.
e) IMS LRM v1.2.1 to IEEE LOM 1.0 XSL transform published.
f) Guidelines for using the IMS LRM v1.2.1 to IEEE LOM 1.0 XSL transform published.
g) Incorporates changes as appropriate from IMS Technical Board.

Index

A
Application profile 1, 2, 3, 4, 5, 6, 7, 8, 9
ARIADNE 1

B
Binding 1, 2, 3, 4, 5

C
CanCore 1, 2
CEN/ISSS 1, 2, 3, 4

D
Datatype 1, 2, 3, 4
Dublin Core 1, 2, 3, 4, 5

E
Extensions 1, 2, 3, 4, 5

I
ICP 1, 2
IEEE 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19
Interoperability 1, 2, 3, 4, 5, 6

L
Learning Resource 1, 2, 3, 4, 5, 6
LOM 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20
LRM 1, 2, 3, 4
LTSC 1, 2, 3, 4, 5, 6

M
Meta-data 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
MIME 1

N
Namespaces 1, 2, 3

P
Profile 1, 2, 3, 4, 5

R
Resource 1, 2, 3, 4, 5, 6
RFC 1, 2, 3

S
Schema 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
SCORM 1, 2
Standards 1, 2, 3, 4, 5, 6, 7, 8
Structure 1, 2, 3, 4, 5

T
taxon 1
Translation 1, 2, 3

U
URI 1, 2

V
vCard 1, 2
Vocabularies 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Vocabulary 1, 2, 3, 4, 5, 6, 7, 8

W
W3C 1

X
XML 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
XSL 1, 2, 3
XSLT 1, 2, 3

1
For legal reasons the hyphenated form "meta-data" will be used in this specification except when referring to the titles of documents and standards which use the form "metadata".

2
Examples might include: image-specific technical details, preservation meta-data, accessibility issues, descriptions of how a resource has been used (so-called secondary meta-data), digital rights, etc.

3
At the time of writing the latest version of the Dublin Core Element Set was version 1.1, first issued in July 1999. The latest reference documentation at the time of writing was issued in June 2003 and is available at http://dublincore.org/documents/2003/06/02/dces/

4
Open Archive Initiative-Protocol for Metadata Harvesting, see http://www.openarchives.org/

 

 

 

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Meta-data Best Practice Guide for IEEE 1484.12.1-2002 Standard for Learning Object Metadata ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

IMS makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

IMS would appreciate receiving your comments and suggestions.

Please contact IMS through our website at http://www.imsglobal.org

Please refer to Document Name:
IMS Meta-data Best Practice Guide for IEEE 1484.12.1-2002 Standard for Learning Object Metadata Revision: 20 May 2004