Skip to main content
U.S. flag

An official website of the United States government


Introduction to Metadata

International Organization for Standardization (ISO)


Introduction to Metadata

Metadata provides descriptive, contextual information about datasets and products to make them easier to discover, use, and understand. Good metadata answers the following questions:

  • Who collected the data?
  • Who processed the data? Who wrote the metadata?
  • Who should I contact for questions?
  • Who should I contact to order data?
  • Who owns the data?
  • What are the data about?
  • What project where they collected under?
  • What are the constraints on their use?
  • What is the quality?
  • What are appropriate uses?
  • What parameters were measured?
  • What format are the data in?
  • Why were the data collected?
  • Where were the data collected?
  • Where were the data processed?
  • Where are the data located?
  • When were the data collected?
  • When were the data processed?
  • How were the data collected?
  • How were the data processed?
  • How do I access the data?
  • How do I order the data?
  • How much do the data cost?
  • How was data quality assessed?


Although metadata has a primary, concrete utility, it is also a multi-functional tool that improves data stewardship in several important ways: 

  • Facilitates Search and Analysis: Metadata makes data easier to search for, document, transform, and report.
  • Improves Data Governance: Following metadata standards makes good data governance possible.  
  • Supports Integration: Complete integration between users, software engineers and data stewards improves data management. 
  • Project Management: Provides a medium to integrate and record progress. 
  • Data Management: Preserves data development iterations to monitor status, assessments and needed changes. 
  • Security: Helps to enforce regulations and protect data.

Metadata Maintenance

Metadata records are living documents that need, at a minimum, annual review to accommodate changes to data and metadata content, or to incorporate information that makes the record more useful. Follow the Metadata Maintenance Guide to keep your metadata in working order.

  • Review content and ensure everything is up-to-date.
    1. Do all of your archive holdings have metadata?
    2. Are URL’s up-to-date?
    3. Are contacts, phone numbers and emails up-to-date?
    4. Are keywords still up-to-date?
    5. Does the distribution link take users to the data access page?
    6. Spelling and grammar are checked?
    7. Did you update the Metadata Date field?
  • How well does the metadata describe the resource?
    1. How complete is the metadata?
    2. Is the scope of the metadata granular enough to describe the resource?
    3. Is the quality of the data recorded?
    4. Are inputs, outputs, processing details and algorithms documented?
  • Have the metadata standard(s) and/or metadata tools evolved?
    1. Are there new features or new tools that make editing metadata easier?
    2. Have the standards evolved and what new features help document data better?
  • Interoperability:
    1. Are there ways to re-use metadata content programmatically?
    2. Does the data home page provide links to metadata for more information?
    3. Is metadata distributed with a data download package?
  • Related Projects and Communities:
    1. Are there other projects and communities that the metadata can be a part of?
    2. Are there expectations and guidance available from projects and communities?
    3. Is the metadata content compatible with other projects and communities?

Data Discovery

Background and Legislation

On April 11th 1994, President Bill Clinton signed Executive Order 12906, which established the National Spatial Data Infrastructure (NSDI) to support public and private sector applications of geospatial data in transportation, community development, agriculture, emergency response, environmental management, and information technology. Order 12906 also established an electronic National Geospatial Data Clearinghouse for the NSDI to address data standardization, make geospatial data publicly available, and address redundancy and incompatibility issues. 

On August 19th 2002, the United States Office of Management and Budget (OMB) created a Government circular (OMB Circular A-16) to provide guidance for federal agencies to create, maintain or use spatial data directly or indirectly through the establishment of the NSDI and the Federal Geographic Data Committee (FGDC). The circular established guidelines for proper use and management of digital spatial data. In September of 2010, the FGDC Steering Committee endorsed 64 non-Federally authored standards, including the ISO 191** series. FGDC policy states that non-Federally authored standards endorsed by the FGDC have the same status as FGDC developed standards (such as CSDGM, BIO, RSE). Since ISO 19115 and the associated standards are endorsed by the FGDC, federal agencies are encouraged to transition to ISO metadata as their agencies are able to do so. 

