IMS Logo IMS Learning Resource Meta-Data XML Binding
Version 1.2.1 Final Specification
Copyright © 2001 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Learning Resource Meta-Data XML Binding
Revision: 28 September 2001

 

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 © 2001 IMS Global Learning Consortium. All Rights Reserved.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.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 XML Basics
           1.1.1 Elements
           1.1.2 Document Type Definitions
           1.1.3 XML Schemas
           1.1.4 Valid Character Sets
           1.1.5 Use of Attributes
           1.1.6 Lists
           1.1.7 Namespaces

2. Narrative Description of XML Binding
     2.1 <lom> Element
     2.2 <general> Element
           2.2.1 <identifier> Element
           2.2.2 <title> Element
           2.2.3 <catalogentry> Element
           2.2.4 <language> Element
           2.2.5 <description> Element
           2.2.6 <keyword> Element
           2.2.7 <coverage> Element
           2.2.8 <structure> Element
           2.2.9 <aggregationlevel> Element
     2.3 <lifecycle> Element
           2.3.1 <version> Element
           2.3.2 <status> Element
           2.3.3 <contribute> Element
     2.4 <metametadata> Element
           2.4.1 <identifier> Element
           2.4.2 <catalogentry> Element
           2.4.3 <contribute> Element
           2.4.4 <metadatascheme> Element
           2.4.5 <language> Element
     2.5 <technical> Element
           2.5.1 <format> element
           2.5.2 <size> element
           2.5.3 <location> element
           2.5.4 <requirement> element
           2.5.5 <installationremarks> Element
           2.5.6 <otherplatformrequirements> Element
           2.5.7 <duration> Element
     2.6 <educational> Element
           2.6.1 <interactivitytype> Element
           2.6.2 <learningresourcetype> Element
           2.6.3 <interactivitylevel> Element
           2.6.4 <semanticdensity> Element
           2.6.5 <intendedenduserrole> Element
           2.6.6 <context> Element
           2.6.7 <typicalagerange> Element
           2.6.8 <difficulty> Element
           2.6.9 <typicallearningtime> Element
           2.6.10 <description> Element
           2.6.11 <language> Element
     2.7 <rights> Element
           2.7.1 <cost> Element
           2.7.2 <copyrightandotherrestrictions> Element
           2.7.3 <description> Element
     2.8 <relation> Element
           2.8.1 <kind> Element
           2.8.2 <resource> Element
     2.9 <annotation> Element
           2.9.1 <person> Element
           2.9.2 <date> Element
           2.9.3 <description> Element
     2.10 <classification> Element
           2.10.1 <purpose> Element
           2.10.2 <taxonpath> Element
           2.10.3 <description> Element
           2.10.4 <keyword> Element

3. Elements Used Globally
     3.1 LangString Binding
     3.2 Date Binding
           3.2.1 <datetime> Element
           3.2.2 <description> Element
     3.3 Vocabulary Binding
           3.3.1 <source> Element
           3.3.2 <value> Element
     3.4 Vcard Binding

4. Special Handling Requirements for Meta-Data Elements
     4.1 Type Structures
           4.1.1 LangStringType
           4.1.2 DateType
           4.1.3 VocabularyType
     4.2 Language Elements
     4.3 TaxonPath Elements
     4.4 vCard Elements
     4.5 Keyword Elements

5. Extensibility
     5.1 Extensions with DTDs
     5.2 Extensions with XML Schema Definition Language

6. Using the vCard Specification

Appendix A - IMS Meta-Data RDF Binding
     A.1 Using RDF for Meta-Data as Compared to Pure XML
     A.2 Design Criteria for RDF Binding
     A.3 Relationship to Other Standards
           A.3.1 Dublin Core
           A.3.2 LOM/IMS XML
           A.3.3 vCard
     A.4 Guidelines to Specific Constructs
           A.4.1. Namespaces
           A.4.2 rdf:value and Other Constructs
           A.4.3. Language-Specific Strings
           A.4.4 Ordered and Unordered Lists
           A.4.5 Pre-Defined Classes
           A.4.6 Vocabularies
           A.4.7 Using Metameta-data
           A.4.8 Classifications
     A.5 Acknowledgements
     A.6 The Binding Table
           1. General Category
           2. Lifecycle Category
           3. Metametadata Category
           4. Technical Category
           5. Educational Category
           6. Rights Category
           7. Relation Category
           8. Annotation Category
           9. Classification Category
     A.7 LangString Definition
     A.8 Taxonomies

Appendix B - Additional Resources

Appendix C - List of Contributors

About This Document

Revision History

Index


1. Introduction

This document describes the XML binding for the IMS Learning Resource Meta-Data Information Model. The model is based on the IEEE Learning Technology Standards Committee (LTSC) Learning Object Meta-Data (LOM) Draft Standard, plus modifications approved by the IMS Technical Board and submitted to IEEE. For links to the related IEEE documents, please see http://www.imsglobal.org/metadata/imsmdv1p2p1/imsmd_infov1p2p1.html.

1.1 XML Basics

The LOM conceptual model for meta-data definitions is a hierarchy. Hierarchical models are convenient for representing data consisting of many elements and sub-elements. XML is perfectly suited for representing hierarchical models. An XML document is a hierarchy comprised of elements that have contents and attributes.

1.1.1 Elements

An element is a component of a document that has been identified in a way a computer can understand. Each element has a tag name. When a tag name is shown as "<TAGNAME>", with less-than and greater-than symbols before and after the tag name, it serves as the start-tag to mark the beginning of an element. When that same tag name has a forward slash "/" added, it serves as an end-tag such as "</TAGNAME>". An element may have contents between its start and end-tags, and may have one or more attributes. When an XML element has a start and end-tag (also called an opening and closing tag) with a common name, it is considered to be "well-formed" XML. The contents of an element are placed between the start and end-tags as shown below:

<TAGNAME>contents</TAGNAME>

1.1.1.1 Element Contents

An element may contain other elements, Parsed Character Data (PCDATA), Character Data (CDATA), or a mixture of PCDATA and elements. The allowable contents of an element are its content model. XML parsers treat PCDATA with their special or reserved meaning unless they are specifically marked (or "escaped"). In contrast, CDATA can use special or reserved characters without having to escape them, as CDATA is not read by XML parsers.

1.1.1.2 Element Attributes

An attribute provides additional information about an element. Attributes are a way of attaching characteristics or properties to the elements of a document. An element may have more than one attribute. Attributes are contained within the start tag of an element. Attributes are represented by an attribute name followed by an equal sign and the attribute value in quotation marks:

<timeframe>
  <begin restrict="1"> 1999-07-23 </begin>
</timeframe>

In this example, the timeframe element contains another element: the begin element. The begin element has one attribute "restrict", with the value "1". The value for the element BEGIN is "1999-07-23". These two elements then make up a timeframe begin date.

1.1.1.3 Element Names

Each element has a unique name, referred to as the tag name. XML is case-sensitive in its processing of tag names. The IMS Learning Resource Meta-Data XML Binding Specification adheres to the following tag name rules:

  • All tag names will conform to the rules for element naming as given within the XML 1.0 Specification.
  • Names beginning in XML in any case or mix of cases are not permitted.
  • The IMS binding will use only lowercase tag and element names.
  • Element names may not include words reserved by the XML specification. These include:

DOCTYPE
ELEMENT
ATTLIST
ENTITY

  • Tag names defined by the IMS Binding may not be redefined.

1.1.2 Document Type Definitions

The tag name, content model, and attributes of elements are defined in a Document Type Definition (DTD) statement. This may exist as an external file or a block of text internal to an XML document. Internal DTDs are used to override elements defined in external DTD files, so an internal DTD should be used with care. The DTD defines the elements that may be used and may define the contents of the elements.

This specification defines a DTD (imsmd_rootv1p2.dtd) as a non-normative reference. Some XML editors may make use of a DTD to help guide the developer in creating the proper elements at the proper locations in an XML file. Other developers will make use of DTDs to validate their XML documents to ensure their document is consistent with all of the element names and locations defined in the DTD. Details of the construction of DTDs are outside the scope of this document, but links to the XML 1.0 Specification are included in the Appendix.

1.1.3 XML Schemas

A schema is a formal specification of element names that indicates which elements are allowed in an XML instance, and in which combinations. New schema languages, such as those defined in the XML-Schemas Working Group, provide the same baseline functionality as a DTD. However, because these schema languages are extensible, developers can augment them with additional information, such as data types, inheritance, and presentation rules. This makes schema languages far more powerful than DTDs. For more information about XML schemas, there is a link to the W3C XML Schema Recommendation in the Appendix.

This specification defines a W3C XML Schema (imsmd_rootv1p2p1.xsd), and a Microsoft XML-Data Schema (XDR) as non-normative references. Some XML editors may make use of these schemas to help guide the developer in creating the proper elements at the proper locations in an XML file. Other developers will make use of the schemas to validate their XML instances and/or to define extensions to the IMS Meta-Data Binding. Details of the construction of schemas are outside the scope of this document.

1.1.4 Valid Character Sets

An IMS meta-data instance must use UTF-8 or UTF-16 encoding of the character sets as defined in ISO 10646. See the XML Version 1.0 for more details on the specification of well-formed XML.

1.1.5 Use of Attributes

Within the IMS Meta-Data Binding specification, the use of attributes is reserved for information about the structure of and source of terms in the meta-data instance. It is recommended that attributes not be used for information about the resource. This Binding specification uses only two element attributes (the "xml:lang" attribute and the "type" attribute) in particular ways and for particular purposes.

xml:lang:

This attribute specifies the human language of the contents of the element. It is only used as an attribute of the <langstring> element. The "xml:lang" attribute may contain a two-character language code followed by a two-character country code. For example:

<otherplatformrequirements>
  <langstring xml:lang="en-US">Will not run in browser.</langstring>
</otherplatformrequirements>

The codes for languages and countries are enumerated in the W3C XML Specification.

Note: When using the <langstring> element's "xml:lang" attribute in the VocabularyType (within <source> and <value>), the xml:lang attribute shall have a value of "x-none".

<role>
  <source>
    <langstring xml:lang="x-none">LOMv1.0</langstring>
  </source>
  <value>
    <langstring xml:lang="x-none">Author</langstring>
  </value>
</role>

type:

This attribute specifies the type of string that may be used to identify the location of a learning resource as used in the <location> element. The type attribute may be assigned the value of either "URI" or "TEXT". 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. For example:

<technical>
  <format/>
  <size>1032353</size>
  <location type="URI">http://www.brookscole.com</location>
</technical>

1.1.6 Lists

