[This local archive copy is from the official and canonical URL, http://www.imsproject.org/work_public/meta-data_did188.html; please refer to the canonical source document if possible.]

Introduction

Metadata ("data about data") are descriptive labels used to index resources for use. "Use" includes activities like resource management, discovery, and delivery. Examples of metadata range from simple soup can labels (which describe cans' ingredients) to rich indexing schemes employed by libraries (which describe books, titles, authors, subjects, locations within the library, etc.). Metadata systems make the process of using resources more efficient and effective.

The system specified here allows the creation of multiple structures or "schemas"  The organization of the meta-data information reflects the manner in which meta-data schemas are managed. The actual meta-data describing a resource are created by following a meta-data schema. A schema describes a particular set of meta-data and the kinds of values that will be used to express the information. The IMS has several meta-data schemas that are all related. Each schema is designed to label different a kind of resource, from simple images to complete courses.

Purpose

This document specifies how meta-data is defined for interchange. It does not specify how meta-data is stored.

Revisions

Version 1.0
Version 1.01: Added ISO MIME reference to Format.
Version 1.02: Adjusted extensibility to match revised scope.

Acknowledgements

Many people have contributed to the development of the meta-data system. The IMS meta-data specifications are based on the IEEE LOM V2.2 Working document jointly authored with ARIADNE. The framework of the meta-data structure was developed principally through a collaboration of Erik Duval (U.K Leuven, ARIADNE Project), Wayne Hodgins (Autodesk, IEEE) and Tom Wason (IMS Project, IMS Project) under the IEEE LSTC (P1484) Learning Object Metadata group. The IMS Version 1.0 meta-data specifications differ in minor ways from the current state of the IEEE meta-data. IMS continues to collaborate with ARIADNE with the intent of converging meta-data standards under the auspices of the IEEE.

The IMS Meta-Data is a merger of the IMS and National Institutes of Standards and Technology (NIST) Learning Object Meta-Data Group (LOMG) efforts under the IMS Project.

Contents

Overview

Definitions

IMS Meta-Data

Conformance

Registration

Element Dictionary

Meta-Data Types

Appendices

Overview

Learning Resources

Meta-data is information about a resource, be it physical, digital or otherwise. The resource may be an HTML file, a video, or a book on a shelf. As the number of these resources grows, the lack of descriptive information about them places a severe constraint on our ability to locate, manage, and use these resources.

The IMS metadata standard specifies the organization and terminology of learning resource metadata. Learning resources are defined herein following the definition of "learning object" outlined by the IEEE's Learning Technology Standards Committee Working Group on Learning Object Metadata (P1484.12):

Learning Objects are defined here as any entity, digital or non-digital, which can be used, re-used or referenced during technology supported learning. Examples of technology supported learning include computer-based training systems, interactive learning environments, intelligent computer-aided instruction systems, distance learning systems, and collaborative learning environments. Examples of Learning Objects include multimedia content, instructional content, learning objectives, instructional software and software tools, and persons, organizations, or events referenced during technology supported learning.

Learning resource meta-data is the information required to adequately describe a learning resource so that it can be managed, discovered and used.

Property-Value Pairs

Learning resources have properties like a creation date, an author, and a file format. For any particular object there are specific values for these properties. The following Mona Lisa metadata is an example:

Mona Lisa Metadata
Property	Value
Creation Date	3/1/99
Author	John Smith
File Format	.jpg

Another way of representing the same information would be:

Creation Date = 3/1/99
Author = John Smith
File Format = .jpg

In other words, John Smith scanned the image on March 1st, 1999, and saved the image in .jpg format.

Elements and Hierarchies

When two systems exchange information and are able to use the information exchanged, the systems are said to be "interoperable." Interoperable metadata systems should be able to exchange and use each other's metadata. This interoperability requires a common way of describing the properties and values of learning resources. To this end the IMS metadata specification defines fixed ways of referring to the properties of learning resources. Fixing the terminology facilitates interoperability, allowing people and machines to talk to and understand each other.

The IMS specification fixes terminology by defining several metadata elements. Metadata elements represent a learning resource property or portion thereof. The names of these elements are "tokens." The individual elements can be combined in order to represent more information. In the following example, the elements Characteristics, Language, Description, and Concept are combined. The combination is represented hierarchically.

Element Name	Contextualized Definition  & Comments
Characteristics	Non-contextualized features of the resource.
|--Language	The human language of the intellectual content or the application interface.
|--Description	A textual description of the content of the resource.
|--Concept	The idea or notion presented in the resource. Examples: invariance, evolution, proof, taxonomy, operator, epoch.
|--|--Description	A textual description of the concept.

Each |-- represents one "indentation," or level, in the hierarchy.
This combination could also be represented in outline form:

• Characteristics
  • Language
  • Description
  • Concept
    • Description

Also, element names are frequently written together separated by periods:

Characteristics.Language
Characteristics.Description
Characteristics.Concept
Characteristics.Concept.Description

In the IMS specification, metadata elements are combined into unique concatenations. These concatenations of element names have meanings different from any of the individual elements. Notice that the element "Description" occurs twice. It's meaning depends on its position in the hierarchy. Under the category Characteristics, Description means simply "description of the resource." Under Characteristics.Concept, Description means "description of the concept(s) in the resource."

These meaning of these concatenations may be roughly understood by chopping off their first element (the category), and reading from right to left substituting "of the" or "in the" in place of each of the periods. Using this method even long combinations of elements are understandable. For example, LifeCycle.Create.Contribute.Role would mean the "role of the contribution in the creation" of the resource.

Because concatenated elements names like LifeCycle.Create.Contribute.Role are to long to use easily in conversation, the specification also defines Captions for each of the unique concatenations.

Element Name	Contextualized Definition  & Comments	Caption
Characteristics	Non-contextualized features of the resource.
|--Language	The human language of the intellectual content or the application interface.	Language
|--Description	A textual description of the content of the resource.	Abstract
|--Concept	The idea or notion presented in the resource. Examples: invariance, evolution, proof, taxonomy, operator, epoch.	Concept
|--|--Description	A textual description of the concept.	Concept Description

While the specification fixes tokens (or element names) for the sake of interoperabilty, captions may be changed as necessary for different locations, knowledge domains, communities, etc.

Constraints

The elements of the IMS metadata specification have specific rules governing their use. These rules, called "constraints," describe the ways in which the elements can be arranged or combined to create learning resource metadata. There are three constraints: obligation and list.

Constraint	Description
Obligation	The requirement for including the specific element at the specific location in the hierarchy.
List	The types and order of values that the element can have.

Constraint 1: Obligation

"Obligation" describes the level of requirement for using an element at a specific location in the hierarchy. As seen above, an element may mandatory or optional, for example. The IMS specification defines four levels of obligation.

Level of Obligation	Description
Mandatory	Elements which are Mandatory must be included. For example, General.Title must always be included and have a valid value.
Optional	Elements which are Optional may or may not be included at the user's discretion. For example, Characteristics.Approach, which describes the pedagogical approach of the resource, is optional since it may not apply to all learning resources.
Conditional	Elements which are Conditonal must be included if some other element be included. For example, RightsManagement.Conditions.Price.MonetaryUnit only needs to be included if an amount of money has been specified, that is, if RightsManagement.Conditions.Price.Amount has been included.
Not Allowed	Elements which are Not Allowed can not be included. This can be used to prohibit the use of elements that we initially Optional or Conditional.

As also shown above, a single element may occur in more than one place in the hierarchy. When an element occurs in more than one place, its obligation may change depending on the its position. The previous table is repeated here, now including obligation information.

Element Name	Contextualized Definition  & Comments	Obligation
Characteristics	Non-contextualized features of the resource.	M
|--Language	The human language of the intellectual content or the application interface.	M
|--Description	A textual description of the content of the resource.	M
|--Concept	The idea or notion presented in the resource. Examples: invariance, evolution, proof, taxonomy, operator, epoch.	O
|--|--Description	A textual description of the concept.	O

In this arrangment the element Description occurs twice, with differing obligations (Mandatory under Characteristics and Optional under Characteristics.Concept).

Constraint 2: List

Listing defines if an element, with its contents at a specifical location in a hierarchy, may be repeated, and if so, if the order is significant.

Schemas

An arrangement of metadata elements with associated obligations is called a "schema":

arrangement of elements + obligations = schema

The IMS metadata specification defines five schemas. Each serves a different purpose.

Schema Name	Description
Master	The Master Schema contains many useful combinations of elements. Many of these are optional but are included to indicate exactly where such properties would be located.
Base	The minimum set of elements. It defines a minimum set of properties for metadata interchange.
Item	The Item schema is intended to describe a single learning resource such as a picture, an audio clip, a video clip, a text block, and HTML file). An item is typically a single file of formats such as *.gif, *.html, *.jpg or *.txt.
Module	When several Items (like images and HTML files) are combined to form a more complete educational unit, this unit is referred to as a Module. The Module schema is intended for the description of Modules.
Tool	A Tool is different from an Item or Module in that it provides some kind of functionality, like a word processor, calculator, or HTML editor. The Tool schema is intended for the description of Tools.

The Master schema is so called because it contains the master arrangement of elements. The other four schemas are made up of sub-sets of the master arrangement and different obligations.

Customizing the IMS Metadata Specification

There are a number of ways that the IMS metadata specification can be customized or extended.

1. Change the obligation of elements in the Master schema
2. Arrange existing elements in new ways
3. Introduce new elements.

The specification supports security, privacy, commerce, and evaluation, but only to the extent that meta-data properties will be provided for specifying descriptive tokens related to these areas; the specification will not concern itself with how these features are implemented. We expect these specifications will conform to, integrate with, or reference existing open specifications and existing work in related areas. For example core properties of Learning Resources will be coordinated with or may simply defer to, the efforts to standardize content resources in general.

Definitions

Abstract Data Type (ADT)

A fixed or defined block of information. Specifics of the implementation are not always defined.

Crosswalk:

Mapping from one system to another.

Data Type

Basic element of information, a single value. 

Dictionary:

"(n.) 1. A reference book containing an explanatory alphabetical list of words, as: a. A book listing a comprehensive or restricted selection of words of a language, identifying usually the phonetic, grammatical, and semantic value of each word, often with etymology, citations, and usage guidance, and other information...." (American Heritage Dictionary of the English Language, 1973)

Extend:

To change by adding or increasing.

Grammar:

"(n.) 1. The study of language as a systematically composed body of words that exhibit discernible regularity of structure (morphology), and arrangement into sentences (syntax), sometimes including such aspects of language as the pronunciation of words (phonetics), the meaning of the words (semantics), and the history of words (etymology). ... 2.b . The system of rules implicit in a language, viewed as a mechanism for generating all sentences possible in that language. ..." (American Heritage Dictionary of the English Language, 1973)

Lexicon:

terms that are specific for a particular domain or community.

Localization:

To make specific for a particular community, region, or domain. There are two aspects to meta-data localization: terms and values. Terms have labels (or "property captions") and definitions used to describe the terms within a meta-data structure. Localization is the support of local descriptive terminology for terms. For example, an institution may wish to use the name "resource summary" instead of "abstract" for general.description in the structure. Values are vocabularies and taxonomies. A localized value set (or more formally, "value domain") has terms relevant to the specific user community.

Set

Herein, a meta-data structure.  

Taxonomy:

A structured arrangement of terms, for instance terms structured in a hierarchy.

Vocabulary:

A controlled list of terms.

We shall use "dictionary" to refer to a group of defined elements. The "grammar" specifies how those elements may be used. Unfortunately, there is a certain amount of circularity within this description: in order to define the elements, it is necessary to refer to the grammar, and vice versa. Basically, elements have contents. The grammar prescribes how those contents may be constructed and manipulated.

IMS Meta-Data

Introduction

In order to describe a learning resource with meta-data, we begin by creating a structure of the description. A learning resource may be described by a number of different terms, such as its title, its author, its creation date. These terms may just be used as a jumbled list of descriptive labels about the resource. However, a more useful approach is to give a structure to these terms. This has two advantages: 1) the structure facilitates reading the meta-data because it has an overlay of organization to its collection of terms, and 2) the same term can have a different meaning depending on where it falls within the defined structure.