The Environmental Data Management Committee (EDMC) coordinates the development of NOAA's environmental data management strategy and policy, and provides guidance to promote consistent implementation across NOAA on behalf of the NOSC and CIO Council. Environmental data management is an end-to-end process that includes acquisition, quality control, validation, reprocessing, storage, retrieval, dissemination, and long-term preservation activities. The goal of the EDMC is to enable NOAA to maximize the value of its environmental data assets through sound and coordinated data management practices.

The NOAA Data Documentation Procedural Directive page provides detailed information about EDMC activities, organization, and initiatives.



NCEI  provides access to an enormous, diverse collection of environmental data by developing and maintaining enterprise software, portals, APIs, visualization methods, and other tools and services that use metadata to facilitate data search and discovery.

NCEI Access Services


Geoportal searches the indexed fields from metadata for all archived datasets, bringing together various discovery web services and metadata into a user-focused framework.

Launch Geoportal

Other Government Portals

Writing Quality Metadata

Planning for metadata development during the initial planning stages of a project can save time, effort, and money in the long run. Establish a format or protocol for data documentation, and then stick to it. Document everything during data development: it’s much easier to capture this information in real time than to document it retroactively. 

Fundamentals of Quality Metadata

Organize Your Information 

Metadata is often a compilation of information from many different sources. Make a habit of documenting, organizing, and tracking your data sources for the duration of the project. 

Follow Metadata Standards

Carefully follow a standard as you write metadata, and study it before you begin writing to identify how and where to document specific information.  For example, metadata may include multiple contacts that are responsible for different aspects of the data, including: 

  • Metadata creator
  • Data processor
  • Data access provider

It’s essential to document these roles correctly, and reviewing the standard beforehand can help insure the accuracy and integrity of your document. 

Use Plain Language

Don’t assume that readers will have a deep knowledge of your subject matter. Explain and articulate foundational concepts, even if they seem basic. 

Follow a Template or Style Guide

Develop and apply standard grammar, style, and format conventions, and use them consistently throughout the document. Create a generic stylesheet to reference as you move from one file to the next. 

  • Always place similar references in the same spot in your metadata files, such as adding at least one individual or organization as a citable author in the Cited Responsible Party element.
  • Give credit to anyone who worked on the project.
  • Use a consistent style and naming conventions for titles within your organization
  • Follow consistent capitalization and hyphenation rules 
Use Consistent Terminology and Naming Conventions 

Keep your terminology and definitions consistent throughout the document. Call out synonyms and abbreviations at the beginning of a paragraph or file if you plan to use them. Provide a rubric for sections that use a large amount of technical terminology.


Review your file for accuracy and completeness. Add any details or context needed to ensure the data can be used accurately. Have someone else perform a second review. 

Final Review

Read over the file once more for typos, grammar, and formatting errors before publishing.


Metadata production, validation, and management can be challenging and time consuming because of the many content sources, formats, storage structures and standards used in metadata management. Complex metadata standards and disparate tool-sets add to this challenge by creating interoperability and compatibility issues. 

Extensible Markup Language (XML) techniques can be used to simplify metadata management by automating format transformations, standards implementation, and other steps in the production cycle.  

XML can be used to map a schematic or model of the source data onto a target schema of the desired output. The mapping between a source schema and a target schema defines a transform (xslt file extension). The transform is then applied to the source XML to create the desired output. Programmatic metadata generation provides many other benefits, such as reduced effort, consistency, enhanced accuracy, and improved efficiency. 

The Metaserver tool and the Oxygen XML can both transform records from one standard to another. Before transforming an XML document in Oxygen XML Editor, you need to define the transformation scenario to apply to that document. A scenario is a set of values for various parameters that define a transformation. It is not related to a particular document, but rather to a document type. Oxygen XML Editor includes preconfigured built-in transformation templates scenarios, but also allows users to create custom scenarios.  


Metadata schemes provide the overall structure for metadata by describing how the document is set up, and usually address standards for common components like dates, names, and places. There are also discipline-specific schemas to address more specific elements.

The ISO 19139 Technical Specification provides Extensible Markup Language (XML) schemas enhance interoperability by providing a common specification for describing, validating and exchanging metadata about geographic datasets, dataset series, individual geographic features, feature attributes, feature types, feature properties, etc.

All of the main ISO standards: 19115/19139 (basic), 19115-2 (extensions) and 19119 (service) are built into this schema document.