The meta-data specification uses listing at multiple levels in the hierarchy. A list is a repetition of the contents of an element. In XML this is accomplished by repeating the containing element:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE record [
  <!ELEMENT general (language*)>
  <!ELEMENT language (#PCDATA)>
  ]>
<lom>
  <language>en_US</language>
  <language>fr_FR</language>
</lom>

In this example, the <language> element is repeated. Thus, <language> is the containing element for the repeated contents of "en_US" and "fr_FR". The notation for repetitions of an element in a content model follows the W3C XML Specification. An asterisk (*) specifies that none or more repetitions of the <language> element may be included in the XML instantiation. There are two main types of lists: ordered and unordered.

1.1.6.1 Ordered Lists

Repeating the listed element at its specific location in the XML structure creates an ordered list of contents. The order of the elements has significance as their placement in the XML file determines this. The following is an example of an XML fragment in which the <educational> element contains an ordered list of <learningresourcetype> elements:

<educational>
  <learningresourcetype>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">Simulation</langstring>
    </value>
  </learningresourcetype>
  <learningresourcetype>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">Assessment</langstring>
    </value>
  </learningresourcetype>
</educational>

1.1.6.2 Unordered Lists

Repeating the containing element at its specific location in the XML structure creates an unordered list of contents. The order of the repetitions has no significance. For example:

<general>
  <language>en_US</language>
  <language>fr_FR</language>
</general>

In this example, each new instance of a definition of a language requires that the <language> element be repeated. Whether an element list should be treated as ordered or unordered is specified by the IEEE LOM Draft Standard.

1.1.7 Namespaces

XML is designed to allow individuals to create their own element tag names. It soon became apparent that there could be problems if different DTDs were used in the same document and those DTDs had elements using the same name. The W3C XML Namespace Recommendation specifies a way to ensure that names from different DTDs can be identified in a single document.

The XML Namespace document provides more information about the flexible capabilities of namespaces. The W3C Recommendation for Namespaces (http://www.w3.org/TR/1999/REC-xml-names-19990114) does not specify how namespaces are to be used. The introductory abstract states the following:

"XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references."

The W3C XML 1.0 Specification does not specify how namespaces are to be processed. Currently there are two general approaches to namespaces:

  1. Use to point to a specific encoding schema for machine interpretation, and
  2. Use as a reference for uniqueness and possibly definition (semantics).

These two approaches are not mutually exclusive. A namespace is applied as a prefix to an element or attribute name:

<dc:subject>

The prefix of dc: is the qualifier, and must be defined elsewhere in the document. The user is directed to the W3C Namespace Recommendation for more details on application. IMS does not specify how namespaces are to be resolved (semantically or for machine interpretation). Namespaces should point to schema files for validation. To point to a schema file locally, the schema and the XML instance must reside in the same directory and would look similar to the following:

<lom xmlns="http://www.imsproject.org/xsd/imsmd_rootv1p2p1" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:schemaLocation="http://www.imsproject.org/xsd/imsmd_rootv1p2p1 imsmd_rootv1p2p1.xsd">

To validate your XML instance online your namespace reference would look similar to the following:

<lom xmlns="http://www.imsproject.org/xsd/imsmd_rootv1p2p1" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:schemaLocation="http://www.imsproject.org/xsd/imsmd_rootv1p2p1 http://www.imsproject.org/xsd/imsmd_rootv1p2p1.xsd">

2. Narrative Description of XML Binding

This section of the specification uses a simple narrative to describe the XML format. DTDs and XSDs that implement this abstract format are referenced as non-normative parts of this specification.

The reader's attention is called to LOM's "smallest permitted maximum" concept. Implementations are not guaranteed to handle more than a smallest permitted maximum declared for a given element or string length.

2.1 <lom> Element

Description. General information that describes the learning object as a whole.

Multiplicity. The <lom> element is the root element of the XML instance. This element should occur 1 and only 1 time in an IMS XML Meta-Data instance.

Attributes

  • xmlns - indication of the IMS Meta-Data Namespace

Elements

  • <general>
  • <lifecycle>
  • <metametadata>
  • <technical>
  • <educational>
  • <rights>
  • <relation>
  • <annotation>
  • <classification>

2.2 <general> Element

Description. General information that describes the learning object as a whole.

<general> elements

 

Figure 2.1 <general> elements.

Multiplicity. The <general> element occurs 0 or 1 time within the top-level <lom> element.

Attributes

  • None

Elements

  • <identifier>
  • <title>
  • <catalogentry>
  • <language>
  • <description>
  • <keyword>
  • <coverage>
  • <structure>
  • <aggregationlevel>

2.2.1 <identifier> Element

Description. A globally unique label that identifies this learning object. This element is no longer reserved and authors may use their own ID method or the IMS Persistent, Location-Independent Resource Identifiers Best Practice Guide, which at the time of this writing was being considered as an IMS wide base specification.

Multiplicity. The <identifier> element occurs 0 or 1 time within the <general> element.

Attributes

  • None

Elements

  • None

2.2.2 <title> Element

Description. Name given to the learning object.

Multiplicity. The <title> element occurs 0 or 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).

Example

<general>
  <title>
    <langstring xml:lang="en">Title 1 in English</language>
    <langstring xml:lang="fr">Titre 1 en francais</language>
  </title>
</general>

2.2.3 <catalogentry> Element

Description. This data element defines an entry within a catalog (i.e. a listing identification system) assigned to this learning object. This sub-category shall describe this learning object 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 instances within the <general> element.

Attributes

  • None

Elements

  • <catalog>
  • <entry>

Example

<general>
  <catalogentry>
    <catalog>ISBN</catalog>
    <entry>
      <langstring>0-226-10389-7</langstring>
    </entry>
  </catalogentry>
</general>

2.2.3.1 <catalog> Element

Description. The name of the catalog (i.e. listing identification system).

Multiplicity. The <catalog> element must occur 1 and only 1 time within the <catalogentry> element.

Attributes

  • None

Elements

  • None

2.2.3.2 <entry> Element

Description. Actual string value of the entry within the catalog (i.e. listing identification system).

Multiplicity. The <entry> element occurs 1 and only 1 time with the <catalogentry> element. If the <catalogentry> element is used, the <entry> elment must occur 1 and only 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).

2.2.4 <language> Element

Description. The primary human language or languages used within this learning object 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 instances within the <general> element.

Attributes

  • None

Elements

  • None

Example

<general>
  <language>en</language>
  <language>fr</language>
</general>

2.2.5 <description> Element

Description. A textual description of the content of this learning object.

Multiplicity. The <description> element occurs 0 or more times within the <general> element. The smallest permitted maximum is 10 instances within the <general> 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

<general>
  <description>
    <langstring xml:lang="en">English description</langstring>
    <langstring xml:lang="fr">French description</langstring>
  </description>
</general>

2.2.6 <keyword> Element

Description. A collection of keywords or phrases describing this learning object. 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 instances within the <general> element.

Attributes

  • None

Elements

  • <langstring> - (The <langstring> element can be repeated 1 or more times within the <keyword> element. However, each langstring is required to contain a different xml:lang attribute).

Example

<general>
  <keyword>
    <langstring xml:lang="en">metadata</langstring>
    <langstring xml:lang="nl">metadata</langstring>
    <langstring xml:lang="fr">metadonnees</langstring>
  </keyword>
  <keyword>
    <langstring xml:lang="en">learning object</langstring>
    <langstring xml:lang="nl">leerobject</langstring>
    <langstring xml:lang="fr">objet d'apprentissage</langstring>
  </keyword>
  <keyword>
    <langstring xml:lang="en">education</langstring>
  </keyword>
<general>

2.2.7 <coverage> Element

Description. The span or extent of such things as time, culture, geography or region that applies to this learning object.

Multiplicity. The <coverage> element occurs 0 or more times within the <general> element. The smallest permitted maximum is 10 instances within the <general> element.

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

Example

<general>
  <coverage>
    <langstring xml:lang="en">Circa, 16th century France</langstring>
  </coverage>
<general>

2.2.8 <structure> Element

Description. Underlying organizational structure of this learning object.

Multiplicity. The <structure> element occur 0 or 1 time within the <general> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • Collection
  • Mixed
  • Linear
  • Hierarchical
  • Networked
  • Branched
  • Parceled
  • Atomic

Example

<general>
  <structure>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">Collection</langstring>
    </value>
  </structure>
</general>

2.2.9 <aggregationlevel> Element

Description. The functional granularity of this learning object.

Multiplicity. The <aggregationlevel> element occurs 0 or 1 time within the <general> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • 1 - the smallest level of aggregation, e.g. raw media data or fragments
  • 2 - a collection of atoms, e.g. an HTML document with some embedded pictures or a lesson
  • 3 - a collection of level 2 learning objects, e.g. a 'web' of HTML documents, with an index page that links the pages together or a course
  • 4 - the largest level of granularity, e.g. a set of courses that lead to a certificate.

Example

<general>
  <aggregationlevel>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">1</langstring>
    </value>
  </aggregationlevel>
</general>

2.3 <lifecycle> Element

Description. Features related to the history and current state of this learning object and those who have affected this learning object during its evolution.

<lifecycle> elements

 

Figure 2.2 <lifecycle> elements.

Multiplicity. The <lifecycle> element occurs 0 or 1 time within the top-level <lom> element.

Attributes

  • None

Elements

  • <version>
  • <status>
  • <contribute>

2.3.1 <version> Element

Description. The edition of this learning object.

Multiplicity. The <version> element occurs 0 or 1 time within the <lifecycle> element.

Attributes

  • None

Elements

  • <langstring> - (The <langstring> element can be repeated 1 or more times within the <version> element. However, each langstring is required to contain a different xml:lang attribute).

Example

<lifecycle>
  <version>
    <langstring xml:lang="en">1.0.alpha</langstring>
  </version>
</lifecycle>

2.3.2 <status> Element

Description. The state or condition of this learning object.

Multiplicity. The <status> element occurs 0 or 1 time within the <lifecycle> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • Draft
  • Final
  • Revised
  • Unavailable

Example

<lifecycle>
  <status>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">Final</langstring>
    </value>
  </status>
</lifecycle>

2.3.3 <contribute> Element

Description. This data element describes those people or organizations that have affected the state of this learning object during its evolution.

Multiplicity. The <contribute> element occurs 0 or more times within the <lifecycle> element. The smallest permitted maximum is 30 instances within the <lifecycle> element.

Attributes

  • None

Elements

  • <role>
  • <centity>
  • <date>

Example

<lifecycle>
  <contribute>
    <role>
      <source>
        <langstring xml:lang="x-none">LOMv1.0</langstring>
      </source>
      <value>
        <langstring xml:lang="x-none">Author</langstring>
      </value>
    </role>
    <centity>
      <vcard>
        begin:vcard
        fn: Joe Author
        end:vcard
      </vcard>
    </centity>
    <date>
      <datetime>2000-12-12</datetime>
      <description>
        <langstring>Date Description</langstring>
      </description>
    </date>
  </contribute>
</lifecycle>

2.3.3.1 <role> Element

Description. This data element describes the kind of contribution. It is recommended that at least the Author(s) of the learning object should be described.

Multiplicity. The <role> element occurs 1 and only 1 time within the <contribute> element. If the <contribute> element is used, the <role> element must occur 1 and only 1 time within the <contribute> element. If there are multiple contributors (different roles), then the <contribute> element should be repeated.

Attributes

  • <source>
  • <value>

Elements

  • None

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • Author
  • Publisher Unknown
  • Initiator
  • Terminator
  • Validator
  • Editor
  • Graphical Designer
  • Technical Implementer
  • Content Provider
  • Technical Validator
  • Educational Validator
  • Script Writer
  • Instructional Designer

2.3.3.2 <centity> Element

Description. This data element is the identification of and information about people or organizations contributing to this learning object, most relevant first.

Multiplicity. The <centity> element occurs 0 or more times within the <contribute> element. The smallest permitted maximum is 40 instances within the <contribute> element.

Attributes

  • None

Elements

  • <vcard>

2.3.3.3 <date> Element

Description. This data element describes date of the contribution.

Multiplicity. The <date> element occurs 0 or 1 time within the <contribute> element.

Attributes

  • None

Elements

  • <datetime>
  • <description>

2.4 <metametadata> Element

Description. Groups information about the meta-data instance itself (rather than the learning object that this instance describes).

<metametadata> elements

 

Figure 2.3 <metametadata> elements.

Multiplicity. The <metametadata> element occurs 0 or 1 time within the top-level <lom> element.

Attributes

  • None

Elements

  • <identifier>
  • <catalogentry>
  • <contribute>
  • <metadatascheme>
  • <language>

2.4.1 <identifier> Element

Description. A globally unique label that identifies this meta-data instance. This element is no longer reserved and authors may use their own ID method or the IMS Persistent, Location-Independent Resource Identifiers Best Practice Guide, which at the time of this writing was being considered as an IMS wide base specification.

Multiplicity. The <identifier> element occurs 0 or 1 time within the <metametadata> element.

Attributes

  • None

Elements

  • None

2.4.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 instances within the <metametadata> element.

Attributes

  • None

Elements

  • <catalog>
  • <entry>

Example

<metametadata>
  <catalogentry>
    <catalog>ISBN</catalog>
    <entry>
      <langstring>0-226-10389-7</langstring>
    </entry>
  </catalogentry>
</metametadata>

2.4.2.1 <catalog> Element

Description. The name of the catalog (i.e. listing identification system).

Multiplicity. The <catalog> element must occur 1 and only 1 time within the <catalogentry> element.

Attributes

  • None

Elements

  • None

2.4.2.2 <entry> Element

Description. Actual string value of the entry within the catalog (i.e. listing identification system).

Multiplicity. The <entry> element must occur 1 and only 1 time within the <catalogentry> element.

Attributes

  • None

Elements

  • <langstring> - (The <langstring> element can be repeated 1 or more times within the <catalogentry> element. However, each langstring is required to contain a different xml:lang attribute).

2.4.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 instances within the <metametadata> element.

Attributes

  • None

Elements

  • <role>
  • <centity>
  • <date>

Example

<metametadata>
  <contribute>
    <role>
      <source>
        <langstring xml:lang="x-none">LOMv1.0</langstring>
      </source>
      <value>
        <langstring xml:lang="x-none">Creator</langstring>
      </value>
    </role>
    <centity>
      <vcard>
        begin:vcard
        fn: Joe Creator
        end:vcard
      </vcard>
    </centity>
    <date>
      <datetime>2000-12-12</datetime>
      <description>
        <langstring>Date Description</langstring>
      </description>
    </date>
  </contribute>
</metametadata>

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

Multiplicity. If the <contribute> element is used, the <role> element must occur 1 and only 1 time within the <contribute> element. If there are multiple contributors (different roles), then the <contribute> element should be repeated.

Attributes

  • None

Elements

  • <source>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • Creator
  • Validator

2.4.3.2 <centity> Element

Description. This data element is the identification of and information about people or organizations contributing to this meta-data instance, most relevant first.

Multiplicity. The <centity> element occurs 0 or more times within the <contribute> element. The smallest permitted maximum is 10 instances within the <contribute> element.

Attributes

  • None

Elements

  • <vcard>

2.4.3.3 <date> Element

Description. This data element describes date of the contribution.

Multiplicity. The <date> element occurs 0 or 1 time within the <contribute> element.

Attributes

  • None

Elements

  • <datetime>
  • <description>

2.4.4 <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 0 or more times within the <metametadata> element. The smallest permitted maximum is 10 instances within the <metametadata> element.

Attributes

  • None

Elements

  • None

Example

<metametadata>
  <metadatascheme>LOMv1.0</metadatascheme>
</metametadata>

2.4.5 <language> Element

Description. This data element describes the language of this meta-data instance. This is the default language for all LangString values in this meta-data instance.

Multiplicity. The <language> element occurs 0 or 1 time within the <metametadata> element.

Attributes

  • None

Elements

  • None

Example

<metametadata>
  <language>en</language>
</metametadata>

2.5 <technical> Element

Description. Groups the technical requirements and characteristics of the learning object.

<technical> elements

 

Figure 2.4 <technical> elements.

Multiplicity. The <technical> element occurs 0 or 1 time within the top-level <lom> element.

Attributes

  • None

Elements

  • <format>
  • <size>
  • <location>
  • <requirement>
  • <installationremarks>
  • <otherplatformrequirements>
  • <duration>

2.5.1 <format> element

Description. This data element describes the technical data type(s) of (all the components of) this learning object. This data element shall be used to identify the software needed to access the learning object.

