 |
1EdTech Learning Resource Meta-Data XML Binding Version 1.2.1 Final Specification |
| Copyright © 2001 1EdTech Consortium, Inc. All Rights Reserved. The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc. Document Name: 1EdTech 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.
1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © 2001 1EdTech Consortium. All Rights Reserved.
Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.
Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
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 - 1EdTech 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/1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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
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 1EdTech Meta-Data Binding. Details of the construction of schemas are outside the scope of this document.
1.1.4 Valid Character Sets
An 1EdTech 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 1EdTech 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:
- Use to point to a specific encoding schema for machine interpretation, and
- 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. 1EdTech 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 1EdTech XML Meta-Data instance.
Attributes
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.
Multiplicity. The <general> element occurs 0 or 1 time within the top-level <lom> element.
Attributes
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 1EdTech Persistent, Location-Independent Resource Identifiers Best Practice Guide, which at the time of this writing was being considered as an 1EdTech wide base specification.
Multiplicity. The <identifier> element occurs 0 or 1 time within the <general> element.
Attributes
Elements
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
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
Elements
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
Elements
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
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
Elements
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
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
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
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
Elements
LOM Defined Vocabularies (<source> element set to LOMv1.0)
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
Elements
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.
Multiplicity. The <lifecycle> element occurs 0 or 1 time within the top-level <lom> element.
Attributes
Elements
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
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
Elements
LOM Defined Vocabularies (<source> element set to LOMv1.0)
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
Elements
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
Elements
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
Elements
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
Elements
2.4 <metametadata> Element
Description. Groups information about the meta-data instance itself (rather than the learning object that this instance describes).
Multiplicity. The <metametadata> element occurs 0 or 1 time within the top-level <lom> element.
Attributes
Elements
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 1EdTech Persistent, Location-Independent Resource Identifiers Best Practice Guide, which at the time of this writing was being considered as an 1EdTech wide base specification.
Multiplicity. The <identifier> element occurs 0 or 1 time within the <metametadata> element.
Attributes
Elements
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
Elements
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
Elements
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
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
Elements
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
Elements
LOM Defined Vocabularies (<source> element set to LOMv1.0)
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
Elements
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
Elements
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
Elements
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
Elements
Example
<metametadata> <language>en</language> </metametadata>
2.5 <technical> Element
Description. Groups the technical requirements and characteristics of the learning object.
Multiplicity. The <technical> element occurs 0 or 1 time within the top-level <lom> element.
Attributes
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
Elements
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
Elements
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
Elements
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
Elements
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
Elements
LOM Defined Vocabularies (<source> element set to LOMv1.0)
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
Elements
LOM Defined Vocabularies (<source> element set to LOMv1.0)
If Technical.Requirement.Type="Operating System"
If Technical.Requirement.Type="Browser"
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
Elements
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
Elements
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
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
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
Elements
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.
Multiplicity. The <educational> element occurs 0 or 1 time within the top-level <lom> element.
Attributes
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
Elements
LOM Defined Vocabularies (<source> element set to LOMv1.0)
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
Elements
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
Elements
LOM Defined Vocabularies (<source> element set to LOMv1.0)
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
Elements
LOM Defined Vocabularies (<source> element set to LOMv1.0)
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
Elements
LOM Defined Vocabularies (<source> element set to LOMv1.0)
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
Elements
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
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
Elements
LOM Defined Vocabularies (<source> element set to LOMv1.0)
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
Elements
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
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
Elements
Example
<educational> <language>en</language> </educational>
2.7 <rights> Element
Description. Conditions of use of the resource.
Multiplicity. The <rights> element occurs 0 or 1 time within the top-level <lom> element.
Attributes
Elements
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
Elements
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
Elements
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
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.
Multiplicity. The <relation> element occurs 0 or more times within the top-level <lom> element. The smallest permitted maximum is 100 instances.
Attributes
Elements
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
Elements
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
Elements
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
Elements
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
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
Elements
Description. Source of the following string value.
Multiplicity. The <catalog> element occurs 1 and only 1 time within the <catalogentry> element.
Attributes
Elements
Description. Actual catalog value.
Multiplicity. The <entry> element occurs 1 and only 1 time within the <catalogentry> element.
Attributes
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.
Multiplicity. The <annotation> element occurs 0 or more times within the top-level <lom> element. The smallest permitted maximum is 30 instances.
Attributes
Elements
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
Elements
Example
<annotation>
<person>
<vcard>
begin:vcard
org: 1EdTech
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
Elements
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
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.
Multiplicity. The <classification> element occurs 0 or more times within the top-level <lom> element. The smallest permitted maximum is 40 instances.
Attributes
Elements
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
Elements
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
Elements
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
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
Elements
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>
Description. A specific classification. Any recognized "official" taxonomy.
Multiplicity. The <id> element occurs 0 or 1 time within the <taxon> element.
Attributes
Elements
Description. Taxon's name or label.
Multiplicity. The <entry> element occurs 0 or 1 time within the <taxon> element.
Attributes
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
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
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.
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
Example
<classification>
<keyword>
<langstring xml:lang="en">simulation</langstring>
</keyword>
</classification>
3.2 Date Binding
Description. Defines the structure of a Date Type.
Multiplicity. Varies - see parent element.
Attributes
Elements
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
Elements
3.2.2 <description> Element
Description. Description of the date.
Multiplicity. The <description> element occurs 0 or 1 time within its parent element.
Attributes
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
Elements
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
Elements
3.3.2 <value> Element
Description. Defines the vocabulary structure.
Multiplicity. The <value> element occurs 0 or 1 time within its parent element.
Attributes
Elements
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
Elements
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:
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 1EdTech meta-data instances; however, 1EdTech 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, 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech meta-data:
- One or more elements may be added to the structure using elements defined in the IEEE LOM Draft Standard.
- One or more elements may be added to the structure using namespaced elements.
These two types of extension are defined as:
- 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.
- Use of namespaced elements: New elements may be introduced and used to extend the structure.
The 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech XML Binding uses the vCard Specification wherever the <entity> element is defined. An <entity>, as far as 1EdTech meta-data is concerned, represents a person or organization. The 1EdTech 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:
FN:Text Value
FN:Dr. Thomas D. Wason, Sr.
N:Family (Sur) Name; First (Given) Name; Other Names; Prefix; Suffix CRLF
N:Wason;Thomas;D.;Dr.;Sr
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
ADR:;1EdTech Project;1421 Park Drive;Raleigh;North Carolina;27605-1727;United States of America
LABEL: Text
LABEL;QUOTED-PRINTABLE:1EdTech 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.
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
ORG:1EdTech Project;Meta Data Team
Electronic Mail:
EMAIL; Electronic Mail Type:email
EMAIL;INTERNET:twason@imsproject.org
Telephone:
TEL:telephone number
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:1EdTech Project;Meta Data Team ADR:;1EdTech 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:1EdTech Project=0A= 1421 Park Drive=0A= Raleigh, NC 27605-1727=0A= USA END:VCARD
Appendix A - 1EdTech Meta-Data RDF Binding
This is a binding guide for representing 1EdTech Learning Resource Meta-Data v1.2 in RDF. For each element in the 1EdTech 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 1EdTech 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:
- The 1EdTech Meta-Data Information Model v1.2 (which is essentially equivalent with IEEE LOM Draft 6.1).
- The 1EdTech Meta-Data 1.2 Dublin Core mapping found as an Appendix to the 1EdTech Meta-Data Information Model.
- The RDF and RDF Schema Specifications from the W3C. This document does not contain tutorials on RDF or RDF Schema, but heavily relies on them (http://www.w3c.org/RDF/).
- The Dublin Core element set 1.1 (http://dublincore.org/documents/1999/07/02/dces/).
- The recent Dublin Core Qualifers in RDF draft, found at (http://www.mathematik.uni-osnabrueck.de/projects/dcqual/qual21.3.1/). Note that this document is also a work in progress and is not final.
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 1EdTech 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 1EdTech 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 1EdTech 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 1EdTech 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/1EdTech XML
The Dublin Core compatibility is reached at the cost of full 1EdTech 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 1EdTech 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 1EdTech base meta-data namespace "http://www.imsproject.org/rdf/imsmd_rootv1p2#".
- lom_gen: which is the 1EdTech general meta-data namespace "http://www.imsproject.org/rdf/imsmd_generalv1p2#".
- lom_life: which is the 1EdTech life cycle meta-data namespace "http://www.imsproject.org/rdf/imsmd_lifecyclev1p2#".
- lom_meta: which is the 1EdTech meta-meta-data namespace "http://www.imsproject.org/rdf/imsmd_metametadatav1p2#".
- lom_tech: which is the 1EdTech technical meta-data namespace "http://www.imsproject.org/rdf/imsmd_technicalv1p2#".
- lom_edu: which is the 1EdTech educational meta-data namespace "http://www.imsproject.org/rdf/imsmd_educationalv1p2#".
- lom_rights: which is the 1EdTech rights meta-data namespace "http://www.imsproject.org/rdf/imsmd_rightsv1p2#".
- lom_rel: which is the 1EdTech relation meta-data namespace "http://www.imsproject.org/rdf/imsmd_relationv1p2#".
- lom_ann: which is the 1EdTech annotation meta-data namespace "http://www.imsproject.org/rdf/imsmd_annotationv1p2#".
- lom_cls: which is the 1EdTech 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>
<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 1EdTech 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:
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 1EdTech 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
2. Lifecycle Category
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.
4. Technical Category
5. Educational Category
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 1EdTech Meta-Data v1.1). This is reflected below.
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.
8. Annotation Category
This is strictly speaking no category, but an element in itself.
9. Classification Category
This is strictly speaking no category, but an element in itself.
A.7 LangString Definition
A.8 Taxonomies
This table defines how to construct reusable taxonomies.
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/
1EdTech 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
1EdTech Meta-Data Documents
The 1EdTech Learning Resource Meta-Data Best Practice and Implementation Guide can be found at: http://www.imsglobal.org/metadata/imsmdv1p2p1/imsmd_bestv1p2p1.html
The 1EdTech 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:
About This Document
|
1EdTech Learning Resource Meta-Data XML Binding Specification |
|
|
This document provides updated information regarding 1EdTech Learning Resource Meta-Data XML Binding Specification. |
|
|
http://www.imsglobal.org/metadata/imsmdv1p2p1/imsmd_bindv1p2p1.html |
Revision History
Index
A
Attributes 1
B
Binding Table 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
N
Names 1
Namespace 1
Namespaces 1, 2
P
PCDATA 1
S
schema 1
Schema Definition 1
Schemas 1
U
Unicode 1
1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this 1EdTech Learning Resource Meta-Data XML Binding ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
1EdTech would appreciate receiving your comments and suggestions.
Please contact 1EdTech through our website at http://www.imsglobal.org
Please refer to Document Name: 1EdTech Learning Resource Meta-Data XML Binding Revision: 28 September 2001