A valid XML document conforms to the rules of the schema that defines its structure.

It’s easy to introduce errors in XML, particularly when working on large projects with a high file-count. Tools like Oxygen include error checkers that identify errors quickly and easily.

The XML used to share ISO Metadata is complicated enough that writing it without a validation tool is impossible. All sophisticated XML editors include a validation capability, but the error reports they generate can be hard to understand. Consult the following Validation Error Guide for help interpreting and fixing validation errors.

Error Messages in Oxygen
1. Element ‘someElementName’ cannot have character [children]
Error Message:
cvc-complex-type.2.3: Element 'gmd:organisationName' cannot have character [children], 
because the type's content type is element-only.

Errors related to "element-only" usually occur when content (text) is included in a tag that can only have tags as children. This usually means that you have written a string directly into an element without the required <gco:CharacterString> tag. For example:

<gmd:organisationName>Geoscience Australia (GA)</gmd:organisationName>

    <gco:CharacterString>Geoscience Australia (GA)</gco:CharacterString>
2. Expected content from

This error is related to changes in the namespace structure for Geographic Markup Language (GML). It can come in multiple forms including (but not limited to):

This error can be fixed by changing the gml namespace from gml to gml/3.2, usually in the root element of the document.

3. The content of element ‘gmd:CI_ResponsibleParty’ is not complete
Description: cvc-complex-type.2.4.b: The content of element 'gmd:CI_ResponsibleParty' is not complete.
One of '{"":role}' is expected.

This error is related to content missing from the gmd:ResponsibileParty object. This object requires a role element that is not there.

<gmd:CI_ResponsibleParty uuid="08D95C427FB128479945893256DADE37">

<gmd:CI_ResponsibleParty uuid="08D95C427FB128479945893256DADE37">
4. Invalid content was found
cvc-complex-type.2.4.a: Invalid content was found starting with element 'someElement'. 
One of '{someListOfElements}' is expected.

This error is usually related to incorrect ordering of the elements in the record. Even a correct element can cause a problem if it is in the wrong location. For example:

  <gmd:MD_CharacterSetCode codeList=""
  <gmd:LanguageCode codeList="" codeListValue="eng">eng</gmd:LanguageCode>
gives this error while the same content in the correct order:
  <gmd:LanguageCode codeList="" codeListValue="eng">eng</gmd:LanguageCode>
  <gmd:MD_CharacterSetCode codeList="" codeListValue="UTF8">UTF8</gmd:MD_CharacterSetCode>
is valid.

This error can also indicate that a required element is missing.

cvc-complex-type.2.4.a: Invalid content was found starting with element 'gmd:codeSpace'. 
One of '{"":authority, "":code}' 
is expected.

For example, this gmd:RS_Identifier is missing the required code element:

        <gco:CharacterString>location name</gco:CharacterString>

        <gco:CharacterString>code goes here</gco:CharacterString>
        <gco:CharacterString>location name</gco:CharacterString>
6. Not a valid value for ‘someType’
cvc-datatype-valid.1.2.1: '' is not a valid value for 'decimal'

This error indicates that an invalid value is present for an element with the specified type. It can happen if a bounding latitude or longitude is left empty:

6. Multiple occurrences of ID value ‘someId’

When id attributes are used to identify objects in a metadata record the values of those ids must be unique in the file.

cvc-id.2: There are multiple occurrences of ID value 'sourceTemporalExtent'

    <gml:TimePeriod gml:id="sourceTemporalExtent">
        <gml:description> ground condition </gml:description>
    <gml:TimePeriod gml:id="sourceTemporalExtent">
        <gml:description> ground condition </gml:description>

    <gml:TimePeriod gml:id="sourceTemporalExtent_1">
        <gml:description> ground condition </gml:description>
    <gml:TimePeriod gml:id="sourceTemporalExtent_2">
        <gml:description> ground condition </gml:description>
7. Attribute ‘codeListValue’ must appear on element ‘gmd:CI_DateTypeCode’

When translating from one dialect to another it is sometimes difficult to deal with unknown values. The <date> element in this example has no real content, but the translation included a gmd:CI_DateTypeCode element which has a required attribute: codeListValue. The solution in this case is to replace the entire <gmd:date> with an empty tag with a gco:nilReason attribute.