Multiplicity. The <format> element occurs 0 or more times within the <technical> element. The smallest permitted maximum is 40 instances within the <technical> element.

Attributes

  • None

Elements

  • None

Example

<technical>
  <format>video/mpeg</format>
  <format>text/html</format>
</technical>

2.5.2 <size> element

Description. This data element describes the size of the digital learning object 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 object. If the learning object is compressed, then this data element shall refer to the uncompressed size.

Multiplicity. The <size> element occurs 0 or 1 time within the <technical> element.

Attributes

  • None

Elements

  • None

Example

<technical>
  <size>568</size>
</technical>

2.5.3 <location> element

Description. This data element is a string that is used to access this learning object. 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 object described by this meta-data instance is physically located.

Multiplicity. The <location> element occurs 0 or more times within the <technical> element. The smallest permitted maximum is 10 instances within the <technical> element.

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

Example

<technical>
  <location type="URI">http://host/id</location>
</technical>

2.5.4 <requirement> element

Description. This data element describes the technical capabilities required in order to use this learning object. 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 instances within the <technical> element.

Attributes

  • None

Elements

  • <type>
  • <name>
  • <minimumversion>
  • <maximumversion>

Example

<technical>
  <requirement>
    <type>
      <source>
        <langstring xml:lang="x-none">LOMv1.0</langstring>
      </source>
      <value>
        <langstring xml:lang="x-none">Browser</langstring>
      </value>
    </type>
    <name>
      <source>
        <langstring xml:lang="x-none">LOMv1.0</langstring>
      </source>
      <value>
        <langstring xml:lang="x-none">Microsoft Internet Explorer>/langstring>
      </value>
    </name>
    <minimumversion>4.0</minimumversion>
    <maximimversion>5.0</maximumversion>
  </requirement>
</technical>

2.5.4.1 <type> Element

Description. This data element describes the technology required to use this learning object, i.e. hardware, software, network, etc.

Multiplicity. The <type> element occurs 0 or 1 time within the <requirement> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • Operating System
  • Browser

2.5.4.2 <name> Element

Description. This data element describes name of the required technology to use this learning object. The value for this data element may be derived from the 4.4.1 Technical.Format automatically, e.g., "video/mpeg" implies "Multi-OS".

Multiplicity. The <name> element occurs 0 or 1 time within the <requirement> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

If Technical.Requirement.Type="Operating System"

  • PC-DOS
  • MS-Windows
  • MacOS
  • Unix
  • Multi-OS
  • None

If Technical.Requirement.Type="Browser"

  • Any
  • Netscape Communicator
  • Microsoft Internet Explorer
  • Opera
  • Amaya

2.5.4.3 <minimumversion> Element

Description. This data element describes the lowest possible version of the required technology to use this learning object.

Multiplicity. The <minimumversion> element occurs 0 or 1 time within the <requirement> element.

Attributes

  • None

Elements

  • None

2.5.4.4 <maximumversion> Element

Description. This data element describes the highest version of the technology known to support the use of this learning object.

Multiplicity. The <maximumversion> element occurs 0 or 1 time within the <requirement> element.

Attributes

  • None

Elements

  • None

2.5.5 <installationremarks> Element

Description. This data element contains the description of how to install this learning object.

Multiplicity. The <installationremarks> element occurs 0 or 1 time within the <technical> element.

Attributes

  • None

Elements

  • <langstring> - (The <langstring> element can be repeated 1 or more times within the <installationremarks> element. However, each langstring is required to contain a different xml:lang attribute).

Example

<technical>
  <installationremarks>
    <langstring>Installation remakes placed here</langstring>
  </installationremarks>
</technical>

2.5.6 <otherplatformrequirements> Element

Description. This data element contains information about other software and hardware requirements.

Multiplicity. The <otherplatformrequirements> element occurs 0 or 1 time within the <technical> element.

Attributes

  • None

Elements

  • <langstring> - (The <langstring> element can be repeated 1 or more times within the <otherplatformrequirements> element. However, each langstring is required to contain a different xml:lang attribute).

Example

<technical>
  <otherplatformrequirements>
    <langstring>Other platform requirements placed here</langstring>
  </otherplatformrequirements>
</technical>

2.5.7 <duration> Element

Description. This data element the time a continuous learning object takes when played at the intended speed. This data element is especially useful for sounds, movies or animations.

Multiplicity. The <duration> element occurs 0 or 1 time within the <technical> element.

Attributes

  • None

Elements

  • <datetime>
  • <description>

Example

<technical>
  <duration>
    <datetime>00:00:15</datetime>
    <description>
      <langstring>Length of time to play the simulation</langstring>
    </description>
  </duration>
</technical>

2.6 <educational> Element

Description. Conditions of use of the resource.

<educational> elements

 

Figure 2.5 <educational> elements.

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>

2.6.1 <interactivitytype> Element

Description. The type of interactivity supported by the learning object.

Multiplicity. The <interactivitytype> element occurs 0 or 1 time within the <educational> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • Active
  • Expositive
  • Mixed
  • Undefined

Example

<educational>
  <interactivitytype>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">Active</langstring>
    </value>
  </interactivitytype>
</educational>

2.6.2 <learningresourcetype> Element

Description. Specific kind of resource, most dominant kind first.

Multiplicity. The <learningresourcetype> element occurs 0 or more times within the <educational> element. The smallest permitted maximum is 10 instances within the <educational> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • Exercise
  • Simulation
  • Questionnaire
  • Diagram
  • Figure
  • Graph
  • Index
  • Slide
  • Table
  • Narrative Text
  • Exam
  • Experiment
  • ProblemStatement
  • SelfAssesment

Example

<educational>
  <learningresourcetype>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">Simulation</langstring>
    </value>
  </learningresourcetype>
</educational>

2.6.3 <interactivitylevel> Element

Description. Level of interactivity between an end user and the learning object.

Multiplicity. The <interactivitylevel> element occurs 0 or 1 time within the <educational> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • very low
  • low
  • medium
  • high
  • very high

Example

<educational>
  <interactivitylevel>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">very high</langstring>
    </value>
  </interactivitylevel>
</educational>

2.6.4 <semanticdensity> Element

Description. Subjective measure of the learning object's usefulness as.compared to its size or duration.

Multiplicity. The <semanticdensity> element occurs 0 or 1 time within the <educational> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • very low
  • low
  • medium
  • high
  • very high

Example

<educational>
  <semanticdensity>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">very high</langstring>
    </value>
  </semanticdensity>
</educational>

2.6.5 <intendedenduserrole> Element

Description. Normal user of the learning object, most dominant first.

Multiplicity. The <intendedenduserrole> element occurs 0 or more times within the <educational> element. The smallest permitted maximum is 10 instances within the <educational> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • Teacher
  • Author
  • Learner
  • Manager

Example

<educational>
  <intendedenduserrole>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">Learner</langstring>
    </value>
  </intendedenduserrole>
</educational>

2.6.6 <context> Element

Description. The typical learning environment where use of learning object is intended to take place.

Multiplicity. The <context> element occurs 0 or more times within the <educational> element. The smallest permitted maximum is 10 instances within the <educational> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • Primary Education
  • Secondary Education
  • Higher Education
  • University First Cycle
  • University Second Cycle
  • University Postgrade
  • Technical School First Cycle
  • Technical School Second Cycle
  • Professional Formation
  • Continuous Formation
  • Vocational Training

Example

<educational>
  <context>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">University Postgrade</langstring>
    </value>
  </context>
</educational>

2.6.7 <typicalagerange> Element

Description. 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 instances within the <educational> element.

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

Example

<educational>
  <typicalagerange>
    <langstring xml:lang="en">adult pilot with 3 years experience</langstring>
  </typicalagerange>
</educational>

2.6.8 <difficulty> Element

Description. How hard it is to work through the learning object for the typical target audience.

Multiplicity. The <difficulty> element occurs 0 or 1 time within the <educational> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • very easy
  • easy
  • medium
  • difficult
  • very difficult

Example

<educational>
  <difficulty>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">medium</langstring>
    </value>
  </difficulty>
</educational>

2.6.9 <typicallearningtime> Element

Description. Approximate or typical time it takes to work with the resource.

Multiplicity. The <typicallearningtime> element occurs 0 or 1 time within the <educational> element.

Attributes

  • None

Elements

  • <datetime>
  • <description>

Example

<educational>
  <typicallearningtime>
    <datetime>01:30:00</datetime>
  </typicallearningtime>
</educational>

2.6.10 <description> Element

Description. Comments on how the learning object is to be used.

Multiplicity. The <description> element occurs 0 or 1 time within the <educational> element.

Attributes

  • None

Elements

  • <langstring> - (The <langstring> element can be repeated 1 or more times within the <description> element. However, each langstring is required to contain a different xml:lang attribute).

Example

<educational>
  <description>
    <langstring>Used for training on in-flight refueling</langstring>
  </description>
</educational>

2.6.11 <language> Element

Description. User's natural language.

Multiplicity. The <language> element occurs 0 or more times within the <educational> element. The smallest permitted maximum is 10 instances within the <educational> element.

Attributes

  • None

Elements

  • None

Example

<educational>
  <language>en</language>
</educational>

2.7 <rights> Element

Description. Conditions of use of the resource.

<rights> elements

 

Figure 2.6 <rights> elements.

Multiplicity. The <rights> element occurs 0 or 1 time within the top-level <lom> element.

Attributes

  • None

Elements

  • <cost>
  • <copyrightandotherrestrictions>
  • <description>

2.7.1 <cost> Element

Description. Whether use of the resource requires payment.

Multiplicity. The <cost> element occurs 0 or 1 time within the <rights> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

Example

<rights>
  <cost>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">no</langstring>
    </value>
  </cost>
</rights

2.7.2 <copyrightandotherrestrictions> Element

Description. Whether copyright or other restrictions apply.

Multiplicity. The <copyrightandotherrestrictions> element occurs 0 or 1 time within the <rights> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

Example

<rights>
  <copyrightandotherrestrictions>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">no</langstring>
    </value>
  </copyrightandotherrestrictions>
</rights>

2.7.3 <description> Element

Description. Comments on the conditions of use of the resource.

Multiplicity. The <description> element occurs 0 or 1 time within the <rights> element.

Attributes

  • None

Elements

  • <langstring> - (The <langstring> element can be repeated 1 or more times within the <description> element. However, each langstring is required to contain a different xml:lang attribute).

Example

<rights>
  <description>
    <langstring xml:lang="en">LOMv1.0</langstring>
  </description>
</rights

2.8 <relation> Element

Description. Features of the resource in relationship to other learning objects.

<relation> elements

 

Figure 2.7 <relation> elements.

Multiplicity. The <relation> element occurs 0 or more times within the top-level <lom> element. The smallest permitted maximum is 100 instances.

Attributes

  • None

Elements

  • <kind>
  • <resource>

2.8.1 <kind> Element

Description. Nature of the relationship between the resource being described and the one identified by 7.2 relation/resource.

Multiplicity. The <kind> element occurs 0 or 1 time within the <resource> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • IsPartOf
  • HasPart
  • IsVersionOf
  • HasVersion
  • IsFormatOf
  • HasFormat
  • References
  • IsReferencedBy
  • IsBasedOn
  • IsBasisFor
  • Requires
  • IsRequiredBy

Example

<relation>
  <kind>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">Requires</langstring>
    </value>
  </kind>
  <resource>
    <description>
      <langstring>Description of resource</langstring>
    </description>
  </resource>
  <catalogentry>
    <catalog>ISBN</catalog>
      <entry>
        <langstring>0-226-10389-7</langstring>
      </entry>
    </catalog>
  </catalogentry>
</relation>

2.8.2 <resource> Element

Description. The target learning object that this relationship references.

Multiplicity. The <resource> element occurs 0 or 1 time within the <relation> element.

Attributes

  • None

Elements

  • <identifier>
  • <description>

2.8.2.1 <identifier> Element

Description. Unique identifier of the other resource.

Multiplicity. The <identifier> element occurs 0 or 1 time within the <resource> element.

Attributes

  • None

Elements

  • None

2.8.2.2 <description> Element

Description. Description of 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).

2.8.2.3 <catalogentry> Element

Description. Reference to the other resource.

Multiplicity. The <catalogentry> element occurs 0 or more times within the <resource> element. The smallest permitted maximum is 10 instances within the <resource> element.

Attributes

  • None

Elements

  • <catalog>
  • <entry>

2.8.2.3.1 <catalog> Element

Description. Source of the following string value.

Multiplicity. The <catalog> element occurs 1 and only 1 time within the <catalogentry> element.

Attributes

  • None

Elements

  • None

2.8.2.3.2 <entry> Element

Description. Actual catalog value.

Multiplicity. The <entry> element occurs 1 and only 1 time within the <catalogentry> element.

Attributes

  • None

Elements

  • <langstring> - (The <langstring> element can be repeated 1 or more times within the <catalogentry> element. However, each langstring is required to contain a different xml:lang attribute).

2.9 <annotation> Element

Description. Comments on the educational use of the learning object.

<annotation> elements

 

Figure 2.8 <annotation> elements.

Multiplicity. The <annotation> element occurs 0 or more times within the top-level <lom> element. The smallest permitted maximum is 30 instances.

Attributes

  • None

Elements

  • <person>
  • <date>
  • <description>

2.9.1 <person> Element

Description. Comments on the educational use of the learning object

Multiplicity. The <person> element occurs 0 or 1 time within the <annotation> element.

Attributes

  • None

Elements

  • <vcard>

Example

<annotation>
  <person>
    <vcard>
      begin:vcard
      org: IMS
      end:vcard
    </vcard>
  </person>
</annotation>