As an example of the first advantage, a collection of 30 descriptive terms about a resource is much easier to comprehend when it is broken down into categories of 4 or 5 terms each. For example, there may be a General category that holds only objective labels to identify a resource, such as it's Identification number or Title.

As an example of the second advantage for creating a meta-data structure, a descriptive term may be used in multiple categories in order to convey different concepts. The description of Creator means something different when it refers to a Learning Resource versus when it refers to the Meta Data label itself. One term refers to who created the learning resource; the other term refers to who created the meta-data associated with this resource. This term may or may not identify the same person.

Dictionary

A dictionary of elements can be defined. Elements are to have definitions that are distinctly differentiated. The definitions are to be as non-overlapping as possible. This is called "orthogonality". Well-differentiated definitions prevent semantic ambiguity within structures. The elements create the context for their contents. The elements have clearly stated meanings that do not depend upon context. For instance, a description is "Textual information about something. " There are four general types of elements:

Categories

Semantic Elements

Abstract Data Types

Data Types

Elements have three (3) fixed defining attributes:

• Contents
• Definition
• Usage

Contents:

The permissible content types of an element type. Each of the dictionary types has specific containment rules. The specification of contents for an element type are its containment rules. The concept of containment is discussed below.

Definition:

A non-contextualized definition. The definition is to be short and general purpose. For example the element "Description" may have the definition of "Textual information about something. "This can be applied to anything: a resource, a subject, a role, etc. The semantic element "Date" has the definition of: "A calendar date."

Usage:

The element type(s) in which the element type may be contained. This is not strictly required, as the usage can be deduced from the permissible contents of all element types. It is included for completeness.