<gmd:date gco:nilReason="unknown"/>
8. Illegal HTML character: decimal 146 or 148

Some special characters (smart quotes / apostrophes) are illegal in html and stylesheets that encounter these characters will show an error. You can find these characters in the xml by searching for &#N; where N is 146 or 148 and use Oxygen's Search and Replace in Files tool to replace these characters in a collection of files.



The NCEI template WAF has metadata templates for different kinds of data, including  granule-level datasets, cruise-level events, publications, map layers, services, and collection level metadata. 

The NCEI Collection Level Metadata Template provides a section by section guide to filling out the four sections of the ISO 19115-2 standard, and provides a minimum information baseline for NCEI metadata records. The template can accommodate additional sections in the ISO standard, other fields that may be required by another standard such as the NOAA Completeness Rubric, or other information that is relevant to a specific dataset. 

The template is intended for NCEI staff who are directly involved in the management of collection level metadata records or for staff developing tools to support metadata. 

ISO Workbook

The ISO workbook was created  to act as an education and implementation guide to be used in conjunction with ISO 19115-2 Geographic information ─ Metadata Part 2: Extensions for imagery and gridded data ISO 19115-2:2009(E).

ISO Explorer

The ISO Explorer is a web-based comprehensive explorer for ISO 19115 and 19115-2. The pages show the correct order of the elements, links to child element/object, obligation, repeatability and references to more information and examples. 

International Organization for Standardization (ISO)

What is ISO 

The International Organization for Standardization (ISO) was founded in 1947, and is the world’s largest developer of voluntary International Standards. NCEI follows and implements the ISO metadata standard, as required by: 

  • The NOAA Administrative Order 212-15, which provides high-level guidance for environmental data and information management. 
  • The NOAA Environmental Data Management Committee (EDMC) Data Documentation Planning Directive, which establishes ISO 19115 Parts 1 and 2 and a recommended representation standard (ISO 19139) for documenting environmental data and information.

Geospatial ISO Standards

  • ISO 19115 Geographic information – Metadata: The ISO standard for documenting geospatial data. 
  • ISO 19115-2 Geographic information – Metadata – Part 2: Extensions for imagery and gridded data: An extension of ISO 19115 used to document information about imagery, gridded data, and remotely sensed data. The root of ISO 19115 metadata records will change from MD_Metadata to MI_Metadata when using ISO 19115-2. 
  • ISO 19110 Geographic information – Methodology for feature cataloguing: A separate standard and document that can be referenced in ISO 19115 if needed.
  • ISO 19111 Geographic information – Spatial referencing by coordinates: A separate standard and document that may be referenced from the ISO 19115 if needed.
  • ISO 19139: Defines the XML encoding of the ISO metadata standards, and sets the structure and rules for the validation. 
  •  ISO 19115-1: A revision of ISO 19115 that defines metadata elements and schema that describe geospatial resources i.e. datasets and services. 

ISO Organization and Content

ISO utilizes Unified Model Language (UML) diagrams and tables to describe the standard. The Production Rules of ISO 19115 diagram defines the “MD_Metadata” and shows containment relationships with the other metadata classes. ISO is organized in Sections and Packages:

  • Section: Groupings of similar information.
  • Package: Logical groupings of elements found in multiple locations within Sections. Two letter abbreviations denote the packages.
  • Class name: The class name follows an underscore with the package letter abbreviation. 


Unified Modeling Language (UML) is used to represent the relationships among classes and objects in object oriented programming. 