2.9.2 <date> Element

Description. Date that this annotation was created.

Multiplicity. The <date> element occurs 0 or 1 time within the <annotation> element.

Attributes

  • None

Elements

  • <datetime>
  • <description>

Example

<annotation>
  <date>
    <datetime>2001-04-17</datetime>
  </date>
</annotation>

2.9.3 <description> Element

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

Example

<annotation>
  <description>
    <langstring xml:lang="en">
      This simulation can be used in conjunction with the in-flight refueling course
    </langstring>
  </description>
</annotation>

2.10 <classification> Element

Description. Description of a characteristic of the resource by entries in classifications.

<classification> elements

 

Figure 2.9 <classification> elements.

Multiplicity. The <classification> element occurs 0 or more times within the top-level <lom> element. The smallest permitted maximum is 40 instances.

Attributes

  • None

Elements

  • <purpose>
  • <taxonpath>
  • <description>
  • <keyword>

2.10.1 <purpose> Element

Description. Characteristics of the resource described by this classification entry.

Multiplicity. The <purpose> element occurs 0 or 1 time within the <classification> element.

Attributes

  • None

Elements

  • <source>
  • <value>

LOM Defined Vocabularies (<source> element set to LOMv1.0)

  • Discipline
  • Idea
  • Prerequisite
  • Educational Objective
  • Accessibility Restrictions
  • Educational Level
  • Skill Level
  • Security Level

Example

<classification>
  <purpose>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">Educational Objective</langstring>
    </value>
  </purpose>
</classification>

2.10.2 <taxonpath> Element

Description. A taxonomic path in a specific classification

Multiplicity. The <taxonpath> element occurs 0 or more times within the <classification> element. The smallest permitted maximum is 15 instances within the <classification> element.

Attributes

  • None

Elements

  • <source>
  • <taxon>

Example

<classification>
  <taxonpath>
    <source>
      <langstring>DDC</langstring>
    <source>
  </taxonpath>
</classification>

2.10.2.1 <source> Element

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

2.10.2.2 <taxon> Element

Description. An entry in a classification. A hierarchical nesting of taxons creates a taxonomic path: this is a path from a more general to a more specific entry in a classification.

Multiplicity. The <taxon> element occurs 0 or 1 time within the <taxonpath> element. If the <taxonpath> element is used, the <taxon> element must occur 1 and only 1 time with the <taxonpath> element. The smallest permitted maximum is 15 instances within the <taxonpath> element.

Attributes

  • None

Elements

  • <id>
  • <entry>
  • <taxon>

Example

<classification>
  <taxonpath>
    <source>
      <langstring xml:lang="en">A great taxonomic source.</langstring>
    </source>
    <taxon>
      <entry>
        <langstring xml:lang="en">Information Science</langstring>
      </entry>
      <taxon>
        <entry>
          <langstring xml:lang="en">Information Processing</langstring>
        </entry>
        <taxon>
          <entry>
            <langstring xml:lang="en">Metadata</langstring>
          </entry>
        </taxon>
      </taxon>
    </taxon>
  </taxonpath>
</classification>

2.10.2.2.1 <id> Element

Description. A specific classification. Any recognized "official" taxonomy.

Multiplicity. The <id> element occurs 0 or 1 time within the <taxon> element.

Attributes

  • None

Elements

  • None

2.10.2.2.2 <entry> Element

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

2.10.3 <description> Element

Description. A textual description of the learning object relative to its stated purpose.

Multiplicity. The <description> element occurs 0 or 1 time within the <classification> element.

Attributes

  • None

Elements

  • <langstring> - (The <langstring> element can be repeated 1 or more times within the <description> element. However, each langstring is required to contain a different xml:lang attribute).

Example

<classification>
  <description>
    <langstring xml:lang="en">Electronic, computer generated simulation</langstring>
  </description>
</classification>

2.10.4 <keyword> Element

Description. A collection of keywords or phrases describing the learning objective relative to its stated purpose. The smallest permitted maximum is 40 instances within the <classification> element.

Multiplicity. The <keyword> element occurs 0 or more times within the <classification> element.

Attributes

  • None

Elements

  • <langstring> - (The <langstring> element can be repeated 1 or more times within the <keyword> element. However, each langstring is required to contain a different xml:lang attribute).

Example

<classification>
  <keyword>
    <langstring xml:lang="en">simulation</langstring>
  </keyword>
</classification>

3. Elements Used Globally

3.1 LangString Binding

Description. Phrase in a human language.

<langstring> attribute

 

Figure 3.1 <langstring> attribute.

Multiplicity. The smallest permitted maximum is 10 instances.

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

  • <langstring>

Example

<classification>
  <keyword>
    <langstring xml:lang="en">simulation</langstring>
  </keyword>
</classification>

3.2 Date Binding

Description. Defines the structure of a Date Type.

<date> elements

 

Figure 3.2 <date> elements.

Multiplicity. Varies - see parent element.

Attributes

  • None

Elements

  • <datetime>
  • <description>

Example

<datetime>00:00:20</datetime>
<description>
  <langstring>Description of Date</langstring>
</description>

3.2.1 <datetime> Element

Description. Date expressed as per ISO 8601 standard.

Multiplicity. The <datetime> element occurs 0 or 1 time within its parent element.

Attributes

  • None

Elements

  • None

3.2.2 <description> Element

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

3.3 Vocabulary Binding

Description. Defines the vocabulary structure. A Vocabulary datatype is made of two elements: <source> describes the source of the vocabulary (i.e., LOMv1.0), <value> describes the actual vocabulary term.

Multiplicity. Varies - see parent element.

Attributes

  • None

Elements

  • <source>
  • <value>

Example

<status>
  <source>
    <langstring xml:lang="x-none">LOMv1.0</langstring>
  </source>
  <value>
    <langstring xml:lang="x-none">Final</langstring>
  </value>
</status>

3.3.1 <source> Element

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

3.3.2 <value> Element

Description. Defines the vocabulary structure.

Multiplicity. The <value> element occurs 0 or 1 time within its parent element.

Attributes

  • None

Elements

  • <langstring>

3.4 Vcard Binding

Description. The vCard specification defines a "virtual" electronic business card. vCards can store information such as your name, address, telephone number, email address, and so on.

Multiplicity. Varies - see parent element.

Attributes

  • None

Elements

  • None

Example

<vcard>
  begin:vcard
  fn:Joe Student
  addr:1111 Elm Street
  end:vcard
</vcard>

4. Special Handling Requirements for Meta-Data Elements

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 discussed in greater detail below.

4.1 Type Structures

These structures have the suffix of "TYPE". Interactivitytype is not a common structure, even though it ends in "TYPE". The types defined in the LOM and encoded in the XML are:

  • LangStringType
  • DateType
  • VocabularyType

4.1.1 LangStringType

LangStringType denotes a string that is encoded for a specific language or other interpretable type. It is of the logical form:

LangStringType
  langstring
    language
    string

It is important to note how the logical form specified by the IEEE LOM appears to be different from the XML binding suggested in this document. In the suggested binding of this document, LangStringType is not an XML element. Rather <langstring> is an element with an "xml:lang" attribute which is used to define the language of a string value:

<langstring xml:lang="en">string value</langstring>

The "xml:lang" attribute can contain both language and country codes as defined in the W3C XML Specification. Any element that contains a <langstring> element may contain multiple langstring elements with each one representing a different language

Note: Each <langstring> within an element is considered to contain the same information, differing by language.

The W3C XML 1.0 Specification also allows the "xml:lang" attribute to be assigned an arbitrary value that is agreed upon by parties in private use. These attributes are identified by the prefix "x-" or "X-". In general, this practice is strongly discouraged for IMS meta-data instances; however, IMS has assigned a value of "x-none" to the "xml:lang" attribute when used to list vocabulary items using the subelements <source> and <value>. See the following example for an illustration of this.

<educational>
  <learningresourcetype>
    <source>
      <langstring xml:lang="x-none">LOMv1.0</langstring>
    </source>
    <value>
      <langstring xml:lang="x-none">Simulation</langstring>
    </value>
  </learningresourcetype>
</educational>

4.1.2 DateType

DateType is a formatted date. There are two subelements representing the two different date formats used. Precise date and time information are formatted according to the ISO8601 Specification. Point in time and time duration information are captured in the <datetime> element. More general date and time information is captured using the <description> element. A DateType may contain values for both a DateTime and Description.

DateType has the logical structure of:

DateType
  datetime
  description
    LangStringType

It is important to note that, just as with the LangStringType, the logical form specified by the IEEE LOM for DateType appears to be different from the XML Binding suggested in this document. In this binding, DateType is not an XML element. Rather <date> is an element with two subelements: <datetime> and <description>.

The <datetime> element makes use of the format dictated by the ISO8601 Specification Dates are captured using the CCYY-MM-DD form while Time elements are specified as hh:mm:ss. There is also the ability to specify Time Zone Determination information by adding "+hh:mm" to indicate differences in time zones. Both the date and time value are combined using the capital "T" character to separate them. Three examples of this are found below:

Note: Use <datetime> for precise dates and times. Use <description> for more general date time information.

<datetime>1999-07-26<datetime> 
<datetime>1999-07-26T12:15:35<datetime> 
<datetime>1999-07-26T12:15:35+01:00<datetime> 

There is a version of the ISO8601 Specification that is available through the W3C which also specifies how a date range is represented and how date and time duration is accurately represented. Readers may refer to the ISO8601 Specification available at: http://www.w3.org/TR/NOTE-datetime for more detailed information on the usage of date and time values.

4.1.3 VocabularyType

VocabularyTypes are defined for certain meta-data elements. A vocabulary is a recommended list of predefined values appropriate for that element. There are two subelements used to describe the vocabulary. The <source> element is used to indicate the source of the vocabulary value. If implementers use "LOMv1.0", the value comes from the LOM defined vocabulary list for that element, if they use anything else, such as a URI as the <source>, the value is not contained in the LOM vocabulary. The <value> element lists the actual value from the vocabulary list.

Implementers may use other values, not present in a particular vocabulary list, but to maintain the highest degree of semantic interoperability, it is recommended that LOM vocabulary values be used whenever possible.

VocabularyType has the logical structure of:

VocabularyType
  source
    langstring
  value
    langstring

To ensure that vocabulary items are treated as tokens and are not translated or transliterated into another natural language, IMS recommends that implementers use "x-none" as the xml:lang attribute value of the <langstring> element. Following is an example implementation of the VocabularyType:

<aggregationlevel>
  <source>
    <langstring xml:lang="x-none">LOMv1.0</langstring>
  </source>
  <value>
    <langstring xml:lang="x-none">2</langstring>
  </value>
</aggregationlevel>

4.2 Language Elements

Meta-data authors may specify a language that will be used as the default language for any <langstring> elements that are encountered. This is done by providing a value for the <langstring> element that is contained by the <metametadata> element. Each individual occurrence of <langstring> may override this default value by declaring a language and country code using the "xml:lang" attribute.

Note: The default language for an instance can be specified in the <metametadata> category. Use individual <langstring> elements to override the default language.

4.3 TaxonPath Elements

In most cases, the value of using the <taxonpath> element lies in the ability to locate the source of the taxonomy. If the <source> for a <taxonpath> is not provided or doesn't map to an existing, logical source then the element should contain something useful regarding how to locate information about the taxonomy.

Note: Always try to provide a <source> element when using the <taxonpath> element.

4.4 vCard Elements

There are at least two elements in the IEEE LOM that require contributing entity information: elements lifecycle.contribute.entity and metametadata.contribute.entity. Both elements specify the vCard specification as the source for representing their data.

The formatted name or "FN" element from the vCard Specification should contain the name of the individual contributing to the learning resource of metameta-data of the resource. If a company, rather than an individual, contributed to the resource or resource metameta-data, the organization or "ORG" element from the vCard Specification should be used. This is illustrated below:

<centity>
<vcard>
  BEGIN:vCard
  FN:Lotta Data
  END:vCard
</centity>

As far as most XML parsers are concerned, the information between the <vcard> and </vcard> tags is just a bunch of text. It is up to meta-data implementers to individually determine how they will process vCard information. The vCard Specification allows for a rich set of information to be captured as the example below illustrates. The reader is directed to the "Using the vCard Specification" section of this document and the vCard Specification itself for more details regarding its use.

4.5 Keyword Elements

The elements general.keyword and classification.keyword are found in the IMS meta-data set. It is expected that the keywords describing a learning resource are likely to be provided in multiple languages. To accommodate this, the IMS XML binding suggests that keywords and short, keyword phrases be represented as separate langstring elements rather than a comma-delimited text string as in the example below:

Note: Use multiple <keyword> elements to represent multiple keywords and keyword phrases. Use multiple <langstring> elements to represent the semantic equivalences of the same keywords or keyword phrases in different languages.

<keyword>
  <langstring xml:lang="en">metadata</langstring>
  <langstring xml:lang="nl">metadata</langstring>
  <langstring xml:lang="fr">metadonnees</langstring>
</keyword>
<keyword>
  <langstring xml:lang="en">learning object</langstring>
  <langstring xml:lang="nl">leerobject</langstring>
  <langstring xml:lang="fr">objet d'apprentissage</langstring>
</keyword>

5. Extensibility

Some meta-data providers may find the element set defined in the IMS meta-data too restrictive to meet all of their meta-data needs. To ensure meta-data extensibility, the IEEE LOM Draft Standard requires that there be no limit on potential extensions to meta-data, as long as the integrity of the specified meta-data is not impaired. An extension is the addition of information to an existing meta-data XML structure. There are two general ways to extend IMS meta-data:

  1. One or more elements may be added to the structure using elements defined in the IEEE LOM Draft Standard.
  2. One or more elements may be added to the structure using namespaced elements.