Elements may also have variable defining attributes. These are attributes that are defined within a semantic structure, and may differ for a given element as a function of its particular context. Not all instances of elements must use all variable attributes. Variable attributes will be explained more fully within the grammar, below. Some standard variable attributes are:

List:

Specifies the listing usage for the particular content block of an element.

Obligation:

Specifies if an element (and consequently its content block) must be used and have valid values.

Property Caption:

Provides a human-readable label for a specific locus within a structure.

Property Definition:

Provides a human-readable definition for a specific locus within a structure. This definition reflects the complete context of the loci within the structure.

---

Categories

Category elements Are the highest level in the hierarchical structure. Category elements provide the context for their contents. Category elements are a special case of semantic element. Example category elements are General and Technical. They are usually called "Categories"  

Contents:

Category elements contain only semantic elements. 

Usage:

Nothing may contain a category element. In XML the root element contains only category elements. 

Definition:

Each category has a definition. This definition sets the context for all of a category's contents. The standard definition is in English. Additional definitions in other languages may be supplied locally.  

---

Semantic Elements

Semantic elements provide definitional loci within a structure. Semantic elements provide the context for their contents. Semantic elements are usually referred to simply as "elements". Examples of meta-data semantic elements are description, title, definition and keywords.  

Contents:

Semantic elements may contain:

• Semantic elements (elements)
• Abstract Data Types
• Data Types (unlikely)

Semantic elements may NOT contain category elements.

Usage:

Semantic elements may be contained by:

• Category elements
• Semantic elements (elements)
• Abstract data types (ADTs) (?)

 

Definition:

Each semantic element has a context-free definition. This definition sets the context for all of a element's contents. The standard definition is in English. Additional definitions in other languages may be supplied locally.  

---

Abstract Data Types

Abstract Data Types (ADT) have specified contents that may or may not be extended, depending upon domain rules. An ADT is a predefined set of information. The ADT information set may contain only a single data value, or it may contain multiple or complex data. An ADT could be an object that is queried for its information. In this description, the contents of an ADT are described as a structural implementation.

Abstract data types contain a substructure of information. The ADT is NOT a data type. The intent is to create a fixed structure for reuse. For example, Person can be an ADT. It may have a name (another ADT), email (with a data type string), an affiliation, and so forth. Name may have several pieces: firstname, middlename, prefix, surname. Each of these would be of data type string. Affiliation could have a structure. ADTs can be (re)used in many places: a person could be a contributor and a contact Affiliation could have an organization ADT. Organization can be used in many loci in meta-data templates.

ADTs create consistent low level structures that are stable. A template may call out no more than the ADT, using the defined substructure by reference. Limiting ADTs to a fine-grained level maintains the basic generative nature of the hierarchical structure system.

The meta-data structures system manages controlled templates and element dictionaries within registries. As the ADTs are part of the dictionary, this ensures stability. ADTs are one type of control created in the meta-data structures system. Abstract Data Types provide the context for their contents as does any other element.  

Contents:

Abstract Data Types may contain: 

• One or more ADTs
• A single Data Type
• Semantic elements (?)

Usage:

ADTs may be contained by: 

• Category elements (categories)
• Semantic elements (elements)
• Abstract Data Types

Definition:

Abstract data types have definitions that specifically define the information structure they contain. 

---

Data Types

Data Types (DT) are the primitive value definitions, for example string, integer, and boolean. 

Contents:

Values. A DT represents only a single value. Compound values are contained within ADTs.  

Usage:

DTs can be contained within:

• ADTs

Definition:

DTs define the specified data types represented by their values. 

Grammar

The grammar defines how structures are created and interpreted. A major purpose of the grammar is the creation of model structures or "templates". It is also possible to use the grammar to create "free" instances of information not contained in a particular template. A free instance is unregistered. Registration will be discussed elsewhere. This document is primarily oriented toward the specification and use of meta-data structure templates. These templates may be registered. Before turning to a description of the structures, the concepts of content definition, context, containment, blocks, list obligation, and extension shall be presented.

It is useful to provide occasional examples. An XML syntax will be used for these examples. This does not mean that implementations are to be constrained to XML or to this particular use of XML. XML will also be used to explain concepts, it being more readable (to this author) than BNF. generally within this document examples will be taken from meta-data.

---

Content Definition

An element within a structure defines its contents. Within an XML structure, this may have the form of:
 
   <A>
      Contents
   </A>
 
The contents of an element at a specific locus in a template structure define the next level down in a hierarchy. The contents of a data type may define an allowable vocabulary. For example, within a structure template a specific vocabulary may be defined:
 
   <A>
      <String>
         low,
         medium,
         high
      </String>
   </A>
 
Similarly, a vocabulary may be referred to:
 
   <A>
      <String>
         http://www.IMSProject.org/disciplines.html
      </String>
   </A>

---

Context

The hierarchical structures of this system use elements with brief definitions to provide the context for interpreting each element's contents. For example the meaning of description in the structure:

   <characteristics>
      <description>
   <characteristics>

is interpreted to mean the general description of the resource. It is the abstract or summary information about the entire resource. On the other hand

---

Containment

An element contains content. It may contain a single piece of information or a complete sub-structure of information. In containing its content, it provides the context under which the content is to be interpreted. For example:  

		<Create>
		   <Date>
		      <String>
		         1998-11-12
		      </String>
		   </Date>
		</Create>

means that 12 Nov. 1998 (as a string) is the date of creation. Containment can be "read" upward with the form as "Y of X" for the structure of:

		<X>
		   <Y>
		</X>

This interpretation by containment is a key component of the meta-data structure system. The contained contents are called a "block".

---

Blocks

The content of an element (i.e., category, semantic element, ADT or data type) is called a "block". A block is a logical entity. A block may consist of a single DT value or a structure. Data types' blocks contain only a single value. A block is a term of reference. A block maintains the definition of the element that contains it. A contained block has the form of:

		<A>
		   [BLOCK]
		</A>

For example, the following structure (as an XML fragment) contains several blocks:

		<A>
		   <B>
		      Q
		   </B>
		   <C>
		      <M>
		         R
		      </M>
		      <N>
		         S
		      </N>
		   </C>
		</A>

Element B has a simple block of Q. Element C has a compound block of:

		<M>
		   R
		</M>
		<N>
		   S
		</N>

Element A has a complex block with the sub-structure of:

		<B>
		   Q
		</B>
		<C>
		   <M>
		      R
		   </M>
		   <N>
		      S
		   </N>
		</C>

