[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.]


IMS Meta-Data

Specification: Draft

Document Meta Data

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
    PropertyValue
    Creation Date3/1/99
    AuthorJohn 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: 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.

    ConstraintDescription
    ObligationThe requirement for including the specific element at the specific location in the hierarchy.
    ListThe 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 ObligationDescription
    MandatoryElements which are Mandatory must be included. For example, General.Title must always be included and have a valid value.
    OptionalElements 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.
    ConditionalElements 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 AllowedElements 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 NameDescription
    MasterThe 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.
    BaseThe minimum set of elements. It defines a minimum set of properties for metadata interchange.
    ItemThe 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.
    ModuleWhen 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.
    ToolA 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:
    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.


     
    Hierarchy of containment.
     
    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: 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
    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: 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:
    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
     
    Master Meta-Data Schema Table
    Based on the IEEE LOM V2.2 Working document
    jointly authored with ARIADNE
     
    Name Contextualized Definition
    & Comments
    Property 
    Caption
    List Oblig. ADT
    General Basic reference to the resource.   Sngl M   -
    |--Identifier A unique label for the resource. 
    note: This element can be transparent to the metadata creator. It can be created by the metadata management system.
    GUID Sngl M   A_Identifier
    |--Title Name given to the resource. Title Unord M   A_LangString
    |--Catalog Entry Designation given to the resource. Catalog ID Unord O   A_SourceString
    Characteristics Non-contextualized features of the resource.   Sngl M   -
    |--Language The human language of the intellectual content or the application interface. Language Unord M   A_Locale
    Can include N.A. (Not Applicable)
    |--Description A textual description of the content of the resource. Abstract Unord M   A_LangString
    |--Discipline A specific knowledge domain. Disciplines are ordered from the most relevant to the least relevant.    Ord M   -
    |--|--TaxonPath A taxonomic path in a specific taxonomy.  There may be different paths in the same or different taxonomy that describe a particular discipline.    Unord M   -
    |--|--|--Source A specific taxonomy Subject Taxonomy Sngl M   A_Source
    Example: {IMS Standard Subjects}
    |--|--|--Taxon An entry from a taxonomy that refers to the discipline. An ordered list of Taxons creates a taxonomic path, i.e "taxonomic stairway": this is a path from a more general to more specific entry in a taxonomy.  Subject Taxonomy Ord M   A_Entry
    |--|--Description A textual description of the discipline. Subject Description Unord O   A_LangString
    |--|--Keywords Keywords describing the discipline. Subject Keywords Ord O   A_LangString
    |--Concept The idea or notion presented in the resource. Examples: invariance, evolution, proof, taxonomy, operator, epoch.    Ord O   -
    |--|--TaxonPath A path in a specific taxonomy or ontology.  There may be different paths in the same or different taxonomy or ontology that describe a particular resource concept.    Unord O   -
    |--|--|--Source A specific taxonomy Concept Taxonomy Sngl M   A_Source
    |--|--|--Taxon An entry from a taxonomy (or ontology). An ordered list of Taxons creates a taxonomic path, i.e "taxonomic stairway": this is a path from a more general to more specific entry in a taxonomy.  Concept Taxon Ord M   A_Entry
    |--|--Description A textual description of the concept. Concept Description Unord O   A_LangString
    |--|--Keywords Keywords describing the concept. Concept Keywords Ord O   A_LangString
    |--Coverage The spatial or temporal characteristics of the intellectual content of the resource. Coverage Unord O   A_Coverage 
    example: {1700-1800}
    |--Type The kind of resource.  An ordered list with the most prevalent type first. Resource Type Ord O   A_Coverage
    examples: 
    {Advertisement 
    Assessment 
    Base (undifferentiated) 
    Collection 
    Dataset 
    Document 
    Example 
    Exercise 
    Media Resource 
    Message 
    Misc (ellaneous) 
    Reference 
    Schedule 
    Simulation 
    Tool 
    Tutorial }
    |--Approach Logical structure used in the resource. Approaches are listed with the most prevalent first. Pedagogy Ord O   A_Vocabulary
    example: {inductive, deductive}
    |--Granularity The relative size of the resource. Granularity Sngl O   A_Vocabulary 
    example: {curriculum, course, unit, topic, lesson, fragment}
    |--Structure Underlying organizational structure of the resource. Structure Sngl O   A_Vocabulary 
    example: {linear, hyperdimensional, branched, parcelled, atomic, multiple}
    |--Interaction quality Level of interactivity between an end user and the resource. Interactivity Level Sngl O   A_Vocabulary 
    example: {low, medium, high}
    |--Semantic density Relationship between the usage time and the amount of content presented in the resource. Semantic Density Sngl O   A_Vocabulary 
    example: {low, medium, high}
    Life Cycle Characteristics related to the different phases of the resource.   Sngl M   -
    |--Version The edition of the resource. Version Sngl M   A_Decimal
    |--Status The condition the resource is in. Life Cycle Status Sngl O   A_Vocabulary 
    example: {draft, final, revised}
    |--Create Origin and edition of the resource.  Create includes edit.    Unord M   -
    |--|--Date The date that the resource was created or edited. Create or Edit Date Sngl M   A_Date
    |--|--Contribute Involvement in the creation or edition of the resource.   Unord M   -
    |--|--|--Role Kind of involvement. Exactly one instance of "Creator" must exist.  Contributor Role Sngl M   A_Vocabulary 
    examples: {creator, author, editor, programmer, graphics artist
    |--|--|--Person Person involved. Contributing Person Ord M   A_Person
    |--Publish Making the resource available.   Unord M   -
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the resource was published. Publisher Sngl M   A_Organisation
    |--|--Date The date that the resource was published. Publication Date Sngl M   A_Date
    |--Terminate Making the resource no longer available.   Sngl O   -
    |--|--Date The date on which the resource ceases to be accessible. Termination Date Sngl O   A_Date
    |--Initiated By Requesting that the resource be produced.   Sngl O   -
    |--|--Person Person initiating the production of the resource. Initiating Person Sngl O   A_Person
    |--|--Organisation Organization initiating the production of the resource. Initiating Organization Sngl O   A_Organisation
    Meta-metadata Characteristics of the description rather than the resource.   Sngl M   -
    |--Create Origin and edition of the metadata.   Ord M   -
    |--|--Date The date that the description was created or edited. Meta-Data Creation or Edit Date Sngl M   A_Date
    |--|--Person Person that created the description. Meta-Data Editor Unord M   A_Person
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the description was published. Meta-Data Source Organization Sngl M   A_Organisation
    |--Scheme Defines the structure of the metadata.  This includes version. Meta-Data Schema Sngl M   A_Vocabulary 
    example: {Base 1.0, IMS, ARIADNE}
    |--Validate Verification of the quality of the description by a third, authorized party.   Unord O   -
    |--|--Date The date that the description was validated. Meta-Data Validation Date Sngl O   A_Date
    |--|--Person Person that validated the description. Meta-Data Validator Unord O   A_Person
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the description was validated. Meta-Data Validating Organization Sngl O   A_Organisation
    Technical Technical features of the resource.   Sngl M   -
    |--Format Technical data type of the resource. 
    note: Can be used to identify the software needed to access the resource.
    Technical Format Sngl M   A_Format
    |--Size The size of the digital resource in bytes. 
    note: This refers to the actual size of the resource, and not to the size of a compressed version of the resource.
    Size in Bytes Sngl O   A_Integer
    |--LocSpec A location or a method that resolves to a location. 
    note: This allows for a URL, a URN, a URI, a DOI, etc.  The order can be used to indicate the preferable LocSpec first. 
    Location Ord M   A_LocSpec
    |--OSRequirements Needs with respect to the Operating System in order to access the resource.   Sngl M   -
    |--|--OperatingSystem Name of the Operating System. 
    note: May be derived from Format automatically, e.g., HTML implies "generic". 
    Operating System (OS) Unord M   A_Vocabulary
    example: {MacOS, Unix, Windows95, Windows NT, Generic}
    |--|--MinimumVersion Lowest version number of the Operating System. Minimum OS Version Sngl O   A_Decimal
    |--|--MaximumVersion Highest version number of the Operating System. Maximum OS Version Sngl O   A_Decimal
    |--OtherPlatformRequirements Information about other software and hardware requirements.   Unord O   A_LangString
    |--InstallationRemarks Description on how to install the resource. Installation Remarks Unord O   A_LangString
    |--Duration Time a continuous resource takes. Technical Duration Sngl O   A_TimeSpan
    Educational Use Dependent Features that need to be interpreted according to the educational use of the resource.   Unord O   -
    |--Role Kind of use of the resource. 
    An author creates or publishes resource.  A coordinator manages the delivery of the resource, e.g., a university or college.  The document for a coordinator is typically a curriculum.
    User Role Sngl C: if difficulty or duration are defined   A_Vocabulary. 
    Example: {Teacher, Learner, Author, Coordinator.   }
    |--Description Comments on how the resource is to be used. Use Description Unord O   A_LangString 
    examples: {Not Applicable, Study aid, teacher's resource, student's resource, Sub-element)
    |--Prerequisite Course and/or capabilities required from the end user.   Unord O   -
    |--|--Description Verbal description of the prerequisite.  May be automatically extracted from the resource indicated by the Identifier of the prerequisite. Use Prerequisite Description Unord M   A_LangString
    |--|--Source Source of the description Source of Use Prerequisite Sngl O   A_Source
    |--|--Identifier Unique Identifier of an educational objective within the Source of the Prerequisite. GUID of the Use Prerequisite Sngl O   A_Identifier
    |--Educational objective Intended learning result.   Unord O   -
    |--|--Description Verbal description of the prerequisite.  May be automatically extracted from the resource indicated by the Identifier.  Multiple language versions may be included. Description of the Educational Objective(s) Unord M   A_LangString
    |--|--Source Source of the description Source of the Educational Objective Description Sngl O   A_Source
    |--|--Identifier Unique Identifier of an educational objective within Source of the Educational Objective. GUID of the Educational Objective Sngl O   A_Identifier
    |--Level Target audience. 
    note: The intention is to develop a numerical evaluator scheme that maps levels across national boundaries.
    Use Level Sngl C: if difficulty or duration are defined   A_Vocabulary
    |--Difficulty How hard it is to work trough the resource. Use Difficulty Sngl O   A_Vocabulary 
    example: {low, medium, high}
    |--Duration Time it takes to work with the resource. Use Duration Sngl O   A_TimeSpan
    Rights Management Features that need to be interpreted according to the use of the resource.   Unord M   -
    |--Role Kind of use of the resource. Rights Management Role Sngl M   A_Vocabulary 
    example: {read, incorporate, resell}
    |--Description Comments on the use of the resource. Rights Role Description Unord O   A_LangString
    |--Contact A steward that can assist with rights procurement. Contact Location Sngl O   A_LocSpec
    |--Support Whether or not support is available for the resource. Support Sngl O   A_Boolean
    |--Conditions Legal or economic requirements for use according to the role.   Sngl M   -
    |--|--Reciprocity Whether or not the provider of a resource can use any resource that incorporates his resource on the same basis. Rights Reciprocity Sngl O   A_Boolean
    |--|--Attribution Whether or not the use of a resource requires it be cited. Attribution Required Sngl O   A_Boolean
    |--|--Price Amount of money to be paid to use the resource in the way specified by role.   Unord -   -
    |--|--|--Monetary Unit Unit of currency referred to by Amount. Currency Sngl C: if Amount is used and Amount<>0   A_Vocabulary 
    example: {BEF, US$, FrFr}
    |--|--|--Amount Monetary value. 
    note: 0 is an acceptable value.
    Price Sngl C: If Code is not used.   A_Decimal
    |--|--|--Unit of pricing Unit to which the price applies. Units Sngl O   A_Vocabulary 
    example: {flat fee, per hour, per MByte}
    |--|--|--Code Price Code Price Code Sngl O    
    Relation Characteristics of the resource in relationship to other resources.   Unord O   -
    |--Kind Nature of the relationship between the resources. Kind of Relationship Sngl M   A_Vocabulary 
    example: {IsPartOf, HasPart, IsVersionOf, HasVersion, IsFormatOf, HasFormat, References, IsReferencedBy, IsBasedOn, IsBasisFor, Requires, IsRequiredBy}
    |--Resource Resource the relationship holds for.   Sngl M  
    |--|--Identifier Unique Identifier of the other resource Target Resource Identifier Sngl O   A_Identifier
    |--|--Description Description of the other resource. Target Resource Description Unord O   A_LangString
    Annotation Comments on the use of the resource.   Unord O   -
    |--Person Annotator. Annotator Sngl M   A_Person
    |--Date Date that the annotation was created. Annotation Date Sngl M   A_Date
    |--Description The content of the annotation Annotation Unord M   A_LangString

    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.
    Base Type Schema Information
    Publisher IMS
    Type Base
    Catalog ID 1
    Version 0.2
    Date 1998-07-01
    Derived From NA
    Description 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 common properties for meta-data interchange among all derived type schemas.
     
    Base Meta-Data Schema Table
    Name Contextualized Definition 
    & Comments
    Property 
    Caption
    List Oblig. Data Type
    General Basic reference to the resource.   Sngl M   -
    |--Identifier A unique label for the resource. 
    note: This element can be transparent to the metadata creator. It can be created by the metadata management system.
    GUID Sngl M   A_Identifier
    |--Title Name given to the resource. Title Unord M   A_LangString
    Characteristics Non-contextualized features of the resource.   Sngl M   -
    |--Language The human language of the intellectual content or the application interface. Language Unord M   A_Locale 
    Can include N.A. (Not Applicable)
    |--Description A textual description of the content of the resource. Abstract Unord M   A_LangString
    |--Discipline A specific knowledge domain. Disciplines are ordered from the most relevant to the least relevant.    Ord M   -
    |--|--TaxonPath A taxonomic path in a specific taxonomy.  There may be different paths in the same or different taxonomy that describe a particular discipline.    Unord M   -
    |--|--|--Source A specific taxonomy Subject Taxonomy Sngl M   A_Source 
    Example: {IMS Standard Subjects}
    |--|--|--Taxon An entry from a taxonomy that refers to the discipline. An ordered list of Taxons creates a taxonomic path, i.e "taxonomic stairway": this is a path from a more general to more specific entry in a taxonomy.  Subject Taxonomy Ord M   A_Entry
    Life Cycle Characteristics related to the different phases of the resource.   Sngl M   -
    |--Version The edition of the resource. Version Sngl M   A_Decimal
    |--Create Origin and edition of the resource.  Create includes edit.    Unord M   -
    |--|--Date The date that the resource was created or edited. Create or Edit Date Sngl M   A_Date
    |--|--Contribute Involvement in the creation or edition of the resource.   Unord M   -
    |--|--|--Role Kind of involvement. Exactly one instance of "Creator" must exist.  Contributor Role Sngl M   A_Vocabulary 
    examples: {creator, author, editor, programmer, graphics artist
    |--|--|--Person Person involved. Contributing Person Ord M   A_Person
    |--Publish Making the resource available.   Unord M   -
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the resource was published. Publisher Sngl M   A_Organisation
    |--|--Date The date that the resource was published. Publication Date Sngl M   A_Date
    Meta-metadata Characteristics of the description rather than the resource.   Sngl M   -
    |--Create Origin and edition of the metadata.   Ord M   -
    |--|--Date The date that the description was created or edited. Meta-Data Creation or Edit Date Sngl M   A_Date
    |--|--Person Person that created the description. Meta-Data Editor Unord M   A_Person
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the description was published. Meta-Data Source Organization Sngl M   A_Organisation
    |--Scheme Defines the structure of the metadata.  This includes version.  Syntax: Source:Scheme:Version Meta-Data Schema Sngl M   A_Vocabulary 
    for IMS Base: 
    IMS:1.0:0.2
    Technical Technical features of the resource.   Sngl M   -
    |--Format Technical data type of the resource. 
    note: Can be used to identify the software needed to access the resource.
    Technical Format Sngl M   A_Format
    |--LocSpec A location or a method that resolves to a location. 
    note: This allows for a URL, a URN, a URI, a DOI, etc.  The order can be used to indicate the preferable LocSpec first. 
    Location Ord M   A_LocSpec
    |--OSRequirements Needs with respect to the Operating System in order to access the resource.   Sngl M   -
    |--|--OperatingSystem Name of the Operating System. 
    note: May be derived from Format automatically, e.g., HTML implies "generic". 
    Operating System (OS) Unord M   A_Vocabulary 
    example: {MacOS, Unix, Windows95, Windows NT, Generic}
    Rights Management Features that need to be interpreted according to the use of the resource.   Unord M   -
    |--Role Kind of use of the resource. Rights Management Role Sngl M   A_Vocabulary 
    example: {read, incorporate, resell}
    |--Conditions Legal or economic requirements for use according to the role.   Sngl M   -
    |--|--Price Amount of money to be paid to use the resource in the way specified by role.   Unord M   -
    |--|--|--Monetary Unit Unit of currency referred to by Amount. Currency Sngl C: if Amount is used and Amount<>0   A_Vocabulary 
    example: {BEF, US$, FrFr}
    |--|--|--Amount Monetary value. 
    note: 0 is an acceptable value.
    Price Sngl C: If Code is not used.   A_Decimal

    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.
    Item Type Schema Information
    Publisher IMS
    Type Item
    Catalog ID 1.1
    Version 1.0
    Date 1998-07-01
    Derived From IMS 1.0:1.0
    Description  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. 

    The IMS Item type is derived from the IMS Base Meta-Data Type.

     
    Item Meta-Data Schema Table
    Name Contextualized Definition 
    & Comments
    Property 
    Caption
    List Oblig. Data Type
    General Basic reference to the resource.   Sngl M   -
    |--Identifier A unique label for the resource. 
    note: This element can be transparent to the metadata creator. It can be created by the metadata management system.
    GUID Sngl M   A_Identifier
    |--Title Name given to the resource. Title Unord M   A_LangString
    |--Catalog Entry Designation given to the resource. Catalog ID Unord O   A_SourceString
    Characteristics Non-contextualized features of the resource.   Sngl M   -
    |--Language The human language of the intellectual content or the application interface. Language Unord M   A_Locale 
    Can include N.A. (Not Applicable)
    |--Description A textual description of the content of the resource. Abstract Unord M   A_LangString
    |--Discipline A specific knowledge domain. Disciplines are ordered from the most relevant to the least relevant.    Ord M   -
    |--|--TaxonPath A taxonomic path in a specific taxonomy.  There may be different paths in the same or different taxonomy that describe a particular discipline.    Unord M   -
    |--|--|--Source A specific taxonomy Subject Taxonomy Sngl M   A_Source 
    Example: {IMS Standard Subjects}
    |--|--|--Taxon An entry from a taxonomy that refers to the discipline. An ordered list of Taxons creates a taxonomic path, i.e "taxonomic stairway": this is a path from a more general to more specific entry in a taxonomy.  Subject Taxonomy Ord M   A_Entry
    |--|--Description A textual description of the discipline. Subject Description Unord O   A_LangString
    |--|--Keywords Keywords describing the discipline. Subject Keywords Ord O   A_LangString
    Life Cycle Characteristics related to the different phases of the resource.   Sngl M   -
    |--Version The edition of the resource. Version Sngl M   A_Decimal
    |--Create Origin and edition of the resource.  Create includes edit.    Unord M   -
    |--|--Date The date that the resource was created or edited. Create or Edit Date Sngl M   A_Date
    |--|--Contribute Involvement in the creation or edition of the resource.   Unord M   -
    |--|--|--Role Kind of involvement. Exactly one instance of "Creator" must exist.  Contributor Role Sngl M   A_Vocabulary 
    examples: {creator, author, editor, programmer, graphics artist
    |--|--|--Person Person involved. Contributing Person Ord M   A_Person
    |--Publish Making the resource available.   Unord M   -
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the resource was published. Publisher Sngl M   A_Organisation
    |--|--Date The date that the resource was published. Publication Date Sngl M   A_Date
    Meta-metadata Characteristics of the description rather than the resource.   Sngl M   -
    |--Create Origin and edition of the metadata.   Ord M   -
    |--|--Date The date that the description was created or edited. Meta-Data Creation or Edit Date Sngl M   A_Date
    |--|--Person Person that created the description. Meta-Data Editor Unord M   A_Person
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the description was published. Meta-Data Source Organization Sngl M   A_Organisation
    |--Scheme Defines the structure of the metadata.  This includes version. Meta-Data Schema Sngl M   A_Vocabulary 
    IMS:1.1:0.1
    Technical Technical features of the resource.   Sngl M   -
    |--Format Technical data type of the resource. 
    note: Can be used to identify the software needed to access the resource.
    Technical Format Sngl M   A_Format
    |--Size The size of the digital resource in bytes. 
    note: This refers to the actual size of the resource, and not to the size of a compressed version of the resource.
    Size in Bytes Sngl O   A_Integer
    |--LocSpec A location or a method that resolves to a location. 
    note: This allows for a URL, a URN, a URI, a DOI, etc.  The order can be used to indicate the preferable LocSpec first. 
    Location Ord M   A_LocSpec
    |--OSRequirements Needs with respect to the Operating System in order to access the resource.   Sngl M   -
    |--|--OperatingSystem Name of the Operating System. 
    note: May be derived from Format automatically, e.g., HTML implies "generic". 
    Operating System (OS) Unord M   A_Vocabulary 
    example: {MacOS, Unix, Windows95, Windows NT, Generic}
    |--Duration Time a continuous resource takes. Technical Duration Sngl O   A_TimeSpan
    Rights Management Features that need to be interpreted according to the use of the resource.   Unord M   -
    |--Role Kind of use of the resource. Rights Management Role Sngl M   A_Vocabulary 
    example: {read, incorporate, resell}
    |--Contact A steward that can assist with rights procurement. Contact Location Sngl O   A_LocSpec
    |--Conditions Legal or economic requirements for use according to the role.   Sngl M   -
    |--|--Reciprocity Whether or not the provider of a resource can use any resource that incorporates his resource on the same basis. Rights Reciprocity Sngl O   A_Boolean
    |--|--Attribution Whether or not the use of a resource requires it be cited. Attribution Required Sngl O   A_Boolean
    |--|--Price Amount of money to be paid to use the resource in the way specified by role.   Unord M   -
    |--|--|--Monetary Unit Unit of currency referred to by Amount. Currency Sngl C: if Amount is used and Amount<>0   A_Vocabulary 
    example: {BEF, US$, FrFr}
    |--|--|--Amount Monetary value. 
    note: 0 is an acceptable value.
    Price Sngl C: If Code is not used.   A_Decimal
    |--|--|--Unit of pricing Unit to which the price applies. Units Sngl O   A_Vocabulary 
    example: {flat fee, per hour, per MByte}
    |--|--|--Code Price Code Price Code Sngl O   A_Vocabulary
    Relation Characteristics of the resource in relationship to other resources.   Unord O   -
    |--Kind Nature of the relationship between the resources. Kind of Relationship Sngl M   A_Vocabulary 
    example: {IsPartOf, HasPart, IsVersionOf, HasVersion, IsFormatOf, HasFormat, References, IsReferencedBy, IsBasedOn, IsBasisFor, Requires, IsRequiredBy}
    |--Resource Resource the relationship holds for.   Sngl M  
    |--|--Identifier Unique Identifier of the other resource Target Resource Identifier Sngl O   A_Identifier
    |--|--Description Description of the other resource. Target Resource Description Unord O   A_LangString

    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.
     
     
    Module Type Meta-Data Schema Table
    Name Contextualized Definition 
    & Comments
    Property 
    Caption
    List Oblig. Data Type
    General Basic reference to the resource.   Sngl M   -
    |--Identifier A unique label for the resource. 
    note: This element can be transparent to the metadata creator. It can be created by the metadata management system.
    GUID Sngl M   A_Identifier
    |--Title Name given to the resource. Title Unord M   A_LangString
    |--Catalog Entry Designation given to the resource. Catalog ID Unord O   A_SourceString
    Characteristics Non-contextualized features of the resource.   Sngl M   -
    |--Language The human language of the intellectual content or the application interface. Language Unord M   A_Locale
    Can include N.A. (Not Applicable)
    |--Description A textual description of the content of the resource. Abstract Unord M   A_LangString
    |--Discipline A specific knowledge domain. Disciplines are ordered from the most relevant to the least relevant.    Ord M   -
    |--|--TaxonPath A taxonomic path in a specific taxonomy.  There may be different paths in the same or different taxonomy that describe a particular discipline.    Unord M   -
    |--|--|--Source A specific taxonomy Subject Taxonomy Sngl M   A_Source 
    Example: {IMS Standard Subjects}
    |--|--|--Taxon An entry from a taxonomy that refers to the discipline. An ordered list of Taxons creates a taxonomic path, i.e "taxonomic stairway": this is a path from a more general to more specific entry in a taxonomy.  Subject Taxonomy Ord M   A_Entry
    |--|--Description A textual description of the discipline. Subject Description Unord O   A_LangString
    |--|--Keywords Keywords describing the discipline. Subject Keywords Ord O   A_LangString
    |--Concept The idea or notion presented in the resource. Examples: invariance, evolution, proof, taxonomy, operator, epoch.    Ord O   -
    |--|--TaxonPath A path in a specific taxonomy or ontology.  There may be different paths in the same or different taxonomy or ontology that describe a particular resource concept.    Unord O   -
    |--|--|--Source A specific taxonomy Concept Taxonomy Sngl M   A_Source
    |--|--|--Taxon An entry from a taxonomy (or ontology). An ordered list of Taxons creates a taxonomic path, i.e "taxonomic stairway": this is a path from a more general to more specific entry in a taxonomy.  Concept Taxon Ord M   A_Entry
    |--|--Description A textual description of the concept. Concept Description Unord O   A_LangString
    |--|--Keywords Keywords describing the concept. Concept Keywords Ord O   A_LangString
    |--Coverage The spatial or temporal characteristics of the intellectual content of the resource.  Can specify an epoch or geographical area, for instance. Coverage Unord O   A_Coverage
    examples: {1700-1800, Texas}
    |--Type The kind of resource.  An ordered list with the most prevalent type first.  Resource Type Ord M   A_Vocabulary 
    examples: 
    {Advertisement 
    Assessment 
    Base (undifferentiated) 
    Collection 
    Dataset 
    Document 
    Example 
    Exercise 
    Media Resource 
    Message 
    Misc (ellaneous) 
    Reference 
    Schedule 
    Simulation 
    Tool 
    Tutorial }
    |--Approach Logical structure used in the resource. Approaches are listed with the most prevalent first. Pedagogy Ord M   A_Vocabulary
    example: {inductive, deductive}
    |--Granularity The relative size of the resource. Granularity Sngl M   A_Vocabulary 
    example: {curriculum, course, unit, topic, lesson, fragment}
    |--Structure Underlying organizational structure of the resource. Structure Sngl M   A_Vocabulary 
    example: {linear, hyperdimensional, branched, parcelled, atomic, multiple}
    |--Interaction quality Level of interactivity between an end user and the resource. Interactivity Level Sngl O   A_Vocabulary 
    example: {low, medium, high}
    |--Semantic density Relationship between the usage time and the amount of content presented in the resource. Semantic Density Sngl O   A_Vocabulary 
    example: {low, medium, high}
    |--Presentation The dominant mode of presentation. Presentation Ord O   A_Vocabulary 
    examples: {verbal, graphical, textual, auditory, video, image}
    Life Cycle Characteristics related to the different phases of the resource.   Sngl M   -
    |--Version The edition of the resource. Version Sngl M   A_Decimal
    |--Status The condition the resource is in. Life Cycle Status Sngl O   A_Vocabulary 
    example: {draft, final, revised}
    |--Create Origin and edition of the resource.  Create includes edit.    Unord M   -
    |--|--Date The date that the resource was created or edited. Create or Edit Date Sngl M   A_Date
    |--|--Contribute Involvement in the creation or edition of the resource.   Unord M   -
    |--|--|--Role Kind of involvement. Exactly one instance of "Creator" must exist.  Contributor Role Sngl M   A_Vocabulary 
    examples: {creator, author, editor, programmer, graphics artist
    |--|--|--Person Person involved. Contributing Person Ord M   A_Person
    |--Publish Making the resource available.   Unord M   -
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the resource was published. Publisher Sngl M   A_Organisation
    |--|--Date The date that the resource was published. Publication Date Sngl M   A_Date
    Meta-metadata Characteristics of the description rather than the resource.   Sngl M   -
    |--Create Origin and edition of the metadata.   Ord M   -
    |--|--Date The date that the description was created or edited. Meta-Data Creation or Edit Date Sngl M   A_Date
    |--|--Person Person that created the description. Meta-Data Editor Unord M   A_Person
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the description was published. Meta-Data Source Organization Sngl M   A_Organisation
    |--Scheme Defines the structure of the metadata.  This includes version. Meta-Data Schema Sngl M   A_Vocabulary 
    IMS:1.2:0.1
    |--Validate Verification of the quality of the description by a third, authorized party.   Unord O   -
    |--|--Person Person that validated the description. Meta-Data Validator Unord O   A_Person
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the description was validated. Meta-Data Validating Organization Sngl O   A_Organisation
    Technical Technical features of the resource.   Sngl M   -
    |--Format Technical data type of the resource. 
    note: Can be used to identify the software needed to access the resource.
    Technical Format Sngl M   A_Format
    |--Size The size of the digital resource in bytes. 
    note: This refers to the actual size of the resource, and not to the size of a compressed version of the resource.
    Size in Bytes Sngl O   A_Integer
    |--LocSpec A location or a method that resolves to a location. 
    note: This allows for a URL, a URN, a URI, a DOI, etc.  The order can be used to indicate the preferable LocSpec first. 
    Location Ord M   A_LocSpec
    |--OSRequirements Needs with respect to the Operating System in order to access the resource.   Sngl M   -
    |--|--OperatingSystem Name of the Operating System. 
    note: May be derived from Format automatically, e.g., HTML implies "generic". 
    Operating System (OS) Unord M   A_Vocabulary 
    example: {MacOS, Unix, Windows95, Windows NT, Generic}
    |--Hardware Hardware Requirements to use the resource.   Unord O   -
    |--|--Description Textual description of special hardware requirements. Hardware Notes Unord O   A_LangString
    |--Duration Time a continuous resource takes. Technical Duration Sngl O   A_Timespan
    Educational Use Dependent Features that need to be interpreted according to the educational use of the resource.   Unord M   -
    |--Role Kind of use of the resource. 
    An author creates or publishes resource.  A coordinator manages the delivery of the resource, e.g., a university or college.  The document for a coordinator is typically a curriculum.
    User Role Sngl C: if difficulty or duration are defined   A_Vocabulary. 
    Example:
    {Teacher,
    Learner,
    Author,
    Coordinator.}
    |--Description Comments on how the resource is to be used. Use Description Unord O   A_LangString 
    examples: {Not Applicable, Study aid, teacher's resource, student's resource, Sub-element)
    |--Prerequisite Course and/or capabilities required from the end user.   Unord O   -
    |--|--Description Verbal description of the prerequisite.  May be automatically extracted from the resource indicated by the Identifier of the prerequisite. Use Prerequisite Description Unord M   A_LangString
    |--|--Source Source of the description Source of Use Prerequisite Sngl O   A_Source
    |--|--Identifier Unique Identifier of an educational objective within the Source of the Prerequisite. GUID of the Use Prerequisite Sngl O   A_Identifier
    |--Educational objective Intended learning result.   Unord O!   -
    |--|--Description Verbal description of the prerequisite.  May be automatically extracted from the resource indicated by the Identifier.  Multiple language versions may be included. Description of the Educational Objective(s) Unord M   A_LangString
    |--|--Source Source of the description Source of the Educational Objective Description Sngl O   A_Source
    |--|--Identifier Unique Identifier of an educational objective within Source of the Educational Objective. GUID of the Educational Objective Sngl O   A_Identifier
    |--Level Target audience. 
    note: The intention is to develop a numerical evaluator scheme that maps levels across national boundaries.
    Use Level Sngl M--C: if difficulty or duration are defined   A_Vocabulary
    |--Difficulty How hard it is to work trough the resource. Use Difficulty Sngl M   A_Vocabulary 
    example: {low, medium, high}
    |--Duration Time it takes to work with the resource. Use Duration Sngl M   A_Timespan
    Rights Management Features that need to be interpreted according to the use of the resource. Note that there can be an unordered list of multiple rights management structures.    Unord M   -
    |--Role Kind of use of the resource. Rights Management Role Sngl M   A_Vocabulary 
    example: {read, incorporate, resell}
    |--Description Comments on the use of the resource. Rights Role Description Unord O   A_LangString
    |--Contact A steward that can assist with rights procurement. Contact Location Sngl M   A_LocSpec
    |--Support Whether or not support is available for the resource. Support Sngl O   A_Boolean
    |--Conditions Legal or economic requirements for use according to the role.   Sngl M   -
    |--|--Reciprocity Whether or not the provider of a resource can use any resource that incorporates his resource on the same basis. Rights Reciprocity Sngl O   A_Boolean
    |--|--Attribution Whether or not the use of a resource requires it be cited. Attribution Required Sngl O   A_Boolean
    |--|--Price Amount of money to be paid to use the resource in the way specified by role.   Unord   -
    |--|--|--Monetary Unit Unit of currency referred to by Amount. Currency Sngl C: if Amount is used and Amount<>0   A_Vocabulary 
    example: {BEF, US$, FrFr}
    |--|--|--Amount Monetary value. 
    note: 0 is an acceptable value.
    Price Sngl C: If Code is not used.   A_Decimal
    |--|--|--Unit of pricing Unit to which the price applies. Units Sngl O   A_Vocabulary 
    example: {flat fee, per hour, per MByte}
    |--|--|--Code Price Code Price code   O   A_Vocabulary
    Relation Characteristics of the resource in relationship to other resources.   Unord O   -
    |--Kind Nature of the relationship between the resources. Kind of Relationship Sngl M   A_Vocabulary 
    example: {IsPartOf, HasPart, IsVersionOf, HasVersion, IsFormatOf, HasFormat, References, IsReferencedBy, IsBasedOn, IsBasisFor, Requires, IsRequiredBy}
    |--Resource Resource the relationship holds for.   Sngl M  
    |--|--Identifier Unique Identifier of the other resource Target Resource Identifier Sngl O   A_Identifier
    |--|--Description Description of the other resource. Target Resource Description Unord O   A_LangString
     

    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.

     
    Tool Type Meta-Data Schema Information
    Name Contextualized Definition 
    & Comments
    Property 
    Caption
    List Oblig. Data Type
    General Basic reference to the resource.   Sngl M   -
    |--Identifier A unique label for the resource. 
    note: This element can be transparent to the metadata creator. It can be created by the metadata management system.
    GUID Sngl M   A_Identifier
    |--Title Name given to the resource. Title Unord M   A_LangString
    |--Catalog Entry Designation given to the resource. Catalog ID Unord O   A_SourceString
    Characteristics Non-contextualized features of the resource.   Sngl M   -
    |--Language The human language of the intellectual content or the application interface. Language Unord M   A_Locale 
    Can include N.A. (Not Applicable)
    |--Description A textual description of the content of the resource. Abstract Unord M   A_LangString
    |--Discipline A specific knowledge domain the tool is intended for, if any. Disciplines are ordered from the most relevant to the least relevant.    Ord O   -
    |--|--Description A textual description of the discipline. Subject Description Unord O   A_LangString
    |--|--Keywords Keywords describing the discipline. Subject Keywords Ord C if Description is not used.   A_LangString
    Life Cycle Characteristics related to the different phases of the resource.   Sngl M   -
    |--Version The edition of the resource. Version Sngl M   A_Decimal
    |--Create Origin and edition of the resource.  Create includes edit.    Unord M   -
    |--|--Date The date that the resource was created or edited. Create or Edit Date Sngl M   A_Date
    |--|--Contribute Involvement in the creation or edition of the resource.   Unord M   -
    |--|--|--Role Kind of involvement. Exactly one instance of "Creator" must exist.  Contributor Role Sngl M   A_Vocabulary 
    examples: {creator, author, editor, programmer, graphics artist
    |--|--|--Person Person involved. Contributing Person Ord M   A_Person
    |--Publish Making the resource available.   Unord M   -
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the resource was published. Publisher Sngl M   A_Organisation
    |--|--Date The date that the resource was published. Publication Date Sngl M   A_Date
    Meta-metadata Characteristics of the description rather than the resource.   Sngl M   -
    |--Create Origin and edition of the metadata.   Ord M   -
    |--|--Date The date that the description was created or edited. Meta-Data Creation or Edit Date Sngl M   A_Date
    |--|--Person Person that created the description. Meta-Data Editor Unord M   A_Person
    |--|--Organisation A university department, company, agency, institute, etc under whose responsibility the description was published. Meta-Data Source Organization Sngl M   A_Organisation
    |--Scheme Defines the structure of the metadata.  This includes version. Meta-Data Schema Sngl M   A_Vocabulary 
    example: {Base 1.0, IMS, ARIADNE}
    |--|--Date The date that the description was validated. Meta-Data Validation Date Sngl O   A_Date
    Technical Technical features of the resource.   Sngl M   -
    |--Format Technical data type of the resource. 
    note: Can be used to identify the software needed to access the resource.
    Technical Format Sngl M   A_Format
    |--LocSpec A location or a method that resolves to a location. 
    note: This allows for a URL, a URN, a URI, a DOI, etc.  The order can be used to indicate the preferable LocSpec first. 
    Location Ord M   A_LocSpec
    |--OSRequirements Needs with respect to the Operating System in order to access the resource.   Sngl M   -
    |--|--OperatingSystem Name of the Operating System. 
    note: May be derived from Format automatically, e.g., HTML implies "generic". 
    Operating System (OS) Unord M   A_Vocabulary 
    example: {MacOS, Unix, Windows95, Windows NT, Generic}
    Rights Management Features that need to be interpreted according to the use of the resource.   Unord M   -
    |--Role Kind of use of the resource. Rights Management Role Sngl M   A_Vocabulary 
    example: {read, incorporate, resell}
    |--Description Comments on the use of the resource. Rights Role Description Unord O   A_LangString
    |--Contact A steward that can assist with rights procurement. Contact Location Sngl M   A_LocSpec
    |--Support Whether or not support is available for the resource. Support Sngl O   A_Boolean
    |--Conditions Legal or economic requirements for use according to the role.   Sngl M   -
    |--|--Reciprocity Whether or not the provider of a resource can use any resource that incorporates his resource on the same basis. Rights Reciprocity Sngl O   A_Boolean
    |--|--Attribution Whether or not the use of a resource requires it be cited. Attribution Required Sngl O   A_Boolean
    |--|--Price Amount of money to be paid to use the resource in the way specified by role.   Unord M   -
    |--|--|--Monetary Unit Unit of currency referred to by Amount. Currency Sngl C: if Amount is used and Amount<>0   A_Vocabulary 
    example: {BEF, US$, FrFr}
    |--|--|--Amount Monetary value. 
    note: 0 is an acceptable value.
    Price Sngl C: If Code is not used.   A_Decimal
    |--|--|--Unit of pricing Unit to which the price applies. Units Sngl O   A_Vocabulary 
    example: {flat fee, per hour, per MByte}
    |--|--|--Code Price Code Price Code Sngl O   A_Vocabulary

    Appendix D - Non-normative implementation guide


    Document Meta Data
    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
    Return to Top.

    To Home Index


    Tom Wason, twason@imsproject.org
    IMS Project
    © 1999 IMS Project