These two types of extension are defined as:

  1. Use of elements from the LOM: The LOM Standard contains some elements with definitions that are not specific for any particular context. The context in which an element is placed provides specificity for its definition. These elements may be reused as long as the definition is not changed.
  2. Use of namespaced elements: New elements may be introduced and used to extend the structure.

The IMS Learning Resource Meta-Data XML Binding Specification defines a manner for treating all user-defined, proprietary extensions in a uniform manner. The mechanism is different according to the control file (DTD,XSD,XDR) that is chosen for development of the meta-data instance. Any uses or proposed uses of extensions should be brought to the attention of the IMS Meta-Data Working Group (md-question@imsglobal.org).

5.1 Extensions with DTDs

The XML DTD defines the extension element as the element used for indicating where a set of extension elements can be found in the meta-data structure. In the IMS DTD file the extension elements exists in every element's content model allowing every element to contain one or more extension elements. The only elements without an extension capability are those elements in the Information Model that contain the vocabulary data type.

The use of the <extension> element is illustrated as follows:

<coverage>
  <langstring>1880-1900</langstring>
  <extension>
    <role>Date Range</role>
  </extension>
</coverage>

5.2 Extensions with XML Schema Definition Language

The XML Schema Definition language (XSD, XDR) binding does not inhibit either of the types of meta-data extensions defined above. Developers can use other LOM elements as an extension or as new elements (defined in a specific namespace), and may be introduced to extend the meta-data. Namespace elements typically contain a meaningful prefix, such as "adl" (to represent the Advanced Distributed Learning initiative) to uniquely identify its extensions. The use of the LOM elements as extensions to other LOM elements is illustrated as follows:

<coverage>
  <langstring>1880-1900</langstring>
  <role>Date Range</role>
</coverage>

The use of the namespace extension element is illustrated as follows:

<context>
  <langstring xml:lang="en">Military Training</langstring>
  <adl:type>
    <title>Roman military tactics</title>
      <langstring xml:lan="en">This example discusses how the Romans defined many aspects of modern warfare.</langstring>
  </adl:type>
</context>

6. Using the vCard Specification

The IMS XML Binding uses the vCard Specification wherever the <entity> element is defined. An <entity>, as far as IMS meta-data is concerned, represents a person or organization. The IMS Binding uses the clear text form of the vCard Specification. The vCard Specification defines the clear text form as a "Simplegram". This is not intended as a complete description of the vCard coding; it is intended to provide some guidelines for simple cases. The vCard Specification is located at http://www.imc.org/pdi/.

The vCard Specification defines a set of properties that contain the information about an <entity>. The default character set encoding for the vCard is 7-bit US-ASCII. The default character set can be overridden for an individual property using the "CHARSET" property parameter. For example, the ISO 8859-8 or Latin/Hebrew character set used in an address is specified by:

ADR;CHARSET=ISO-8859-8:...

It is also possible to set the encoding for the entire instance to another encoding. See the vCard Specification for further instructions. The default language is "en-US", which may similarly be overridden for a property using the "language" property parameter. Property names are case insensitive.

The general form of the Simplegram vCard encoding is:

BEGIN:vcard
Items
END:vcard

Items is a list of items separated by a any valid line ending protocol. For example, in 7-bit ASCII, the Carriage Return (CR) character (ASCII decimal 13), the Line Feed character (LF) (ASCII decimal 10), the Carriage Return character followed by a Line Feed character (CRLF), or the Property Delimiter are line ending protocols. Property parameter substrings are delimited by the Field Delimiter, specified by the Semi-Colon (;) character (ASCII decimal 59). Each item is of the general form:

name:value A;value B CRLF 

An example of an item with no substrings is the formatted name property, FN. FN is the full formatted name of a person:

FN:Mr. James Q. Smith, Jr. 

Some items may have multiple properties or parameter substrings. For example, a person's name, N, can contain a Family Name, a Given Name, an Other Names, Prefix and a Suffix. The property value is a concatenation of the Family Name (first field), Given Name (second field), Additional Names (third field), Name Prefix (fourth field), and Name Suffix (fifth field) strings separated by the Field Delimiter ";".

N:Smith;James;Q.;Mr.;Jr 

An unused substring, if not at the end of the list of substrings, is represented with a semicolon only:

N:Smith;James;Q.;;Jr 

Vcards may be organized to contain groups. The grouping of a comment property with a telephone property is shown in the following example:

A.TEL;Home:+1-213-555-1234 
A.NOTE:This is my vacation home. 

Below are some commonly used vCard properties, with substrings. Separate lines should not be used for field substrings, but are used here for clarity:

Formatted Name:

FN:Text Value 

Example:

FN:Dr. Thomas D. Wason, Sr. 

Name:

N:Family (Sur) Name; 
First (Given) Name; 
Other Names; 
Prefix; 
Suffix CRLF 

Example:

N:Wason;Thomas;D.;Dr.;Sr

Address:

The property value is a concatenation of the Post Office Address (first field), Extended Address (second field), Street (third field), Locality (fourth field, e.g., City), Region (fifth field, e.g., State), Postal (Zip) Code (six field), and Country (seventh field) strings:

ADR:P.O.Box; 
: Extended Address 
Street; 
Locality; 
Region; 
Postal Code; 
Country CRLF

Example:

ADR:;IMS Project;1421 Park Drive;Raleigh;North Carolina;27605-1727;United States of America 

Address Delivery Label:

LABEL: Text

Example:

LABEL;QUOTED-PRINTABLE:IMS Project=0A= 
1421 Park Drive=0A= 
Raleigh, NC 27605-1727=0A=

Note the use of the escaped line feed (=0A=). The property parameters are preceded by a semicolon (;) after the property name. They are optional, defining the uses of the Delivery Label.

Organization:

The property value is a concatenation of the Organization Name (first field), Organizational Unit (second field) strings. Additional positional fields, if specified, contain additional Organizational Units:

ORG:Organization Name; 
  Organizational Unit[; 
  Organizational Unit] CRLF 

Example:

ORG:IMS Project;Meta Data Team
Electronic Mail: 
EMAIL; Electronic Mail Type:email 

Example:

EMAIL;INTERNET:twason@imsproject.org

Telephone:

TEL:telephone number

Example:

TEL:+1 919.839.8187 

All of these previously described properties are included in the following example:

BEGIN:VCARD 
N:Wason;Thomas;D.;Dr.;Sr. 
FN:Thomas D. Wason, Ph.D. 
ORG:IMS Project;Meta Data Team 
ADR:;IMS Project;1421 Park Drive;Raleigh;North Carolina;27605-1727;United States of America 
TEL:+1 919.839.8187 
EMAIL;INTERNET:twason@imsproject.org 
LABEL;QUOTED-PRINTABLE:IMS Project=0A= 
1421 Park Drive=0A= 
Raleigh, NC 27605-1727=0A= 
USA 
END:VCARD

Appendix A - IMS Meta-Data RDF Binding

This is a binding guide for representing IMS Learning Resource Meta-Data v1.2 in RDF. For each element in the IMS Meta-Data Information Model v1.2 this Appendix provides the preferred representation in RDF, with examples. This appendix is a working draft that is subject to change, and should not be considered final. There are sample RDF instances that use the constructs described below, as well as other documents containing the language definitions, the local vocabulary and taxonomy, and the set of RDF schemas, available for download on the IMS Meta-Data website: http://www.imsglobal.org/metadata.

The information presented here is not completely self-contained, but rather depends on understanding several separate specifications. In particular, this RDF binding depends on:

Each of these should be regarded as a prerequisite for using and implementing this binding.

A.1 Using RDF for Meta-Data as Compared to Pure XML

It is important to realize that an RDF binding can be done in a number of fundamentally different ways. This has to do with the semantic richness of RDF. In addition, in a pure XML approach such as the IMS Meta-Data XML Binding of LOM, the structure of the XML instance is the result of choosing the most convenient syntax, creating the element hierarchy that best matches the structure of the data.

By contrast, in RDF the precise data model is not simply syntactic, but has semantic consequences. RDF is a highly object-oriented approach where objects have properties that relate them to other objects. The type of an object or property defines its interpretation, and is thus not simply a syntactic placeholder. In addition, while in the pure XML version of the IMS Binding, each structure is represented by an element. In RDF there are several different possibilities, where you can use properties, resources, or even namespaces to get the structure you want. And the choice matters, as those constructs have fundamentally different semantics.

Thus, a considerable amount of effort is needed to extract the desired semantic quality of each element in order to be able to represent it appropriately. If this reinterpretation is not done, you risk losing not only clarity for the human consumer, but you risk more serious damage to the usefulness of the model. Much of the effort that has gone into this binding has focused on creating such a well-formed semantics of the model.

A.2 Design Criteria for RDF Binding

Creating an RDF binding is very different from creating an IMS Meta-Data XML binding, so formulating a more precise design criteria is necessary.

As a consequence of the nature of RDF, we cannot expect the RDF binding to fulfill the same purpose as the XML binding. The XML Binding defines an exchange format for meta-data. The meta-data might be contained in a database and an XML representation generated on demand, for export to other tools and environments. Thus, an XML meta-data record is a self-contained entity with a well-defined structure.

In contrast, an RDF representation is more often than not the definite representation of the meta-data. In addition, the meta-data is not all self-contained, but rather part of a global network of information, where anyone has the capability of adding meta-data to any resource. It is also not the case that meta-data for one resource need be contained in a single RDF document. Translations might be administrated separately, and different categories of meta-data might be separated. This dramatically strengthens the incentive both to reuse identical structures that are used repeatedly, as well as to create decentralized descriptions of resources. Both of these phenomena naturally lead to a fundamentally different approach to meta-data modelling than that found in the XML binding.

Thus, we expect to see much richer structures on many levels in an RDF representation than in the corresponding XML binding instance. In this perspective, we should expect to find that meta-data expressed in RDF using this binding probably can be exported to XML format without many problems; however, an XML meta-data record cannot be effortlessly translated to RDF.

Another aspect is that of compatibility. In XML, there is seldom a natural way to reuse other meta-data standards. By contrast, RDF is designed in a way that leads to naturally reuseable constructs. So, as can be seen in more detail below, this binding is directly compatible with Dublin Core and with vCard. However, this compatibly comes at the price of modeling freedom - some modeling restrictions are imposed on us. Fortunately, much of this compatibility comes for free when taking the approach that the data should be modeled to maximally exploit the expressivity of RDF.

Finally, as RDF is intended to be processed by software, and in many cases software with no explicit knowledge of LOM, it is important to use explicit data typing. This will be seen below in the representation of languages and dates. We have tried to avoid using string literals with only implicit typing. Thus, the purpose of this binding is to define a set of RDF constructs that facilitates introduction of LOM meta-data into the semantic web in the most convenient way.

A.3 Relationship to Other Standards

The RDF representation given here relies heavily on the Dublin Core meta-data element set, and its representation in RDF. We try to model IMS elements similarly to how the Dublin Core qualifiers are represented. The Dublin Core RDF usage model is taken from the latest DC-Architecture RDF draft. Understanding that work is helpful when trying to understand what is being described in this document.

A.3.1 Dublin Core