A block does not (and usually won't) need to be specifically enumerated in a structure model with the designation of "BLOCK", but may be enumerated in an instantiation of a structure.

A block is a structure that is controlled by the containing element. One type of control is the list attribute of the containing element.

---

List

List refers to the number and order in which a block can be repeated in an instantiation. It does NOT refer to the ordering of the components within a block. In this system, the order of items that are contained in a block does not have meaning. Listing relates to repeated blocks. Listing actually has two components: cardinality (length) and ordinality (order). Cardinality would specify the number of items permitted in a list. Ordinality would specify whether or not the list was order sensitive. There are two types of ordinality: ordered and unordered. These two components are combined into a single attribute of list. There are three possible list types:

None (no list permitted)

Ordered

Unordered

This does not allow the specification of limited list lengths. This additional functionality is abandoned in favor of parsimony. Instead of the term "None" for the list attribute in which no list of the content block is permitted, the term "Single" (or tersely, "sngl") is used. A list of a single component is not a list except in the most formal sense of the term. An element always has a list attribute for its block. If the list attribute is omitted, the default is "single". Within the IMS and ARIADNE Meta-data systems, a default list type of "unordered" is normally provided.

The definition of a structure model implies that each element (i.e., category, semantic element, ADT) contains a block. The element's list attribute defines how the block is to be used as a list item in the instantiation. Thus, the implied <BLOCK> contained in A is used as the list item:

	<A I_List="Unordered">
	   <BLOCK></BLOCK>
	</A>

means that the block may be repeated within A in the instantiation, with different values in the block each time:

	<A>
	   <BLOCK>Q</BLOCK>
	   <BLOCK>R</BLOCK>
	   <BLOCK>S</BLOCK>
	</A>

The block structure is fixed for each repetition, only the data type values are changed. Q, R, and S, above, are the same structure with different data values. If the block contains only one element, then the <BLOCK> element does not need to be used in the instantiation. For example, if element A contains element B as its only content, then B comprises the block of A. The list attribute of A in the structure model defines how B may be used in a list:

	<A I_List="Unordered">
	   <B></B>
	</A>

means that B, the block, may be repeated within A in the instantiation:

	<A>
	   <B>Q</B>
	   <B>R</B>
	   <B>S</B>
	</A>

In this example, order is not important. If it were an ordered list, each block (or single element block) could contain a num="n" attribute. The representation of the list ordering is an implementation issue, presented here only as an example.

The block maintains the identity of the containing element, acting as its surrogate. Thus, the example above is virtually an unordered list of:

	<UnorderedList>
	   <A>
	      <B>Q</B>
	   </A>
	   <A>
	      <B>R</B>
	   </A>
	   <A>
	      <B>S</B>
	   </A>
	</UnorderedList>

The specific enumeration of BLOCK need only be used in instantiations when possible confusion in interpretation may arise. The element BLOCK is not used in structure models. The use of nested listing can provide rich, and potentially confusing, structures in instantiations. Hence, instantiations should specifically denote blocks whenever confusion is possible.

---

Obligation

Obligation specifies whether or not the contents of an element (hence a block) must be present. There are four possible states of obligation:

1. Optional (O)
2. Conditional (C)
3. Mandatory (M)
4. Not Allowed (N)

Obligation constrains the requirement to populate the content of an element. The relative strength of constraint is:

O < C < (M = N)

Mandatory cannot be substituted for Not Allowed, but has the same level of constraint. Not Allowed permits a structure to prohibit the use of a particular element at a locus within a structure. This is important in the context of extension.

It is specifically noted that a substructure (block) that is optional that contains mandatory elements is to be interpreted that if the optional substructure is used in the instantiation, then the mandatory substructure elements must be used. The obligation attribute is a logical "switch" on the entire block.

If an element's obligation is mandatory in a template, then at least one instance of its terminal data type values must be mandatory, either directly or by virtue of a conditional state. It is invalid (and logically inconsistent) to have an element declare its contents to be mandatory if none of its contents resolve to mandatory. This requirement, propagated up a hierarchy, determines the validity of a mandatory condition at any given locus.

Structures

Structures of meta-data are created from the dictionary elements (categories, elements, abstract data types, and data types). There are two states of a structure: template and instantiation. The template is the structure model. It includes the element attributes (either directly or by reference). It defines the mandatory part of the structure, it may indicate specialized vocabularies and taxonomies for specific loci. It will indicate the specifics of the data types at each loci (e.g., date as formatted per ISO 8601). The template will specify standard extensions, using the "optional" obligation. The template may define the allowability of new extensions at specific loci. Templates may be controlled, for instance through a registry system. The instantiation is the actual set of meta-data. It is created from the template.

Within the current specification, a structure is comprised of a hierarchy of elements. The top level must always be a Category element. The bottom of the structure, the terminal leaves, must always be Data Types. A particular place in a structure is a locus. Meta-data structures are interpreted from the top level downward, with each locus providing the basis for the interpretation of its contents. Thus, Date may be one element contained by a particular locus of Create. This is interpreted as the creation date. The same element may appear at multiple loci within a structure. Its contents may be different at each locus. This is a significant differentiation from object oriented designs (OOD) in which each element has predefined contents.

 
 
General form of structures illustrating containment rules.
 

If the block that is defined in a structure template is not present in the instantiation (e.g., the optional is not exercised), then the containing element does not need to be present in the instantiated structure. If the block is empty, the element contents are empty, creating an empty element. Within the IMS system, as implemented in XML, elements do not convey meaningful resource information within the attributes of the element, only within the contents of an element.

 

Extension

There are several types of extension of a structure:

1. Changing constraints
2. Extending a structure using standard elements
3. Extending or changing a content vocabulary
4. Extending a structure using newly defined elements

Any meta-data can be extended. A conforming tool may ignore extensions that are not defined within a template. Ignored extensions shall be preserved. Extensions in templates can be created as follows:

1. Changing constraints

Element attributes define the control over the respective contained block. These are the constraints on the block. An extension may increase the level of constraint, e.g., the obligation attribute may increased from "optional" to "conditional" or "mandatory"; the extensibility may be increased from "yes" to "no". The structure template is not changed by changing constraints.

Obligation and Exstensibility constraints may be modified to be more restrictive, but the List constraint may not be changed:

a) It is permissable for an entity to require that an optional IMS metadata element be mandatory (obligation constraint);

b) It is not permissable for an entity to change the requirement about the valid type of list of values an element can contain, where the list types are: single value, unordered list of values, ordered list of values (list constraint);

c) It is not permissable for an entity to change the requirement about the valid type of list of elements an element can contain (list constraint).

2. Extending a structure using standard elements

Categories, (semantic) elements, and ADTs contain elements. The specific contents of an element at a specific locus within a structure may be increased by adding elements from a standard dictionary of elements, within the element type containment rules.

Extension of a structure may be accomplished:

a) An entity may extend a set of elements contained by a parent element by adding an element(s) from an existing collection of elements.

3. Extending or changing a content vocabulary

A specific vocabulary may be included, directly or by reference, at a specific locus of a structure template. This vocabulary may be extended or replaced.

A vocabulary or taxonomy may be changed:

a) An entity is permitted to change the list of allowable values of an element.

4. Extending a structure using newly defined elements

The element dictionary may be extended. New elements should not have definitions that significantly overlap with the definitions of any existing element. A registration authority may control these extensions. These new elements may be used to extend the contents of existing elements.

A structure may be extended with new elements:

a) An entity may extend a set of elements by adding a new element(s).

Conformance

A conforming tool may ignore extensions that are not defined within a template. Ignored extensions shall be preserved.  

Registration

