Storing GSICS Processing History in ISO 19115 Metadata

Processing Components

GSICS processing consists of a series of processing steps. Each processing step can have zero or more input files, one or more output files, and accept zero or more run-time parameters. Some output files may also be used as input to another processing step. Such files are called intermediate files.

In the GSICS processing flow chart below, blue objects represent input files; green objects are intermediate files; pink are output files; and yellow objects are processing steps.

Processing Information in ISO 19115 Metadata Standard

The International Organization for Standardization (ISO) has developed a metadata standard for describing geographic information and services – ISO 19115. The standard provides a framework for storing information about identification, quality, spatial and temporal extent, spatial reference, and distribution of digital geographic data. The UML diagram below shows only the metadata classes available in the ISO 19115 standard for recording processing history.

Metadata Representation of Processing Components

Metadata templates of processing components are developed using the classes and their relationships as displayed in the UML diagram. Each template contains a number of metadata elements where metadata producer needs to supply information. The description of what information is appropriate for each of these elements is given in-line. Such text is surrounded with three dots (...description...) to indicate it must be replaced when the template is implemented.

The developed templates do not fully utilize the capabilities of the metadata classes. The information required for each template represents a useful subset that is practical to provide in an operational satellite data processing environment. They represent the baseline on which further additions can be built upon.

Metadata is given in the XML format. Familiarity with XML and the related XML Linking Language (XLink) is required to fully understand and utilize the metadata templates.

File Metadata Template

ISO 19115 standard has one metadata class (LE_Source) for all files used in processing so both input and output files share the same template. The designation what is an input or output file is made by the processing step metadata.

%CODE_DP{lang="xml" el="textarea" noautolinks="on" highlight="2,4,9,14,33,66,73,80"}% ...Short file description... ...File's name... ...Start time of the file's data in the YYYY-MO-DDTHH:MI:SSZ format... creation MD5 Checksum ...Date and time when the file's checksum was generated in the YYYY-MO-DDTHH:MI:SSZ format... creation The Internet Engineering Task Force (IETF) http://tools.ietf.org/html/rfc1321 ...File's MD5 checksum... ...Name of the organization from which the file can be obtained... ...Either the file's access URL or the home page of the organization from which the file can be obtained... %ENDCODE%

Processing Step Metadata Template

This template is made up of two metadata classes LI_ProcessStep and LE_Processing which through inheritance and association form the LE_ProcessStep class.

%CODE_DP{lang="xml" el="textarea" noautolinks="on" highlight="2,4,7,12,19,26,42,49,54,64,69,76,90,100,105,113,118,128,144,147"}% ...Short description of the processing step... ...Processing date and time in the YYYY-MO-DDTHH:MI:SSZ format... ...Name of the organization which executed the processing step... ...Contact email of the organization which executed the processing step... ...Home page of the organization which executed the processing step... ...Processing step's name... ...Title of the document describing the software implementation of the processing step... ...Date in the YYYY-MO-DD format of the latest revision of the software implementation document... revision ...Version identifier of the software implementation document... ...Name of the organization responsible for the software implementation document... ...URL of the software implementation document... ...Run-time parameters supplied to the software that implements the processing step. Preferably all the parameters that affect execution should be given but, at the minimum, those whose values differ from their default published in the software implementation document... Algorithm Theoretical Basis Document (ATBD) ...Title of the ATBD or its part that describes the processing step... ...Date in the YYYY-MO-DD format of the latest revision of the ATBD or its part that describes the processing part... ...Version identifier of the ATBD... ...Name of the organization which is the ATBD's author... ...URL of the ATBD or its part that describes the processing step...

%ENDCODE%

About XLinks in the Templates

The presented metadata templates have XML elements with an attribute xlink:href. Presence of this attribute in an XML element establishes a hyperlink relationship between that element and another resource. Hyperlinked resources in the templates are other metadata elements that can be either local (present in the same metadata record) or external.

While the xlink:href attribute alone is sufficient to semantically describe hyperlinking intention, it does not provide enough information on how such action should be performed. The XLink standard has a few more attributes available to describe the hyperlinking functionality. How those additional XLink attributes are to be applied in the metadata templates is illustrated using an example XML element: %CODE_DP{lang="xml" el="textarea"}% <example_element xlink:type="'resource' | 'locator'" xlink:show="embed" xlink:actuate="onRequest" xlink:title="...Short hyperlink description..." xlink:href="...URL of a metadata object..."/> %ENDCODE%

• xlink:type="resource" or xlink:type="locator" – the hyperlink is to a local or external resource.
• xlink:show="embed" – the hyperlinked resource is to be embeded within the linking element when processed.
• xlink:actuate="onRequest" – processing of the hyperlink occurs only on request.
• xlink:title="text" – short description of the hyperlink.
• xlink:href="URL" – location of the hyperlinked resource.

The additional attributes and their values are chosen to provide more complete context about the xlink:href hyperlink. They should be assumed as being present when implementing the templates.

Putting All Together

What has been described so far are just metadata building blocks for the processing components. One of the benefits of using XML as storage format is ability to validate content against a schema . The template below is deliberately developed for that purpose. It contains the minimum amount of the required metadata content for one output file that when combined with the processing history metadata will pass validation against the ISO 19115 XML schema.

%CODE_DP{lang="xml" el="textarea" noautolinks="on" highlight="4,7,10,15,22,56,74,92,110,141,35,38,39,48"}% <?xml version="1.0" encoding="UTF-8"?> http://www.ngdc.noaa.gov/metadata/published/xsd/schema.xsd" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gmi="http://www.isotc211.org/2005/gmi"> ...Metadata file name... ...ISO 639-2 code of the language used for documenting metadata, for example "eng" for English... ...Metadata creation time as YYYY-MO-DDTHH:MI:SSZ... ...Name of the organization responsible for the metadata file... ...Home page of the organization responsible for the metadata file...

...File's THREDDS URL... http File's THREDDS page

...File's HTTP URL... http File's URL for HTTP download

...File's OPeNDAP URL... http File's URL for data access via OPeNDAP

...File's FTP URL... ftp File's URL for FTP download

...Processing history content goes here... %ENDCODE%