This appendix is aligned with the efforts to improve interoperability between Dublin Core and LOM. The RDF representation presented here is almost fully Dublin Core RDF compatible, in the sense that meta-data constructed according to this guide can be directly understood by Dublin Core-aware software. All the elements of the LOM Dublin Core mapping (in Appendix B of LOM WD 6.1) are compatibly represented, thus allowing the use of all the Dublin Core constructs in a compatible way. It is, however, at this time not possible to map any Dublin Core construct (made without reference to this guide) to a LOM element without some effort, as the LOM requires a more detailed structure in many elements. In short, this guide describes some restrictions to Dublin Core meta-data that are needed to be LOM compatible. The guiding principle has been that using the "dumb-down" algorithm described in Dublin Core Qualifiers draft (http://www.mathematik.uni-osnabrueck.de/projects/dcqual/qual21.3.1/) should result in correct Dublin Core meta-data.

Please note that the Dublin Core Qualifiers work referred to above has not yet reached its final version, so some constructs described here might change.

A.3.2 LOM/IMS XML

The Dublin Core compatibility is reached at the cost of full IMS XML binding compatibility, which is doomed to be lost anyway when using RDF. Close attention has been paid to LOM, and no structure representable in LOM should be problematic to represent in the RDF binding. But there are some differences from the IMS XML binding in structure, naming, and representation.

A.3.3 vCard

This binding also makes use of the vCard RDF binding by the W3C (http://www.w3.org/TR/vcard-rdf).

A.4 Guidelines to Specific Constructs

A.4.1. Namespaces

Five external namespaces are used below.

  • rdf: which is the RDF namespace "http://www.w3.org/1999/02/22-rdf-syntax-ns#".
  • rdfs: which is the RDF Schema namespace "http://www.w3.org/2000/01/rdf-schema#".
  • dc: which is the Dublin Core Element Set namespace "http://purl.org/dc/elements/1.1/".
  • dcq: which is the Dublin Core Qualifiers namespace "http://dublincore.org/2000/03/13/dcq#".
  • vCard: which is the VCard namespace, "http://www.w3.org/2001/vcard-rdf/3.0#".

In addition, this binding is separated into a number of namespaces. Each LOM category has its own namespace, and in addition there is a root namespace containing common constructs. The following abbreviations are used:

  • lom: which is the IMS base meta-data namespace "http://www.imsproject.org/rdf/imsmd_rootv1p2#".
  • lom_gen: which is the IMS general meta-data namespace "http://www.imsproject.org/rdf/imsmd_generalv1p2#".
  • lom_life: which is the IMS life cycle meta-data namespace "http://www.imsproject.org/rdf/imsmd_lifecyclev1p2#".
  • lom_meta: which is the IMS meta-meta-data namespace "http://www.imsproject.org/rdf/imsmd_metametadatav1p2#".
  • lom_tech: which is the IMS technical meta-data namespace "http://www.imsproject.org/rdf/imsmd_technicalv1p2#".
  • lom_edu: which is the IMS educational meta-data namespace "http://www.imsproject.org/rdf/imsmd_educationalv1p2#".
  • lom_rights: which is the IMS rights meta-data namespace "http://www.imsproject.org/rdf/imsmd_rightsv1p2#".
  • lom_rel: which is the IMS relation meta-data namespace "http://www.imsproject.org/rdf/imsmd_relationv1p2#".
  • lom_ann: which is the IMS annotation meta-data namespace "http://www.imsproject.org/rdf/imsmd_annotationv1p2#".
  • lom_cls: which is the IMS classification meta-data namespace "http://www.imsproject.org/rdf/imsmd_classificationv1p2#".

In addition, the namespace myVoc is used when referring to any resource that can be defined by users and implementers. It uses the URI "http://www.myVocabulary.com/someVocab#".

A.4.2 rdf:value and Other Constructs

In this binding, we make heavy use of the rdf:value construct. This construct is a standard way to add qualifying information to RDF statements. Its use is compatible with Dublin Core Qualifiers draft, where it is also described in some detail. In short, this construct is used when a value of a property needs additional information. The property can then be pointed to a new resource, having an rdf:value property pointing to the original value, and any number of new properties qualifying this value. Thus, the string value of the dc:title property in this example:

<dc:title>Sniffy the virtual rat</dc:title>

This can be qualified with a language in this way (see next section for details on language qualifiers):

<dc:title rdf:parseType="Resource">
  <rdf:value>Sniffy the virtual rat</rdf:value>
  <dc:language rdf:resource="#en"/>
</dc:title>

The title would be found to be the same in both cases, but in the second case, the language (English) of the string would also be known.

Dublin Core Qualifiers draft specifies a "dumb-down" algorithm that essentially removes all qualifying properties, leaving only the final string value. This binding has been designed with this algorithm in mind. This way, software can produce unqualified Dublin Core meta-data from LOM RDF meta-data in a straightforward and stnadardized way, by using the "dumb-down" algorithm.

In the absence of qualifying properties, it is legal to collapse the construct completely as in the following example (see next section for explanation on LangString):

<dc:title>
  <lom:LangString rdf:ID="title">
    <rdf:value rdf:parseType="Resource">
      <rdf:value>Sniffy the virtual rat</rdf:value>
    </rdf:value>
  </lom:LangString>
</dc:title>

This is equivalent to:

<dc:title>Sniffy the virtual rat</dc:title>

This form of collapse is completely legal, and applications should support it for any element where it may occur. However, collapsing in this way is not always desirable. In the above case, collapsing the statement necessitates a restructuring when a translation of the title is to be made. So in many cases, keeping the full construct is the safest way to go, as it simplifies extensions.

Similarly, collapsing an rdf:Bag or other container in the case of only one element is allowed, but not always a good idea, as this may prevent adding additional resources from the outside. In short, care must be taken when using shortcuts such as these. However, they are syntactically and semantically legal constructs and thus must be supported.

A.4.3. Language-Specific Strings

When encoding a string in a specific language, we do not use the xml:lang attribute (this is discussed in the W3C document located at http://www.w3.org/DesignIssues/InterpretationProperties.html). Instead, we follow the guidelines in Dublin Core Qualifiers draft (esp. section 4), using an explicit dc:language qualifier. An example of a language-tagged string follows:

<dc:title>
  <rdf:value>Sniffy the virtual rat</rdf:value>
  <dc:language rdf:resource="#en"/>
</dc:title>

Here "#en" is a separate language resource. This should be an instance of dcq:RCF1766, for example:

<dcq:RCF1766 rdf:ID="en">
  <rdf:value>en</rdf:value>
  <rdf:label>English</rdf:label>
  <rdf:isDefinedBy rdf:resource="http://www.ietf.org/rfc/rcf1766.txt"/> 
</rdf:Description>

It is recommended to put definitions of languages in a separate RDF document, so that they can be reused.

When encoding strings in several languages, always use the following construct (for a more formal description on LangString, see the section of the same title):

<dc:title>
  <lom:LangString rdf:ID="title">
    <rdf:value rdf:parseType="Resource">
      <rdf:value>Sniffy the virtual rat</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
    <lom:translation rdf:parseType="Resource">
      <rdf:value>Sniffy le rat virtuel</rdf:value>
      <dc:language rdf:resource="#fr"/>
    </lom:translation>
  </lom:LangString>
</dc:title>

This technique allows us to separate the original title from translations. It also allows Dublin Core-only RDF parsers to understand what the title is, via the "dumb-down" algorithm described in the previous section. Finally, it allows us to add translations in separate RDF documents. A necessary prerequisite for this is that all LangString instances are given an explicit ID as in the example above. For this reason, giving such an ID to each LangString is strongly recommended, even if it is generated automatically by the editing software.

It should be noted that, though allowed, the use of rdfs:label and rdfs:comment is discouraged. The reason is that there is no good way to add language qualifiers, as they point to string literals. Use dc:title and dc:description instead.

A.4.4 Ordered and Unordered Lists

In the IMS XML binding, lists are constructed using repetitions of the containing element. In RDF, there are four different possibilities, and all of them can be used when they express the desired semantics. The four ways are: repeated properties, rdf:Bag, rdf:Alt, and rdf:Seq. We provide guidelines below on which to choose to be maximally LOM compatible. Implementers are free to use any of these constructs if they feel that it better represents the semantics of their meta-data; however, keep in mind that such information might get lost when translating to the XML binding.

A.4.5 Pre-Defined Classes

In some cases Dublin Core has pre-defined classes for use as types of the values. Use of this construct is strongly encouraged, and the classes available for use are given in the table below. In some cases, there is a corresponding qualifier in LOM. For example, the class http://dublincore.org/2000/03/13/dcq#W3CDTF is used to represent dates and times in ISO8601 format, which is used in LOM. We strongly favor this kind of explicit datatyping using RDF classes (see the dc:language example above).

A.4.6 Vocabularies

Vocabularies are represented in several different ways in this binding. The fundamental idea is that the (source, value) construct in LOM is best represented in RDF using the (namespace, value) construct that is naturally contained in a resource URI in RDF. Thus, vocabulary values are resources, and the source of a vocabulary is implicit in the URI of a resource.

This binding will provide resources for the restricted vocabularies defined in LOM. These resources can be used directly as values of the corresponding property, for example:

<lom_life:status rdf:resource="http://www.imsproject.org/rdf/imsmd_lifecyclev1p2#Draft"/>

Additionally, implementers are free to define their own RDF resources for use as values in vocabularies, for example:

<lom_life:status rdf:resource="http://www.myVocabulary.com/someVocab#FinalBeta"/>

The resource pointed to will most probably be an RDF resource that is part of an RDF Schema defining the vocabulary. Thus, vocabularies will need to be explicitly translated to RDF. This convention leads to some difficulties when interfacing with the XML binding. Further development in this area is necessary.

Note: In several cases, the vocabulary resource is not an RDFS Class, but rather a Property. This is the case with element 7.1. Relation.Kind, for example:

<dcq:hasPart rdf:resource="http://www.someContentProvider.com/someContent.html"/>

Here the relation is of kind "hasPart". Defining new vocabularies here is as simple as for the above case. The only difference is that, in the example, one would need to define a subPropertyOf dc:relation. This new property is again an RDF resource, and thus the same remarks are valid: explicit translation to RDF is necessary, and care must be taken when interfacing with the XML binding.

A definition of a private (not necessarily useful) vocabulary for Relation.Kind could look like:

<rdf:Property rdf:ID="hasPrerequisite">
  <rdfs:subPropertyOf rdf:resource="http://purl.org/dc/elements/1.1/relation"/>
  <dc:title>Has prerequisite</dc:title>
  <dc:description>This property point to a resource that is a necessary
  prerequisite for the learning object.</dc:description>
</rdf:Property>

This would then be used (with the appropriate namespace definition in place) as:

<myVoc:hasPrerequisite rdf:resource="http://www.someContentProvider.com/someContent.html"/>

A.4.7 Using Metameta-data

Generally, the metameta-data category is obsoleted in RDF. There is no real way in which one can talk about "meta-data instances", as the information is connected globally in a semantic web. Thus, the elements in this category must be represented in other ways. Two ways are provided by RDF, and both rely on reusing the normal (non-metameta-data) meta-data properties. But they are not applied to the learning resource, but to either of the following:

  • the containing RDF document
  • a set of RDF statements

Both of these are perfectly valid approaches. Some additional guidance on the representation of LOM metameta-data elements is given in the table below. All of them should apply not to the learning resource being described, but to one of the above resources.

A.4.8 Classifications

This is the most complex category of all. We have decided to represent taxonomies separately from each meta-data instance. The idea is to represent a hierarchical taxonomy separately, and pointing into this hierarchy when classifying resources. In addition, we try to reuse the subject classifications from Dublin Core Qualifiers, for example:

<lom_cls:Taxonomy rdf:ID="MeSH">
  <rdfs:label>Medical Subject Headings</rdfs:label>
  <lom_cls:taxon>
    <dcq:MeSH ID="A">
      <rdf:value>A</rdf:value>
      <rdfs:label>Anatomy</rdfs:label>
      <lom_cls:taxon>
        <dcq:MeSH ID="A01">
          <rdf:value>A01</rdf:value>
          <rdfs:label>Body Regions</rdfs:label>
         <lom_cls:taxon>
            <dcq:MeSH ID="A01.047">
              <rdf:value>A01.047</rdf:value>
              <rdfs:label>Abdomen</rdfs:label>
              <lom_cls:taxon>
              ...

Using this will then look like:

<dc:subject>
  <rdf:value rdf:resource="http://www.myVocabulary.com/taxonomy#A01.047"/>
  <dc:description>...</dc:description>
</dc:subject>

A.5 Acknowledgements

This binding has been developed by Mikael Nilsson at the Center for user-oriented IT-design at the Royal Institute of Technology in Stockholm, Sweden, with cooperation from the Uppsala Learning Lab. Matthias Palmér from CID has contributed substantial critique of this document. Large parts of the binding come from previous work on LOM RDF schemas by researchers from Learning Lab Lower Saxony at KBS in Hannover, from the UNIVERSAL project. Significant contributions to the schema details have come from: Wolfgang Nejdl, Boris Wolf, Hadhami Dhraief, and Jan Brase from KBS, and Gustaf Neumann, Susanne Guth, Bernd Simon, and Thomas Enzi from Wirtschaftsuniversität Wien, part of the UNIVERSAL project.

A.6 The Binding Table

This table defines, for each element in the IMS Meta-Data Information Model v1.2, the corresponding RDF property to use. It specifies how to repeat the element in conformance with the Information Model and gives usage examples. Note that the RDF Schema definition files in some cases provide more precise definitions, especially for vocabulary creators.

Note: Elements 1.1 and 3.1 are special cases that are not represented as properties, but instead use the RDF rdf:about attribute.

1. General Category

 
LOM element Usage guidelines Ordering representation Example
1.1 Identifier Use the RDF rdf:about attribute. Use dc:identifier only for special needs. Do not repeat the dc:identifier.
<rdf:Description rdf:about="http://www.someContentProvider.com/someContent.html">
...
</rdf:Description>
1.2 Title Use dc:title, pointing to a lom:LangString. Do not repeat.
<dc:title>
  <lom:LangString rdf:ID="title">
    <rdf:value rdf:parseType="Resource">
      <rdf:value>Sniffy the virtual rat</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
    <lom:translation rdf:parseType="Resource">
      <rdf:value>Sniffy le rat virtuel</rdf:value>
      <dc:language rdf:resource="#fr"/>
    </lom:translation>
  </lom:LangString>
</dc:title>
1.3 Catalogentry Use lom_gen:catalogentry. Catalogs are represented as RDF Classes, and this property should point to an instance of such a class. The instance should have an rdf:value property pointing to the entry. There are no pre-defined classes to use, so implementers will need to create classes. It is expected that standardized catalog classes will be developed. Use repeated properties.
<lom_gen:catalogentry>
  <myVoc:ISBN>
    <rdf:value>0-226-10389-7</rdf:value>
  </myVoc:ISBN>
</lom_gen:catalogentry>
1.4 Language Use dc:language. Use instances of dcq:RFC1766. Use repeated properties.
<dc:language rdf:resource="#en"/>
1.5 Description Use dc:description pointing to a lom:LangString. Use repeated properties for separate descriptions.
<dc:description>
  <lom:LangString rdf:ID="desc1">
    <rdf:value rdf:parseType="Resource">
      &tl;rdf:value>A computer program ...</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
    <lom:translation rdf:parseType="Resource">
      &tl;rdf:value>Un programme machine ...</rdf:value>
      <dc:language rdf:resource="#fr"/>
    </lom:translation>
  </lom:LangString>
</dc:description>
1.6 Keywords Use dc:subject pointing to a LangString. Use repeated properties for separate keywords.
<dc:subject>
  <lom:LangString rdf:ID="keyword1">
    <rdf:value rdf:parseType="Resource">
      &tl;rdf:value>psychology</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
    <lom:translation rdf:parseType="Resource">
      &tl;rdf:value>psychologie</rdf:value>
      <dc:language rdf:resource="#fr"/>
    </lom:translation>
  </lom:LangString>
</dc:subject>
1.7 Coverage Use dc:coverage, dcq:spatial, or dcq:temporal. Available classes are:
  • dcq:TGN, dcq:ISO3166, dcq:Box and dcq:Point for dcq:spatial values
  • dcq:W3CDTF and dcq:Period for dcq:temporal values.
For textual descriptions, use lom:LangString.
Use repeated properties for separate coverage.
<dcq:temporal>
  <dcq:W3CDTF>
    <rdf:value>1776-07-04</rdf:value>
  </dcq:W3CDTF>
</dcq:temporal>
<dcq:spatial>
  <lom:LangString rdf:ID="USA">
    <rdf:value rdf:parseType="Resource">
      <rdf:value>United States of America</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
  </lom:LangString>
</dcq:spatial>
1.8 Structure Use lom_gen:structure. For LOM restricted vocabulary, use: lom_gen:Collection, lom_gen:Mixed, lom_gen:Linear, lom_gen:Hierarchical, lom_gen:Networked, lom_gen:Branched, lom_gen:Parceled or lom_gen:Atomic. Do not repeat.
<lom_gen:structure rdf:resource="http://www.imsproject.org/rdf/imsmd_generalv1p2#Mixed"/>
1.9 Aggregation Level Use lom_gen:aggregationlevel. For LOM restricted vocabulary, use: lom_gen:Level1, lom_gen:Level2, lom_gen:Level3, lom_gen:Level4. Do not repeat.
<lom_gen:aggregationlevelrdf:resource="http:// www.imsproject.org/rdf/imsmd_generalv1p2#Level2"/>

2. Lifecycle Category

 
LOM element Usage guidelines Ordering representation Example
2.1 Version Use lom_life:version, pointing to a lom:LangString. Do not repeat.
<lom_life:version>
  <lom:LangString rdf:ID="version">
    <rdf:value rdf:parseType="Resource">
      &tl;rdf:value>2.3</rdf:value>
      <dc:language rdf:resource="#x-none"/>
    </rdf:value>
  </lom:LangString>
</lom_life:version>
or (not specifying language or allowing translations)
<lom_life:version>2.3</lom_life:version>
2.2 Status Use lom_life:status. For LOM restricted vocabulary, use: lom_life:Draft, lom_life:Final, lom_life:Revised or lom_life:Unavailable. Do not repeat.
<lom_life:status rdf:resource="http://www.imsproject.org/rdf/imsmd_lifecyclev1p2#Final"/>
2.3 Contribute There are three possibilities:
1. Use dc:publisher pointing to the contributing entity, in VCard format. The role is implicitly lom_life:publisher, and the date implicitly the date contained in dcq:issued or if this is missing, dc:date.
2. Use dc:creator pointing to the contributing entity, in VCard format. The role is implicitly lom_life:author, and the date implicitly the date contained in dcq:created or if this is missing, dc:date.
3. Use a subPropertyOf dc:contributor with rdf:value pointing to the contributing entity, in VCard format, and dc:date pointing to the date of the contribution.
The dc:date should point to an instance of dcq:W3CDTF.
For LOM restricted vocabulary for the contribution, use one of the following pre-defined subPropertiesOf dc:contributor as in case 3 above: lom_life:unknown, lom_life:initiator, lom_life:terminator, lom_life:validator, lom_life:editor, lom_life:graphicaldesigner, lom_life:technicalimplementer, lom_life:contentprovider, lom_life:technicalvalidator, lom_life:educationalvalidator, lom_life:scriptwriter or lom_life:instructionaldesigner. The use of lom_life:publisher or lom_life:author is not allowed. Instead use the corresponding Dublin Core constructs.
Use repeated properties. For multiple entities within one contribute element, use rdf:Seq. Do not use repeated rdf:value. Do not repeat the dc:date properties within a contribute element.
<dc:creator rdf:parseType="Resource">
  <vCard:fn>Erik Duval</vCard:fn>
</dc:creator>

<dcq:created>
  <dcq:W3CDTF>
    <rdf:value>2000-12-16</rdf:value>
  </dcq:W3CDTF>
</dcq:created>

<lom_life:editor rdf:parseType="Resource">
  <rdf:value>
    <rdf:Seq>
      <rdf:li rdf:parseType="Resource">
        <vCard:fn>Tom Wason</vCard:fn>
      </rdf:li>
      <rdf:li rdf:parseType="Resource">
        <vCard:fn>Eric Duval</vCard:fn>
      </rdf:li>
    </rdf:Seq>
  </rdf:value>
  <dc:date>
    <dcq:W3CDTF>
      <rdf:value>1998</rdf:value>
      <dc:description>A few years ago.</dc:description>
    </dcq:W3CDTF>
  </dc:date>
</lom_life:editor>

3. Metametadata Category

Note that all elements below apply not to the learning resource, but to the metadata about the resource. Please see the example document for examples.


 
LOM element Usage guidelines Ordering representation Example
3.1 Identifier Use exactly as 1.1 Identifier. Do not repeat.
<rdf:Description rdf:about="http://www.someContentProvider.com/someContentMetadata.rdf">
...
</rdf:Description>
or
<rdf:Description rdf:about="http://www.someContentProvider.com/someContentMetadata.rdf#bagOfStatements">
...
</rdf:Description>
3.2 Catalog Entry Use exactly as 1.3 Catalog Entry. Use repeated properties.

3.3 Contribute Use exactly as 2.3 Contribute, but use only the roles dc:creator and lom_life:validator for full LOM compliance. Use repeated properties. Group contributions just as in 2.3 Contribute.

3.4 Metadata Scheme If the metadata is compatible with this guide, use lom_meta:metadatascheme pointing to lom_meta:IMSMD_1.2, lom_meta:LOMv1.0 and lom_meta:ARIADNEv3. This will guide software in interpreting the metadata as a LOM description. Use repeated properties.
<lom_meta:metadatascheme rdf:resource="http://www.imsproject.org/rdf/imsmd_metametadatav1p2#LOMv1.0"/>
<lom_meta:metadatascheme rdf:resource="http://www.imsproject.org/rdf/imsmd_metametadatav1p2#ARIADNEv3"/>
<lom_meta:metadatascheme rdf:resource="http://www.imsproject.org/rdf/imsmd_metametadatav1p2#IMSMD_1.2"/>
3.5 Language Use exactly as 1.4 Language. Note that this language may be used in accordance with the LOM Standard to specify a default language for all literals. Do not repeat.

4. Technical Category

 
LOM element Usage guidelines Ordering representation Example
4.1 Format Use dcq:medium with a value of rdf:type dcq:IMT. Instances of this class represent mime-types. For non-digital resources, use a value of type lom_tech:NonDigital. Use repeated properties.
<dcq:medium>
  <dcq:IMT>
    <rdf:value>text/html</rdf:value>
    <rdfs:label>HTML document</rdfs:label>
  </dcq:IMT>
</dcq:medium>
4.2 Size Use dcq:extent with a value of rdf:type lom_tech:ByteSize with an rdf:value pointing to the value literal. Do not repeat.
<dcq:extent>
  <lom_tech:ByteSize>
    <rdf:value>124032</rdf:value>
  </lom_tech:ByteSize>
</dcq:extent>
4.3 Location Use lom_tech:location either pointing to the resource URI, or for non-URI locations, a string literal. Use only rdf:Seq.
<lom_tech:location rdf:resource="http://www.someContentProvider.com/someDocument.pdf"/>
4.4 Requirements Use a subPropertyOf lom_tech:requirement pointing to an instance of lom_tech:TechnologyRequirement with lom_tech:minimumversion and lom_tech:maximumversion pointing to the corresponding version literals.


For LOM restricted vocabulary for the requirement type, use: lom_tech:operatingsystem or lom_tech:browser.


For LOM restricted vocabulary for the required technology, use instances of: lom_tech:PC-DOS, lom_tech:MS-Windows, lom_tech:MacOS, lom_tech:Unix, lom_tech:Multi-OS or lom_tech:None for operating systems, and instances of lom_tech:Any, lom_tech:NetscapeCommunicator, lom_tech:MicrosoftInternetExplorer, lom_tech:Opera or lom_tech:Amaya for browser. All these are subClassesOf lom_tech:TechnologyRequirement
Use repeated properties. Do not repeat any of lom_tech:minimumversion or lom_tech:maximumversion.
<lom_tech:operatingsystem>
  <lom_tech:Multi-OS/>
</lom_tech:operatingsystem>

<lom_tech:browser>
  <lom_tech:NetscapeCommunicator>

<lom_tech:minimumversion>4.7</lom_tech:minimumversion>
  <lom_tech:NetscapeCommunicator>
</lom_tech:browser>
4.5 Installation Remarks Use lom_tech:installationremarks pointing to a lom:LangString. Do not repeat.
<lom_tech:installationremarks>
  <lom:LangString rdf:ID="instremarks">
    <rdf:value rdf:parseType="Resource">
      <rdf:value>First install ...</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
  </lom:LangString>
</lom_tech:installationremarks>
4.6 Other Platform Requirements Use lom_tech:otherplatformrequirements pointing to a lom:LangString. Do not repeat.
<lom_tech:otherplatformrequirements>
  <lom:LangString rdf:ID="otherreq">
    <rdf:value rdf:parseType="Resource">
      <rdf:value>You will also need ...</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
  </lom:LangString>
</lom_tech:otherplatformrequirements>
4.7 Duration Use dcq:extent with a value of type lom:ISO8601. Do not repeat.
<dcq:extent>
  <lom:ISO8601>
    <rdf:value>PT1H20M</rdf:value>
  </lom:ISO8601>
</dcq:extent>

5. Educational Category

 
LOM element Usage guidelines Ordering representation Example
5.1 Interactivity Type Use lom_edu:interactivitytype. For LOM restricted vocabulary, use: lom_edu:Active, lom_edu:Expositive, lom_edu:Mixed or lom_edu:Undefined. Do not repeat.
<lom_edu:interactivitytype rdf:resource="http://www.imsproject.org/rdf/imsmd_educationalv1p2#Active"/>
5.2 Learning Resource Type Use rdf:type. For LOM restricted vocabulary, use: lom_edu:Exercise, lom_edu:Simulation, lom_edu:Questionnaire, lom_edu:Diagram, lom_edu:Figure, lom_edu:Graph, lom_edu:Index, lom_edu:Slide, lom_edu:Table, lom_edu:NarrativeText, lom_edu:Exam, lom_edu:Experiment, lom_edu:ProblemStatement or lom_edu:SelfAssesment. Use repeated properties. This conflicts with LOM, which specifies that this element is ordered.
<rdf:Description rdf:about="http://www.someContentProvider.com/someContent.html">
  <dc:title>...</dc:title>
  ...
  <rdf:type rdf:resource="http://www.imsproject.org/rdf/imsmd_educationalv1p2#Exercise"/>
  ...
</rdf:Description> 
or, using RDF shorthand notation:
<lom_edu:Exercise rdf:about="http://www.someContentProvider.com/someContent.html">
  <dc:title>...</dc:title>
  ...
</lom_edu:Exercise>
5.3 Interactivity Level Use lom_edu:interactivitylevel. For LOM restricted vocabulary, use: lom_edu:VeryLowInteractivity, lom_edu:LowInteractivity, lom_edu:MediumInteractivity, lom_edu:HighInteractivity or lom_edu:VeryHighInteractivity Do not repeat.
<lom_edu:interactivitylevel rdf:resource="http://www.imsproject.org/rdf/imsmd_educationalv1p2#LowInteractivity"/>
5.4 Semantic Density Use lom_edu:semanticdensity. For LOM restricted vocabulary, use: lom_edu:VeryLowDensity, lom_edu:LowDensity, lom_edu:MediumDensity, lom_edu:HighDensity or lom_edu:VeryHighDensity Do not repeat.
<lom_edu:semanticdensity rdf:resource="http://www.imsproject.org/rdf/imsmd_educationalv1p2#HighDensity"/>
5.5 Intended End User Role Use lom_edu:intendedenduserrole. For LOM restricted vocabulary, use: lom_edu:Teacher, lom_edu:Author, lom_edu:Learner or lom_edu:Manager. Use rdf:Seq for repetition.
<lom_edu:intendedenduserrole rdf:resource="http://www.imsproject.org/rdf/imsmd_educationalv1p2#Manager"/>
5.6 Context Use lom_edu:context.
For LOM restricted vocabulary, use: lom_edu:PrimaryEducation, lom_edu:SecondaryEducation, lom_edu:HigherEducation, lom_edu:UniversityFirstCycle, lom_edu:UniversitySecondCycle, lom_edu:UniversityPostgrade, lom_edu:TechnicalSchoolFirstCycle, lom_edu:TechnicalSchoolSecondCycle, lom_edu:ProfessionalFormation, lom_edu:ContinuousFormation or lom_edu:VocationalTraining.
Use repeated properties.
<lom_edu:context rdf:resource="http://www.imsproject.org/rdf/imsmd_educationalv1p2#PrimaryEducation"/>
5.7 Typical Age Range Use lom_edu:typicalagerange pointing to a lom:LangString. For distinct age ranges, use separate properties.
<lom_edu:typicalagerange>
  <lom:LangString rdf:ID="typagerange">
    <rdf:value rdf:parseType="Resource">
      <rdf:value>Over fifteen years of age.</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
  </lom:LangString>
</lom_edu:typicalagerange>
5.8 Difficulty Use lom_edu:difficulty.
For LOM restricted vocabulary, use: lom_edu:VeryEasy, lom_edu:Easy, lom_edu:MediumDifficulty, lom_edu:Difficult or lom_edu:VeryDifficult.
Do not repeat.
<lom_edu:difficulty rdf:resource="http://www.imsproject.org/rdf/imsmd_educationalv1p2#Easy"/>
5.9 Typical Learning Time Use lom_edu:typicallearningtime, with a value of type lom:ISO8601. Do not repeat.
<lom_edu:typicallearningtime>
  <lom:ISO8601>
    <rdf:value>PT1H20M</rdf:value>
  </lom:ISO8601>
</lom_edu:typicallearningtime>
5.10 Description Use lom_edu:description, pointing to a lom:LangString. Do not repeat.
<lom_edu:description>
  <lom:LangString rdf:ID="edudesc">
    <rdf:value rdf:parseType="Resource">
      <rdf:value>This is intended to be used ...</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
  </lom:LangString>
</lom_edu:description>
5.11 Language Use lom_edu:language. Use instances of dcq:RFC1766. Use repeated properties. <lom_edu:language rdf:resource="#fr"/>

6. Rights Category

In this category, we disagree with LOM in that the Dublin Core property dc:rights maps to this whole category. We think it only maps to element 6.3, Rights.Description (as was the case in IMS Meta-Data v1.1). This is reflected below.

 
LOM element Usage guidelines Ordering representation Example
6.1 Cost Use lom_rights:cost. For LOM restricted vocabulary, use: lom_rights:SomeCost or lom_rights:NoCost. Do not repeat.
<lom_rights:cost rdf:resource="http://www.imsproject.org/rdf/imsmd_rightsv1p2#NoCost"/>
6.2 Copyright and Other Restrictions Use lom_rights:copyrightandotherrestrictions. For LOM restricted vocabulary, use: lom_rights:SomeRestriction or lom_rights:NoRestriction. Do not repeat.
<lom_rights:copyrightandotherrestrictions rdf:resource="http://www.imsproject.org/rdf/imsmd_rightsv1p2#SomeRestriction"/>
6.3 Description Use dc:rights, pointing to a lom:LangString. Do not repeat.
<dc:rights>
  <lom:LangString rdf:ID="rights">
    <rdf:value rdf:parseType="Resource">
      <rdf:value>Copyright 1999 ...</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
  </lom:LangString>
</dc:rights>

7. Relation Category

This is strictly no category, but an element. Due to the nature of RDF in the semantic web environment, the elements 7.2.2 Description and 7.2.3 Catalog Entry are not used directly. Instead, the intention is that they can be attached to the resource pointed to. In the example below, the related resource is defined by an ISBN number.

 
LOM element Usage guidelines Ordering representation Example
7 Relation There are two ways to use this element.
1. Use a pre-defined subproperty of dc:relation, one for each element in the restricted LOM vocabulary. There are three cases:
a. Use one of the Dublin Core qualifying properties dcq:isVersionOf, dcq:hasVersion, dcq:isReplacedBy, dcq:replaces, dcq:isRequiredBy, dcq:requires, dcq:isPartOf, dcq:hasPart, dcq:isReferencedBy, dcq:references, dcq:isFormatOf, dcq:hasFormat.
b. Use dc:source when the Relation.Kind is "IsBasedOn".
c. Use lom_rel:isBasisFor.
2. For your own Relation.Kind vocabularies, you can define your own subproperty of dc:relation.
Use repeated properties.
<dcq:hasPart rdf:resource="http://www.someContentProvider.com/someOtherContent.html"/>
<dcq:isReferencedBy>
  <rdf:Description rdf:about="http://www.someContentProvider.com/someOtherContent.html"/>
    <lom_gen:catalogentry>
      <myVoc:ISBN>
        <rdf:value>0-226-10389-7</rdf:value>
      </myVoc:ISBN>
    </lom_gen:catalogentry>
  <rdf:Description>
</dcq:isReferencedBy>

8. Annotation Category

This is strictly speaking no category, but an element in itself.

 
LOM element Usage guidelines Ordering representation Example
8. Annotation Use lom_ann:annotation with lom_ann:person giving a VCard for the annotating person, an dc:date with a value of type dcq:W3CDTF, giving the date of the annotation, and an rdf:value for the actual annotation (a lom:LangString). Use repeated properties. Use only one lom_ann:person, only one dc:date, and only one rdf:value.
<lom_ann:annotation rdf:parseType="Resource">
  <lom_ann:person rdf:parseType="Resource">
    <vCard:fn>Philip Dodds</vCard:fn>
  </lom_ann:person>
  <dc:date>
    <dcq:W3CDTF>
      <rdf:value>2000-12-17</rdf:value>
    </dcq:W3CDTF>
  </dc:date>
  <rdf:value>
    <lom:LangString rdf:ID="ann1">
    <rdf:value rdf:parseType="Resource">
      <rdf:value>I think this document is ...</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
  </lom:LangString>
</lom_ann:annotation>

9. Classification Category

This is strictly speaking no category, but an element in itself.


 
LOM element Usage guidelines Ordering representation Example
9. Classification Use subPropertiesOf lom_cls:classification. There are three possibilities:
1. When Classification.Purpose is "Discipline" or "Idea", use dc:subject. This usage is defined by the LOM-DC mapping.
2. For LOM restricted vocabulary for the purpose, use: lom_cls:prerequisite, lom_cls:educationalobjective, lom_cls:accessibilityrestrictions, lom_cls:educationallevel, lom_cls:skilllevel, lom_cls:securitylevel.
The use of lom_cls:discipline and lom_cls:idea, while allowed, is discouraged. Instead use the first construct above, with dc:subject.
3. Define your own subPropertyOf lom_cls:classification to use private purposes.
This property should point to a taxon in a taxonomy hierarchy. Such an hierarchy is an instance of lom_cls:Taxonomy, which is defined in a separate table.
The classification can be further qualified with a single dc:description and multiple dc:subject (keywords).
Use repeated properties. For giving several classifications with the same purpose, description and keywords, use an rdf:Bag as the value of the rdf:value property. Using the example taxonomy in the taxonomy example in the taxonomy definition table:
<dc:subject>
  <rdf:value rdf:resource="http://www.myVocabulary.com/taxonomy#A01.047"/>
  <dc:description>...</dc:description>
  <dc:subject>...</dc:subject>
</dc:subject>

A.7 LangString Definition

 
LOM element Usage guidelines Ordering representation Example
LangString Use instances of lom:LangString to represent a natural language object with several translations.
Use an rdf:value pointing to the primary translation. For other translations, use lom:translation.
Each translation is represented as a resource with an rdf:value pointing to the string literal, and a dc:language pointing to an instance of dcq:RFC1766 representing a language.
Use one and only one instance of lom:LangString to represent the same natural language object. Do not repeat rdf:value. dc:language can be repeated if an entry is in several languages. Use repeated properties to repeat lom:translation.
<dc:title>
  <lom:LangString rdf:ID="title">
    <rdf:value rdf:parseType="Resource">
      <rdf:value>Sniffy the virtual rat</rdf:value>
      <dc:language rdf:resource="#en"/>
    </rdf:value>
    <lom:translation rdf:parseType="Resource">
      <rdf:value>Sniffy le rat virtuel</rdf:value>
      <dc:language rdf:resource="#fr"/>
    </lom:translation>
  </lom:LangString>
</dc:title>

A.8 Taxonomies

This table defines how to construct reusable taxonomies.

 
LOM element Usage guidelines Ordering representation Example
Taxonomy Taxonomies are instances of lom_cls:Taxonomy. Each taxonomy is a hierarchy of taxons. The first-level taxons are pointed to by lom_cls:taxon properties. Each such taxon can be an instance of one of the pre-defined classes dcq:LCSH, dcq:MeSH, dcq:DDC, dcq:LCC or dcq:UDC, or of a locally defined class.
Each such taxon must have an rdf:value pointing to the code of the taxon, or a dc:title (or rdfs:label) giving the label of the entry. lom:LangString constructs are allowed.
The taxon can also have sub-taxons, in the form of a lom_cls:taxon property pointing to the sub-taxon, and so on recursively.

 
In a separate file (http://www.myVocabulary.com/taxonomy):
<lom_cls:Taxonomy rdf:ID="MeSH">
  <dc:title>Medical Subject Headings</dc:title>
  <lom_cls:taxon>
    <dcq:MeSH ID="A">
      <rdf:value>A</rdf:value>
      <dc:title>Anatomy</dc:title>
      <lom_cls:taxon>
        <dcq:MeSH ID="A01">
          <rdf:value>A01</rdf:value>
          <dc:title>Body Regions</dc:title>
          <lom_cls:taxon>
            <dcq:MeSH ID="A01.047">
              <rdf:value>A01.047</rdf:value>
              <dc:title>Abdomen</dc:title>
              <lom_cls:taxon>
              ...

Appendix B - Additional Resources

IEEE Learning Object Meta-Data (LOM)

The IEEE Learning Object Meta-Data (LOM) Draft Standard can be found at: http://ltsc.ieee.org/doc/wg12/

IMS XML Documents

The imsmd_rootv1p2.dtd is located at: http://www.imsglobal.org/xml/imsmd_rootv1p2.dtd

The imsmd_rootv1p2p1.xsd is located at: http://www.imsglobal.org/xsd/imsmd_rootv1p2p1.xsd

IMS Meta-Data Documents

The IMS Learning Resource Meta-Data Best Practice and Implementation Guide can be found at: http://www.imsglobal.org/metadata/imsmdv1p2p1/imsmd_bestv1p2p1.html

The IMS Learning Resource Meta-Data Information Model document can be found at: http://www.imsglobal.org/metadata/imsmdv1p2p1/imsmd_infov1p2p1.html

Sample meta-data files and control documents in a ZIP file can be found at: http://www.imsglobal.org/metadata/

ISO/IEC 10646

ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7).

Unicode

The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.

vCard

vCard Specification http://www.imc.org/pdi/

XML

XML Version 1.0 Specification of the W3C: http://www.w3.org/TR/1998/REC-xml-19980210

XML Namespace Recommendation of W3C: http://www.w3.org/TR/1999/REC-xml-names-19990114

Appendix C - List of Contributors

The following individuals contributed to the development of this specification:

 
Martin Koning Bastiaan Center for Distributed Learning
Boyd Nielsen NETg
Mikael Nilsson CID, Royal Institute of Technology, Stockholm
Claude Ostyn Click2Learn, Inc.
Dan Rehak Carnegie Mellon University
Schawn Thropp ADL

About This Document

 

Title

IMS Learning Resource Meta-Data XML Binding Specification

Editors

Schawn Thropp and Mark McKell

Version

1.2.1

Version Date

September 2001

Status

Final Specification

Summary

This document provides updated information regarding IMS Learning Resource Meta-Data XML Binding Specification.

Revision Information

28 September 2001

Purpose

Defines the Learning XML Binding Specification.

Document Location

http://www.imsglobal.org/metadata/imsmdv1p2p1/imsmd_bindv1p2p1.html

Revision History

 
Version No. Release Date Comments
Final 1.0 20 August 1999 The version 1.0 of the IMS Learning Resource Meta-Data XML Binding Released.
Final 1.1 5 May 2000 IEEE LTSC LOM Version 3.5 Tables included. All element names changed to lower case only.
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) Assigned "x-none" value to the xml:lang attribute when used within <source> and <value>.
d) Added narrative description of elements in Section 2.
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 RDF binding to the appendix.
Final 1.2.1 28 September 2001 a) Corrected minor discrepancies between element descriptions in this document and the IMS Meta-Data Information Model.