A structure template may be registered or unregistered. A registered structure has been fully defined and accepted by some authority through a well-defined process. A registered structure is under a state of control. The registration process is outside of the scope of this specification. The registered structure, including its defining dictionary elements, is available for reference to create or interpret instantiations. A registered structure may be extended within the limits defined by the element attributes within the structure. New structures may be defined that are derived from (hence are "children of") existing registered structures. Derived structures may extend the parent structure in permitted manners. Derived structures may not remove or override components from the parent structure. Derived structures may only increase the levels of constraints of attributes in the parent structure (e.g., from changing an obligation from "optional" to "mandatory"). Derivation from a registered structure insures interoperability at the level of the parent structure for all structures derived from that structure.

An unregistered structure may be defined by an entity for its own use. It may be derived from a registered structure, and contain locally significant extensions that are not registered. There may be local control of these structures, creating a local registration authority that is not itself registered.

Element Dictionary

The dictionary is comprised of four parts to define four different components of the meta-data schemas:

• Categories
• Data Elements
• Abstract Data Types
• Data Types

Each of these components is an element. The names reflect the differences between the component types.

The dictionary definitions below are de-contextualized to the greatest degree possible, as the structure of the meta-data provides the context for interpretation. De-contextualized definitions support the ability to create new meta-data properties from standard parts such that the meaning of these new properties can be readily inferred from contexts.

---

Categories

Categories are special types of Data Elements (see below). Only Categories can be used at the top level of the meta-data structure. A Category contains a collection of Data Elements. The Categories provide the main context for the data elements contained within the category. The category provides a common context for the data elements it contains. Categories and elements have meanings or definitions.

Annotation

Evaluations.

Characteristics

Non-contextualized features.

Educational Use Dependent

Features that need to be interpreted according to the educational use.

General

Basic reference.

Life Cycle

Characteristics related to the different phases.

Meta-Meta-Data

Characteristics of the description rather than the resource.

Relation

Characteristics in relationship to another entity.

Rights Management

Features that need to be interpreted according to use.

Technical

Technical features.

---

Data Elements

Data Elements, normally called "elements" are the principal semantic elements. They, and categories, provide the context for interpretation of their contents. Categories and elements have meanings or definitions.

Amount

A monetary value

Attribution

Citation of a source. For example, if one resource is encapsulated in another, the top level source may attribute the source of the encapsulated resource.

Approach

 A logical structure.

Catalog Entry

Designation given to the resource.

Code

A designation that requires a key for interpretation.

Concept

A concept is something conceived in the mind. An abstract or generic idea generalized from particular instances.

Conditions

 The legal or economic requirements.

Contact

An active entity.

Contribute

Involvement in the creation or edition.

Coverage

>From the Dublin Core definition: "The spatial or temporal characteristics of the intellectual content of the resource. Spatial coverage refers to a physical region (e.g., celestial sector); use coordinates (e.g., longitude and latitude) or place names that are from a controlled list or are fully spelled out. Temporal coverage refers to what the resource is about rather than when it was created or made available (the latter belonging in the Date element); use the same date/time format (often a range) [Date and Time Formats (based on ISO 8601), W3C Technical Note, http://www.w3.org/TR/NOTE-datetime] as recommended for the Date element or time periods that are from a controlled list or are fully spelled out. "

Create

Origination and editing.

Date

A calendar date.

Description

Textual information about something.

Difficulty

How hard it is to work through an entity.

Discipline

A specific knowledge domain.

Duration

Time interval.

Educational Objective

Learning goal.

Format

Technical data type.

Granularity

A relative size or place in a hierarchy, for instance the level of curricular scope.

Identifier

A discriminative label.

InstallationRemarks

Information useful in the installation on the users platform.

Interaction Quality

The level of interaction between the user and the entity.

Keywords

One or more words exemplifying the meaning or value .

Kind (relation)

The nature of a relationship.

Language

The human language of the intellectual content or the application interface.

Level

A point on a scale.

LocSpec

A location or a method that resolves to a location.

Maximum Version

The largest number instance of an entity.

Minimum Version

The oldest number instance of an entity.

Monetary Unit

The unit of currency.

Operating System

An underlying service infrastructure.

Organization

A legal entity.

OSRequirements

Needs relating to operating system.

OtherPlatformRequirements

Needs in addition to OSRequirements.

Person

A specific human being.

Prerequisite

Requirement that needs to be satisfied before use.

Presentation

The mode of presentation.

Price

The price in money, which may be free (0).

Publish

Making the entity available in its present form.

Resource

Usable entity.

Reciprocity

Requiring that any rights given to others to use a resource allow the provider to use any resource incorporating the resource on the same basis. For example, if an owner of a resource allows another entity to incorporate that resource into another resource for free, the owner of the free resource can use and/or distribute the incorporating resource for free.

Role

Kind of involvement.

Schema

A specific structure of information.

Semantic Density

A relationship between the amount of content and the amount of entity. High semantic density means that a lot of information is concisely presented.

Size

The number of units used for storage.

Source

Entity that an entry belongs to.

Structure

Structure describes how the material is organized.

Support

Assistance.

Taxon

A node from a taxonomy.

TaxonPath

A taxonomic path in a taxonomy; this is a path from a more general to a more specific entry in a taxonomy.

Terminate

The cessation of access.

Title

Name. This can be a brief description.

Type

The category of the entity.

Unit of Pricing

The unit to which the price applies.

Validation

State of verification of the entity.

Version

An indicator of the edition.

---

Abstract Data Types

An Abstract Data Types (ADT) is a particular type of element. It contains specified information. An abstract data type (ADT) is an information construct. An ADT contains information that may have one or more values. The information may be structured. The information content of an ADT may contain mandatory and optional components. The information content of an ADT may be extended within the limitations imposed by the more general meta-data specification. The order of content components is not significant when there is more than one content component. Not all structure components are necessarily mandatory in obligation. Abstract data types have a prefix of "A_". The actual value types within an ADT are Data Type Primitives.

For a meta-data binding in XML, the values will be in string format. The attributes of "len" and "code" define the maximum string length and the string coding respectively. They do not define the format of the data as stored in a repository, as data storage implementation is outside of the scope of this specification. The len and code attribute may be changed from the defaults.

The attribute List defines how many times and the ordering of the contents of an ADT. List can have one of three values: 1) Sngl (single), meaning no list, only a single value; 2) Unord (Unordered), an unordered list; and 3) Ord (Ordered), an ordered list. The default is Unord. In most cases, the ADT list attribute is set to Sngl (no list); the default of Unord is used for consistency with the other elements in the dictionary.

Index of ADTs

• A_Boolean
• A_Coverage
• A_Date
• A_Decimal
• A_Entry
• A_EntryID
• A_Label
• A_Format
• A_Identifier
• A_Integer
• A_LangString
• A_Locale
• A_LocSpec
• A_Name
• A_Organisation
• A_Person
• A_Source
• A_SourceString
• A_Timespan
• A_Vocabulary
• A_Taxon
• A_FirstName
• A_MiddleName
• A_Prefix
• A_Suffix
• A_Surname
• A_String
• A_ZipCode
• A_Street
• A_City
• A_County
• A_State
• A_Country
• A_Telephone
• A_FAX
• A_Communications
• A_URL
• A_Address
• A_Designation