Relationships can be represented in the ISO UML models as associations, aggregations, compositions, generalizations, and dependencies.

  • Association: A general relationship between classes with an assumed two-way association unless otherwise specified. Arrows mark the end of a line, and also specify the direction of an association. The model will also show the ‘role’ of the target object in relation to the source object.
  • Aggregation: When one class functions as the ‘container’ and the other is nested within/inside. For example, MD_Metadata ‘contains’ MD_Distribution
  • Composition (Also known as Strong Aggregation): Used when the parts inside the container cannot exist without the container. If the container is deleted, then all of the objects ‘inside’ the container are deleted as well. 
  • Generalization: Depicts a superclass and subclasses that may be substituted for the superclass. General overall constraints are documents through MD_Constraints, but the subclass MD_SecurityConstraints can substitute its superclass MD_Constraints (Security constraints has the same objects as MD_Constraints, and additional objects that specifically address documenting constraints dealing with security.
  • Dependency (also known as Instantiation): Similar to an ‘IF’ statement: If accessConstraints or useConstraints = “otherRestrictions” then “otherConstraints” must be used.
UML Cardinality

Multiplicity and cardinality are denoted on the UML associations to identify classes as mandatory or optional, and to specify how many times they may repeat.

Metadata Entity UML



Collection Manager

The Collection Manager is a single system consisting of different tools which allows NOAA users to import, create, update, store, reuse, export, validate, assess and publish their collection metadata. This system ensures that all metadata meet NOAA metadata standard practices.


NOAA’s NCEI developed a Data Stewardship Maturity Questionnaire (DSMQ) in support of the NOAA OneStop project as an intuitive way to quickly and systematically assess stewardship maturity of individual digital environmental datasets. Built on the NOAA/CICS-NC Data Stewardship Maturity Matrix (DSMM), the DSMQ presents users with a mechanism for assessing the stewardship aspects of their datasets in a streamlined and user-friendly manner. The resulting quantitative assessments of dataset maturity are beneficial in managing organizational data holdings and associated information. The DSMQ is integrated with the NCEI Collection Metadata Enterprise Tool (CoMET). 

CoMET is a tool that allows users to import, create, edit, validate and publish ISO metadata records. CoMET is one app within the suite of metadata applications developed within NCEI’s Collection Manager.

Launch CoMET


Web Accessible Folders (WAF’s)

WAF’s contain ISO standard metadata records archived by subject. Each record can be viewed as an XML, KML, Full Text, or HML landing page, and as a FAQ page. Each record is assessed for RubricV2, DOI Readiness, CSW Readiness, and Components and they can be accessed with each record. 

Access NCEI WAFs


Docucomp is a NOAA-owned web application for inserting, editing, and managing XML components, which are chunks of XML that describe specific pieces of metadata content. They are stored in a database and managed with REST web services. The REST services support insert, search, update and delete operations. You will need a NOAA account to use docucomp.

Launch Docucomp



Metaserver is a NOAA-owned tool to help you:

  • Assess individual records with Record Services
  • Process records with WAF On Demand
  • View Record Sources and Collection Sources
  • Metrics DB for quality/completeness

You will need a NOAA account to use Metaserver. 

Launch Metaserver


Metaserver User Guide

Oxygen XML Editor

Oxygen is an XML development tool that provides a comprehensive suite of XML authoring and development tools. You can use oxygen XML Editor to work with all XML-based technologies including XML databases, XProc pipelines, and web services.


How to use Oxygen

What is XML?

XML, or eXtensible Mark-up Language, is a set of rules for encoding documents in machine-readable form.  XML emphasizes simplicity, interoperability, and usability in an online environment, and can be presented in a more user friendly HyperText Markup Language (HTML) landing page when a stylesheet is applied. 

Tag: A markup construct that begins with "<" and ends with ">". 

start-tags <section>
end-tags <section/> or </section>

Element:  A logical component of a document that either begins with a start-tag and ends with a matching end-tag, or consists only of an empty-element tag. The characters between the start- and end-tags, if any, are the element's content, and may contain markup, including other elements, which are called child elements. 

<Greeting> Hello, World. </Greeting>

Attribute: A markup construct consisting of a name/value pair that exists within a start-tag or empty-element tag. In the example (below), the element img has two attributes, src and alt:

<img src =”madonna.jpg” alt =’Foligno Madonna, by Raphael’/>

Another example would be Connect A to B. where the name of the attribute is "number" and the value is "3". For more information about attributes, see Using Attributes below.

Namespaces: You may notice in the XML that the element names have a three-letter code followed by a colon.


These codes are called namespaces. The namespace is a container providing context and rules for elements. A definition of a term may change, depending on what namespace is applied. The namespace abbreviation table identifies namespaces that may be found in the XML.

Using Attributes

XML elements can have attributes that  provide additional information about an element. Often, the additional information is not part of the data. Attribute values must contain either single or double quotes. Attributes tend to be "grouped" by certain types. Elements that are ISO roles (xml tags that start with lowercase) will often allow XLinks, uuidref, and nilReason attributes. Elements that are ISO objects (xml tags that start with two upper case package abbreviations) will often allow ids and uuids. The frame, calendarEraName, and indeterminatePosition are gml attributes and found within time positions.

<MD_Keywords> will allow the id and uuid attributes 
<gmd:thesaurusName> will allow the XLink attributes type, href, role, arcole, title, show, and actuate as well as the uuidref and nilReason attributes. 
<gml:beginPosition> will allow the gml attributes of frame, calendarEraName, and indeterminatePosition

id:  An identifier for the element, if specified, must be unique within the XML document. The identifier value must always start with a letter, an underline (_), or a colon (:). An XML element can have only one attribute of type ID. The identifiers used in the id attribute are XML Names that have significant restrictions. They must begin with a letter, an underline (_), or a colon (:), and, after the first character, be composed only of letters, digits, underlines, and hyphens (-). This attribute is often mandatory for such items as units and extents. 

<gml:BaseUnit gml:id=”lengthUnit”>
<gml:identifier codeSpace=”SI”>meters</gml:identifier>
<gml:unitsSystem xlink:href=””/>

Idref: A reference to an XML element in the XML document. The value must correspond to an attribute value of type ID in an existing XML element. The idref attribute allows an XML element to refer to another XML element within the same document that has a corresponding id attribute.

idrefs: A reference to one or more XML elements. The values must be separated by spaces and must correspond to existing XML element ID's.

uuid:  A uuid is assigned to an object when it is created and is stable over the entire life span of the objects. uuids are required for long-term distributed data management and for realizing update mechanisms. These identifiers are also called persistent identifiers. A uuid is a 16-byte number that consists of 32 hexadecimal (0-9 and a-f) values. The values are split into five groups, separated by hyphens in the form 8-4-4-4-12 or 8-4-4-16 for a total of 36 characters (32 values and 4 hyphens). Note: The uuid of any deleted object cannot be used again.

Note: The uuids are Universally Unique Identifiers which also have special characteristics.


uuidref: The uuidref attribute is used to refer to an XML element that has a corresponding uuid attribute.


uom: The uom attribute provides an identifier of the unit of measure used. The uom attribute is often mandatory for the element that uses it. 

        <gco:Distance uom=”meters”>10.0</gco:Distance>

frame: The frame attribute is optional and allows the user to specify the temporal reference system to be used for interpretation of the value of the time position. 

<gml:timePosition frame=”tcs.xml#geologyMA”>-2500</gml:timePosition>

calendarEraName: The calendarEraName attribute is optional and provides the name of the calendar era to which the date is referenced (e.g. the Meiji era of the Japanese calendar). 

      <gml:beginPosition calendarEraName=”Seireki”>1965</gml:beginPosition>
      <gml:endPosition calendarEraName=”Seireki”>1990</gml:endPosition>

indeterminatePosition: The indeterminatePosition attribute is optional and is used in time positions and can be used alone or it can quality a specific value for a temporal position. This attribute is often used to document unknown and present dates. The valid values for indeterminatePosition are “unknown”, “after”, “before”, and “now”. If indeterminatePosition = “now” the best practice is to put the date and time of the instance of metadata creation.

<gml:TimePeriod gml:id=”boundingTemporalExtent”>
        <gml:description>ground condition</gml:description>
        <gml:endPosition indeterminatePosition=”now”/>

XLinks: The XML Linking Language (XLink) allows elements to be inserted into XML documents for creating and describing links between resources, similar to HTML hyperlinks. Linking elements are recognized based on the use of a designated attribute named xml:link and a set of accompanying global attributes. The global attributes are type, href, role, arcrole, title, show, and actuate. If an XLink is used, the following ISO component is not used. 

type: The type attribute indicates the XLink element type, such as simple, extended, locator, arc, resource, or title. 

href: The value of the href attribute in linking elements contains a locator that identifies a resource, e.g., by a URI reference or by an XPointer specification. The xlink href attribute is used to reference a component, and the xlink title attribute is used to apply a human understandable name to the component. Components are snippets of XML describing a specific piece of metadata content, such as information about people, websites, documents, archives, instruments, etc. A component is the finest level (atomic level) of granularity in a metadata record. Components are stored once and used as often as required within a metadata collection. Components provide significant storage and editing advantages over the traditional metadata management method of storing each record as a whole. XLinks can be used to reference a component from an unresolved metadata record (unresolved meaning that the metadata record contains xlinks). The xlink references a specific component by its unique identifier (UUID). During the resolve process, a component referenced via XLink is retrieved and embedded in the record (resolved metadata record). 

<gmd:contact xlink:href=””/>

role: The role attribute specifies a part of the link's semantics. The value of this attribute indicates a property that the entire link has and identifies to the application software the meaning of the link. This allows the application to show different symbols for the different kinds of links. 

arcrole: The arcrole attribute corresponds to the Resource Description Framework (RDF) notion of a property, where the role can be interpreted as stating that "starting-resource HAS arc-role ending-resource." This contextual role can differ from the meaning of an ending resource when taken outside the context of this particular arc. For example, a resource might generically represent a "person," but in the context of a particular arc it might have the role of "mother" and in the context of a different arc it might have the role of "daughter."

title: The title attribute indicates a human-readable description of the entire link. 

<gmd:contact xlink:href=" 0800200c9a66" xlink:title="DOC/NOAA/NCEI> National Centers for Environmental Information (pointOfContact)"/>

show: This attribute indicates the behavior policies to use when the link is traversed for the purpose of display or processing. The embed value indicates that the designated resource should be embedded in the body of the resource and at the location where the traversal started. The replace value indicates that the designated resource should replace the resource where the traversal started. The new value indicates that the designated resource should be displayed or processed in a new context.

actuate: The actuate attribute is used to express a policy as to when the traversal of a link should occur. The auto value indicates that the resource is automatically traversed. The user value indicates that the link is traversed only on the request of the user. The valid values for actuate are “onLoad”, “onRequest”, “other”, and “none”.

nilReason: The nilReason attribute is used to explain why an element is not included in the XML. This attribute allows a reason (explaining why the actual value cannot be provided) to exist in place of an actual value. It can have the values “inapplicable”, “missing”, “template”, “unknown”, and “withheld”. 

            <gmd:date gco:nilReason=”unknown”/>
                <gmd:CI_DateTypeCode codeList=”” codeListValue="publication">publication</gmd:CI_DateTypeCode>

Using CodeLists 

To standardize values for certain metadata elements, ISO metadata uses codelists. A codelist is an enumeration of values. It is a flexible mechanism allowing the extension of code lists as needed. 

Use attributes to refer to a specific codelist value in a register. Codelists contain the attributes “codeList”, “codeListValue”, and “codeSpace”. The codeList attribute is mandatory and contains a URL that references a codeList definition within a registry or a codeList catalogue. The codeListValue attribute is also mandatory and contains the name of the selected value. The codeSpace attribute is optional and refers to the alternative expression of the codeListValue. See Annex C for more information about specific ISO codelists.

        <gmd:CI_DateTypeCode codeList=”” codeListValue="publication" codeSpace="002"</gmd:CI_DateTypeCode> 

Date and Time Formats 

The proper date formats correspond to ISO 8601, Data elements and interchange formats – Information interchange – Representation of dates and times. See Annex A for more information and examples. Calendar date is the most common date representation and is expressed as─


where YYYY is the year in the Gregorian calendar, MM is the month of the year between 01 (January) and 12 (December), and DD is the day of the month between 01 and 31. 

  • Ex: 2010-08-11 represents August 11, 2010. 

Time of day, the time representation, uses the 24-hour timekeeping system and is expressed as─ 

  • hh:mm:ss 

where hh is the number of complete hours that have passed since midnight, mm is the number of complete minutes since the start of the hour, and ss is the number of complete seconds since the start of the minute. 

  • Ex: 23:59:59 represents the time one second before midnight. 

Date and time represents a specified time of a specified day. When using the calendar date, the representation is— 


where T is used to separate the date and time components. 

  • Ex: 2010-08-11T13:31:01 represents 31 minutes and 1 second after 1 o’clock in the

afternoon of August 11, 2010.