Index

A
Attributes 1

B
Binding Table 1

C
CDATA 1
Contributors 1

D
DTD 1, 2
Dublin Core 1

E
Elements 1
     aggregationlevel 1
     annotation 1
     catalog 1
     catalogentry 1
     centity 1
     classification 1
     context 1
     contribute 1
     copyrightandotherrestrictions 1
     cost 1
     coverage 1
     date 1, 2
     Date Type 1
     datetime 1
     description 1, 2, 3, 4
     difficulty 1
     duration 1
     educational 1
     entry 1
     format 1
     id 1
     identifier 1
     installationremarks 1
     intendedenduserrole 1
     interactivitylevel 1
     interactivitytype 1
     keyword 1, 2
     Keywords 1
     kind 1
     LangString Type 1
     Language 1
     language 1
     learningresourcetype 1
     lifecycle 1
     location 1
     lom 1
     maximumversion 1
     metametadata 1
     minimumversion 1
     name 1
     otherplatformrequirements 1
     person 1
     purpose 1
     relation 1
     requirement 1
     resource 1
     rights 1
     role 1
     semanticdensity 1
     size 1
     source 1
     status 1
     structure 1
     taxon 1
     taxonpath 1
     technical 1
     title 1
     type 1
     typicalagerange 1
     typicallearningtime 1
     value 1
     Vcard Type 1
     version 1
     Vocabulary Type 1
Extensibility 1
extension 1
 

G
general 1

I
IEEE 1

L
Lists 1
LOM 1, 2, 3
LTSC 1

N
Names 1
Namespace 1
Namespaces 1, 2

P
PCDATA 1

R
RDF Binding 1
reference 1

S
schema 1
Schema Definition 1
Schemas 1

U
Unicode 1

V
vCard 1, 2
Vocabularies 1

X
XDR 1
XML 1, 2
XSD 1

 

 

 

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Learning Resource Meta-Data XML Binding ("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 Learning Resource Meta-Data XML Binding Revision: 28 September 2001