A_Boolean

Description

Yes or no or 1 and 0.

Attributes

List="Sngl"

len="1": maximum length in bytes (default).

Code="": Default is 8 bit ASCII.

Values

D_Boolean. 1 = Yes, 0 = No.

XML Example

 

A_Coverage

 

Description

Time span or geographic area.

Attributes

List="Sngl"

len="32": Maximum default Length of D_String in Bytes.

Code="": Default is 8 bit ASCII.

Values

D_String: alphanumerics with non-HTML symbol punctuation.

XML Example

<A_Coverage>
  18th Century
</A_Coverage> 

A_Date

Description

A Calendar Date.

Attributes

len="10": Max. default length of D_String in Bytes.

Code="": Default is 8 bit ASCII.

Values

D_String of YYYY_MM_DD per W3C (ISO 8601). May be extended to include time.

XML Example

<A_Date>
  1998_12_25
</A_Date>

 

A_Decimal

Description

Decimal number that may have digits to the right of the decimal point, e.g., 1.04.

Attributes

len="8": Max. default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

D_Decimal

XML Example

<A_Decimal>
  1.04
</A_Decimal>

 

A_Entry

Description

A combination of an A_EntryID and an A_Label. A_EntryID is an identifier for the entry. A_Label describes the entry. Either, but not both, A_EntryID or A_Label may be blank.

Attributes

List="Sngl"

Type="": Type of entry (e.g., LOC). Default is null.

Values

A_EntryID: Obligation="Conditional". Mandatory if no value for A_Label, otherwise optional. List="Sngl".

A_Label Obligation="Conditional". Mandatory if no value for A_EntryID, otherwise optional. List="Sngl".

XML Example

<A_Entry>
  <A_EntryID>
    17
  </A_EntryID>
  <A_Label>
    Differential equations
  </A_Label>
</A_Entry>

 

A_EntryID

Description

EntryID is an identifier for an entry.

Attributes

List="Sngl"

len="32": Max. default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

D_String of alphanumerics with non-HTML symbol punctuation.

XML Example

<A_EntryID>
  103.65
</A_EntryID>

 

A_Label

Description

A Label is a descriptive word or phrase.

Attributes

len="64": Max. default in Bytes.

Code="": Default is 8 bit ASCII.

Values

D_String of alphanumerics with non-HTML symbol punctuation.

XML Example

<A_Label>
  Mathematics
</A_Label>

 

A_Format

Description

MIME or other technical designation of format. MIME is to be used unless an appropriate MIME type does not exist. May include non-digital formats such as videotape, painting, and book.

Attributes

len="16": Max. default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

D_String of MIME, ISO-8859-1.

XML Example

<A_Format>
  txt
</A_Format>

 

A_Identifier

Description

A unique reference.

Attributes

List="Sngl"

len="64": Max. default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

Alphanumerics

XML Example

<A_Identifier>
  978007890797541
</A_Identifier>

 

A_Integer

Description

A whole number, base 10.

Attributes

len="16": Max. default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

A string composed of a sign (+,-) and the digits 0-9. If there is no sign, "+" is the default.

XML Example

<A_Integer>
  32768
</A_Integer>

 

A_LangString

Description

A combination of a value from A_Locale and a string, A_String.

Attributes

Values: Contents of

A_Locale

A_String (an explicit string.)

XML Example

<A_LangString>
  <A_Locale>
    en_US
  </A_Locale>
  <A_String>
    Introduction to Algebra
  </A_String>
</A_LangString>

 

A_Locale

Description

A language and a country.

Attributes

List="Sngl"

len="5": Length in Bytes.

Code="": 8 bit ASCII.

Values

String concatenation constructed per JDK 1.1 (http://chromium.chemie.fu-berlin.de/JavaTutorial/intl/datamgmt/locales.html) of a lower case 2-character language code (ISO 639:1988, http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt) and an upper case 2-character country code (ISO 3166, http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html) separated by a hyphen or underscore, e.g. de_CH, en_US, fr_FR. It is permissible to use only the language code without the country code.

XML Example

<A_Locale>
  en-US
</A_Locale>

 

A_LocSpec

Description

A location or something that resolves to a location, e.g., URL, URN, DOI, Dewey Decimal #, physical location.

Attributes

List="Sngl"

len="128": Max. default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

String

XML Example

<A_LocSpec>
  http://www.imsproject.org/DN/techdev/forum.html
</A_LocSpec>

 

A_Organisation

Description

An organization.

Attributes

Values: Contents of

A_Identifier: Obligation="Optional"; List="Sngl"

A_Label: Obligation="Mandatory"; List="Ord"

A_Address: Obligation="Optional"; List="Sngl"

A_Communications: Obligation="Optional"; List="Sngl"

XML Example

<A_Organisation>

<A_Identifier>

  1234567890

</A_Identifier>

<A_Label>

<BLOCK num="1">

  Acme Educational Products

</BLOCK>

<BLOCK num="2">

  K-12 Division

</BLOCK>

</A_Label>

<A_Address>

<A_Street>

  101 First Street

</A_Street>

<A_City>

  Greentown

</A_City>

<A_State>

  Illinois

</A_State>

<A_ZipCode>

  12345

</A_ZipCode>

<A_Country>

  us

</A_Country>

</A_Address>

<A_Communications>

<A_Telephone>

  111.123.4567

</A_Telephone>

</A_Communications>

</A_Organisation>

 

A_Person

Description

A person.

Attributes

List="Sngl"

Values. Contents of:

A_Indentifier: Optional; List="Sngl"

A_Name: Mandatory; List="Sngl"

A_Organisation: Optional; List="Ord"

XML Example

<A_Person>
  A_Name
</A_Person>

 

A_Source

Description

A combination of an A_Label (name of the source) and/or a location of type A_LocSpec (e.g., [NASA, www.nasa.gov]).

Attributes

Values

A_Label: Obligation="Conditional", Required if no valid value for A_LocSpec; List="Sngl".

A_LocSpec: Obligation="Conditional", Required if no valid value for A_Label; LIst="Sngl".

XML Example

<A_Source>

<A_Label>
  LOC
</A_Label>

</A_Source>

 

A_SourceString

Description

A combination of a Source and a String.

Attributes

Values: Contents of

A_Source: Obligation="Mandatory"; List="Sngl"; len="16"

A_String: Obligation="Mandatory"; List="Sngl"

XML Example

<A_SourceString>

<A_Source>
  NASA
</A_Source>

<A_String>
  Cosmology
</A_String>

</A_SourceString>

 

A_Timespan

Description

A duration.

Attributes

List="Sngl"

len="16": Max default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

Per ISO8601.

XML Example

<A_Timespan>
  1:30
</A_Timespan>

 

A_Vocabulary

Description

A set of values, specific for a data element.

Attributes

List="Sngl"

len="n": Length in Bytes.

Code="": Default is 8 bit ASCII.

Values

Alphanumeric String.

XML Example

<A_Vocabulary>
  Physics
</A_Vocabulary>

 

A_Taxon

Description

A node in a taxonomy.

Attributes

List="Sngl"

len="32": Default maximum length in Bytes.

Code="": Default is 8 bit ASCII.

Values

An A_EntryID and an A_String. If no A_EntryID, a T_String data type can be used as content without the A_String.

XML Example

<A_A_Taxon>
  Algebra
</A_A_Taxon>

 

A_FirstName

Description

A person's first name, e.g., Thomas.

Attributes

len="16": Maximum default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

String of alphanumerics with non-HTML symbol punctuation.

XML Example

<A_FirstName>
  Thomas
</A_FirstName>

 

A_MiddleName

Description

A person's middle name, e.g., Dimock.

Attributes

len="16": Maximum default length in Bytes.

Code=""Default is 8 bit ASCII.

Values

String of alphanumerics with non-HTML symbol punctuation. May use abbreviation, e.g., D.

XML Example

<A_FirstName>
  Dimock
</A_FirstName>

 

A_Prefix

Description

A person's name prefix to the surname, e.g., von.

Attributes

len="16": Maximum default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

String of alphanumerics with non-HTML symbol punctuation.

XML Example

<A_Prefix>
  von
</A_Prefix>

 

A_Suffix

Description

A person's name suffix to the surname, e.g., Jr., and/or other designation, e.g., Ph.D..

Attributes

len="8": Maximum default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

String of alphanumerics with non-HTML symbol punctuation.

XML Example

<A_Suffix>
  Jr.
</A_Suffix>

 

A_Surname

Description

A person's name common to members of the same family, e.g., Graf.

Attributes

len="16": Maximum default length in Bytes.

Code=": Default is 8 bit ASCII.

Values

String of alphanumerics with non-HTML symbol punctuation.

XML Example

<A_SurName>
  Graf
</A_SurName>

 

A_Name

Description

A person's name.

Attributes

List="Sngl"

Values. Contents of:

A_Designation: Obligation="Optional"; List="Ord"

A_FirstName: Obligation="Optional"; List="Sngl"

A_MiddleName: Obligation="Optional"; List="Sngl"

A_Prefix: Obligation="Optional"; List="Sngl"

A_SurName: Obligation="Mandatory"List="Sngl"

A_Suffix: Obligation="Optional"; List="Ord"

XML Example

<A_Name>

<A_FirstName>
  Mark
</A_FirstName>

<A_MiddleName>
  A.
</A_MiddleName>

<A_SurName>
  Resmer
</A_SurName>

<A_Suffix>
  Ph.D.
</A_Suffix>

</A_Name>

 

A_String

Description

An explicit string. To be used when a string is to be one of more than one component of an ADT.

Attributes

len="255": Max. default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

String values per code.

XML Example

<A_String>
  Introduction to Mathematics
</A_String>

 

A_Street

Description

Local geopolitical or postal place designation.

Attributes

len="32": Max. default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

Characters per code.

XML Example

<A_Street>
  101 First Street
</A_Street>

 

A_City

Description

A geopolitical designation of a city, town or other municipality.

Attributes

len="32": Max. default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

Per code.

XML Example

<A_City>
  Greentown
</A_City>

 

A_State

Description

A constituent unit of a country.

Attributes

len="32": Max. default length in Bytes.

Code="": Default is 8 bit ASCII.

Values

Alphabetic characters per code.

XML Example

<A_State>
  North Carolina
</A_State>

 

A_County

Description

A constituent unit of a State.

Attributes

len="32": Max. default length in Bytes.

Code=": Default is 8 bit ASCII.

Values

String of alphanumerics per code.

XML Example

<A_County>
  Wake
</A_County>

A_ZipCode

Description

Postal ZIP Code.

Attributes

len="10": Length in Bytes.

Code="": Default is 8 bit ASCII.

Values

String of alphanumerics per code.

XML Example

<A_ZipCode>
  12345-6789
</A_ZipCode>

A_Country

Description

A national geopolitical designation.

Attributes

len="2": Length in Bytes.

Code="": Default is 8 bit ASCII.

Values

Two character country code.

XML Example

<A_Country>
  us
</A_Country>

A_Communications

Description

Electronic communications designations.

Values: Contents of:

A_Telephone: Optional; List="Sngl"

A_FAX: Optional; List="Sngl"

A_Email: Optional; List="Sngl"

A_URL: Optional; List="Sngl"

XML Example

<A_Communications>

<A_Email>
  tvgraf@someplace.edu
</A_Email>

</A_Communications>

A_Telephone

Description

A telephone number.

Attributes

len="16": Length in Bytes.

Code="": Default is 8 bit ASCII.

Values

Numbers with separators of "-" or "." as appropriate.

XML Example

<A_Telephone>
  01.919.555.1212
</A_Telephone>

A_FAX

Description

Facsimile telephone number.

Attributes

len="16": Length in Bytes.

Code="": Default is 8 bit ASCII.

Values

Numbers with separators of "-" or "." as appropriate.

XML Example

<A_FAX>
  01.919.555.1212
</A_FAX>

A_Email

Description

An email address.

Attributes

len="32": Length in Bytes.

Code="": Default is 8 bit ASCII.

Values

Alphanumeric characters per 8 bit ASCII.

XML Example

<A_Email>
  tvgraf@someplace.edu
</A_Email>

A_URL

Description

An Internet URL.

Attributes

len="n": Length in Bytes.

Code="8 bit ASCII": Standard ASCII.

Values

Characters per ASCII.

XML Example

<A_URL>
  http://www.imsproject.org
</A_URL>

A_Address

Description

A postal, geopolitical or other designation of location.

Attributes

Values: Contents of

A_Street: Obligation="Optional", List="Ord"

A_City: Obligation="Optional", List="Sngl"

A_County: Obligation="Optional", List="Sngl"

A_State: Obligation="Optional", List="Sngl"

A_ZipCode: Obligation="Optional", List="Sngl"

A_Country: Obligation="Mandatory", List="Sngl"

XML Example

<A_Address>

<A_City>
  Raleigh
</A_City>

<A_State>
  NC
</A_State>

<A_Country>
  us
</A_Country>

</A_Address>

A_Designation

Description

A title, position or honorific.

Attributes

len="16": Length in Bytes.

Code="": Default is 8 bit ASCII.

Values

String of characters per code.

XML Example

<A_A_Designation>
  Mr.
</A_A_Designation>

---

Data Type Primitives

Data have a single value as content. Data Type Primitives have a prefix of "T_". Data Type Primitives will be instantiated in the XML binding as strings. Data type primitives do refer to more basic data types, however. The definitions of those data types is maintained here. The XML examples are for illustrative purposes only.
 

T_Boolean

Description

A binary value.

Attributes

None.

Values

1, 0. 1 = Yes or True, 0 = No or False

String implementation

Len="1": maximum length (default)
Code="8 bit ASCII" (default)

 

T_Char

Description

A single character.

Attributes

Code="c": coding system. Default is 8 bit ASCII.

Values

A-Z, a-z, 0-9, ~!@#$%^&*()_+<>?`-=,./\[]{}|.

String implementation

Len="1": maximum length (default)
Code="8 bit ASCII" (default)

 

T_Decimal

Description

A real number that may be positive or negative.

Attributes

Mantissa, exponent.

Values

- inf. to + inf.

String implementation

Len="16": maximum length (default)
Code="8 bit ASCII" (default)

 

T_Integer

Description

An integer number that may be positive or negative.

Attributes

Bytes.

Values

+. - to extent limited by Bytes. Default is 2 bytes (16 bits).

String implementation

Len="16": maximum length (default)
Code="8 bit ASCII" (default)

 

T_String

Description

A string of characters.

Attributes

len="255": default maximum length in Bytes.

Code="": Default is 8 bit ASCII.

Values

Per code.

 

Meta-Data Types

There are several standard meta-data type sets, called "types". All IMS Meta-Data types are derived directly or indirectly from a Master Schema. There are four meta-data types:

• Base
• Item
• Module
• Tool

The Base type is derived from the Master Schema, and includes all mandatory properties from the Master Schema. The Item, Module, and Tool meta-data types are all derived from the Base type and include all elements in the Base type. The Item, Module and Tool types each extend the Base type by increasing selected obligation constraints (e.g., from optional to mandatory) in the Master Schema.

---

Master Schema

The fundamental schema or structure model is called the Master Schema. It contains mandatory and optional elements. Multiple schemas can be created. Each schema must be directly or indirectly derived from the Master Schema.

Master Schema Table

The Master Schema contains designations for many useful properties. Many of these are optional, but are included in the master schema to indicate exactly where such properties would be found. Derived types can increase the obligation constraint of selected optional properties to mandatory. This creates high interchange capabilities among meta-data repositories. It also allows search systems to function more effectively.

Table Description

The Schemas are represented below in tables. The table headings are:
 

• Name
• Contextual Definitions and Comments
• List
• Oblig(ations)
• Data Type
• Property Caption
• Extens(ible)

 

Name:

The element name of the data element or category

 

Contextual Definitions and Comments:

A human readable description of the interpretation of the element (data or category).  A meta-data tool may present this information to a user in a novice user mode. Contextualized definitions are optional. Contextualized definitions may be restated in other terms, e.g., other languages, to suit the user needs.

 

List:

The allowable list types that can be created under the element. There are three list types:

 

• Unord unordered list
• Ord Ordered list
• Sngl Single item only. No list or, conceptually, a list of one item.

Derived types can only be more restrictive in lists. Restriction strengths are: Sngl > Ord > Unord. There are no constraints on list lengths other than the Sngl, which has only one value.
 

Oblig(ations):

The obligation to have a valid ADT value. There are four obligations:

 

• M = Mandatory
• O = Optional
• C = Conditional upon the presence and/or value of some other element
• N = Not allowed, to specifically prohibit an element that may be optional in the Master Schema

 
Derived types can only be more restrictive in obligation. Restriction strengths are: N = M > C > O.
 

ADT:

The ADT is the Abstract Data Type (ADT) element that provides the actual values for the meta-data.

 

Property Caption:

Common human-readable label of property.  It is expected that a Meta Data tool will use this label for the user, when needed.  This will provide the user with the equivalent of a named field.  Property labels can also by synthesized from the context path of the abstract data type.  For instance, Characteristics.Discipline.Keywords is almost human readable as "Keywords of the Discipline of the Characteristics Category of the Resource".  Only data elements with abstract data types will normally have property labels. Property captions are optional. Property captions may be restated in other terms, e.g., other languages, to suit the user needs.

 

Extens(ible):

Defines whether or not the structure can be extended at the indicated location. Extension is accomplished by adding more data elements (elements, ADTs, DTs). Default is yes (Y).

 

Notation:

The Schema Tables use a context notation to indicate that one element is contained under another element. A term in the Name column with no characters before it indicates that it is a top-level element. Only Categories can be top level elements. A term with a pipe and two dashes (|--) indicates that the term is contained within the higher level term:

General

|--Indentifier

could be represented as

General

Identifier

or

General.Identifier

Appendices

Appendix A - Normative XML Binding

No current XML binding specified.

Appendix B - Normative HTML Binding

No current HTML binding specified.

Appendix C - Normative Types

Base

Minimal implementation of the IMS Meta-Data Master Scheme as the Base Schema. All other IMS compliant type schemas are derived from the Base type schema. The Base type defines a minimal set of properties for meta-data interchange among all derived type schemas. It is recommended that all new schemas be derived from the Base type.

Item

The Item extension set is intended to describe a single element such as a picture, an audio clip, a video clip, a text block, and HTML file). An element is typically a single file of formats such as *.gif, *.html, *.jpg or *.txt. An Item can contain a dataset. An Item can contain more than one file, but it is not intended to hold contents of a complete education nature. Items can be used to transport files or compound documents over the Internet, as containers of any type can be transported over the Internet. Items may be aggregated into larger, Modules. Aggregation is a powerful feature of IMS containers. The addition of the Resource Identifier, Rights and Price Code metadata properties reflect the potential for commerce in Item type containers.

Module

Module Type Schema Information

Publisher	IMS
Type	Module
Catalog ID	1.2
Version	1.0
Date	1998-07-07
Derived From	IMS 1.0:0.1
Description	The IMS Module type provides educationally relevant meta-data. The Module type also provides more optional and mandatory rights management properties than the Base type. The IMS Module type is derived from the IMS Base Meta-Data Type.

 

Tool

A Tool type is derived from a Base type schema.

Tool Type Schema Information

Publisher	IMS
Type	Tool
Catalog ID	1.3
Version	0.1
Date	1998-07-07
Derived From	IMS:1.0:0.1
Description	A Tool type provides a function for the user. Examples of the contents of a Tool type include a word processor, calculator, statistical analysis package, or composition guide. A Tool may contain a task specific tool, or a general purpose tool. A Tool can be nested within a Module, or vice versa. The Tool metadata set provides information on usage requirements and supports commerce. It does not contain educational information.  The IMS Table type is derived from the IMS Base Meta-Data Type.

Appendix D - Non-normative implementation guide

Title:

 

Document ID:

DID188

Purpose:

 

Summary:

 

Author:

Thomas D. Wason, IMS Project of EDUCAUSE, Raleigh, North Carolina, USA

Credits:

Learning Objects Metadata working group of the IEEE P1484 Learning Technology Systems Committee

Version Date:

12 January 1999 [1999_01_12]

30 January 1999 [1999_30_12]: Adjusted extensibilities.

24 February 1999 [1999_02_24]: Further adjusted extensibilities. Edit introductoory portion for clarity. Adjusted tables to remove extenibility attribute.

Version:

1.0

1.1

1.2

To Home Index