WMO Core Metadata Profile version 1 - WIS browsingwis.wmo.int/2010/metadata/version_1-2/WMO Core...

WMO Core Metadata Profile 1 Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

WMO Core Metadata Profile version 1.2

Guidelines on the use of Metadata for WIS

Document version: 0.1 (DRAFT)

Author: Jeremy Tandy (IPET-MDI)

Date: 12 November 2010

Change history:

I. Initial version (0.1) published for review [12-Nov-2010]


References and attributions


1. Introduction

Organisations providing information must enable its discovery, evaluation and use. In today’s

environment this is accomplished typically through a set of web services, which may interface with

multiple networks to allow discovery and retrieval of the information.

Metadata is data about data. It provides additional information about the data resource, to enable it

to be better understood and used to good effect.

A world without metadata would be like a world without labels - imagine walking down your

supermarket shopping aisle looking for a specific can of food but there were no labels on the

products:

Could you find what you were looking for?


Successful discovery of geospatial data resources, that is data containing a positional or locational

element relative to the Earth, depends on matching the search criteria to the metadata.

The WMO Information System (WIS) provides a variety of search mechanisms ranging from structure

menus to free text fields. A successful ‘search’ will depend as much on the metadata as on the

specific functions provided by the Global Information System Centres (GISC), Data Collection and

Production Centres (DCPC) and National Centres (NC) that comprise the WIS.

Geospatial metadata describes geospatial data; that is data containing a positional or locational

element relative to the Earth. It describes resources in terms of certain well-defined attributes, such

as resource topic category, resource title, or geographic extent of the resource. This description

allows users to search for keywords, names and phrases in particular contexts or in structured

searches. For example, an organisation’s name might be associated with a specific role with regard

to the data, such as ‘responsible party’ or ‘distributor’. Such associations, combined with the use of

‘controlled vocabularies’ (i.e. standardised lists of terms, such as abbreviations for countries or code

lists for categories) and standardised formats for values (e.g. for dates or geographic extents) can

greatly improve the efficiency of discovery.


2. About metadata

What is commonly understood as metadata comprises:

Identification information, i.e. information to uniquely identify the resource such as:

o Title, abstract, reference dates, version, purpose, responsible parties, …

o Data extent,

o Browse graphics (overview, thumbnail, …),

o Possible usage;

Legal and security constraints;

Distribution information, i.e. information about the distributor of, and options for obtaining

the resource;

Reference system information, i.e. identification of the spatial and temporal system(s) used

in the resource data;

Quality and validity information, i.e. a general assessment of the quality of the resource data

including:

o quality measures related to the geometric, temporal and semantic accuracy, the

completeness or the logical consistency of the data;


o lineage information including the description of the sources and processes applied to

the sources;

o validity information related to the range of space and time pertinent to the data; to

whether the data has been checked to a measurement or performance standard or to

what extent the data is fit for purpose.

Maintenance information, i.e. information about the scope and frequency of updating of the

resource data.

“Metadata applied in a standard way ensures that a minimum amount of consistent information is

given about each dataset.

… it documents the procedures that were used to create and update the dataset and, more

importantly, is an opportunity to state what the data are not. It also provides contact information, so

that questions associated with the data can be fielded appropriately.

Metadata can be used to describe an object so that it can be located when needed. It can help

organize electronic records, facilitate interoperability across systems, provide digital identification,

and support both archiving and preservation.”1

Metadata is the starting point for access as it provides the means for ‘discovery’ of spatial

information.

1 Franks, P. Kunde, N. (Jan 2006) Why Metadata Matters, The Information Management Journal, Sept/Oct 2006


3. Using metadata

Metadata is document, file or record that sits with each dataset (or on a catalogue) and provides

background information about that record that is “computer readable”.

Metadata can be used to describe an object so that it can be located when needed by a search

engine, database or application. It can help organize electronic records, facilitate interoperability

across systems, provide digital identification, and support both archiving and preservation.

Metadata can be shared with others, without sharing the actual resource described by the

metadata.

Metadata applied in a standard way ensures that a minimum amount of consistent information is

given about each dataset.

As metadata documents the procedures that were used to create and update the dataset and, more

importantly, is an opportunity to state what the data are not. It also provides contact information, so

that questions associated with the data can be fielded appropriately.

“Metadata serves data discovery at multiple levels: – initial identification by query of keywords,

location, time, and attributes – assessment once located by use and access constraints; data quality

measures of positional and attribute accuracy and sources used; and statements as to data

availability, format and pricing – access the data, once deemed useful, using distribution URLs,

standard order process instructions and individuals to contact . This is very useful when dealing with

very large resources – e.g. ABS Census data for Australia or the Bathemetry of Australia.”1

A general scenario well describes a typical user’s interaction with metadata covering discovery,

evaluation and use of the associated data. This is applicable to a wide range of meteorological

concerns:


The WIS Metadata Use Case creates a general context associating existing and upcoming metadata

based solutions around three base user activities:

1. The discovery of resources. The user expects to identify a set of resources satisfying a basic

set of search criteria. The user interacts with a Search Engine connected to a set of metadata

repositories which document available resources. The Search Engine transfers the search criteria to

the metadata repository and expects a minimum set of metadata related to the matching resources.

It consolidates the answers and provides them to the user through an adapted interface.

2. The evaluation of available resources. The user has now identified a candidate resource,

potentially as a result of the discovery activity and wants to determine whether this resource

satisfies his/her requirements or not. For this purpose, it may use a Metadata Browser to examine

more detailed metadata about the resource.

3. The use of adequate resources. The user has chosen a resource and some access and use

rights have been granted to him/her. The resource is accessible and can be used through a series of

dedicated tools. Metadata will support the user in fully understanding the data and using it properly

resulting in more reliable analysis and more confidence in the results.

Different kinds of users may be involved in different activities: some experts may evaluate the

resources while operators may use them. There are cases where the user may be a software system

performing automating searches.

A prerequisite of delivering these outcomes is the establishment of effective maintenance for

metadata, i.e. the overall management of the metadata resources. This guidance document seeks to

provide would-be metadata authors with sufficient information to create metadata that conforms to

the WMO Core Metadata Profile and meets the expectations of the user community.

In terms of discovery, it is important to have sufficient information in the response so that a user is

able to recognize the data and determine its source (authority and address). The metadata should

refer to coherent sets or collections of data and datasets, and not to a range of nearly identical

component datasets.


4. General principles of metadata

This section describes some general high-level rules that apply to the creation of metadata. Whilst

the focus of this guidance material is the WMO Core Metadata Profile, these principles are generally

applicable to a wide range of metadata specifications.

Free text

The aim of a discovery metadata specification such as the WMO Core Metadata Profile is to define

metadata in a form that provides easily understood information for potential users of the data

resource, and is searchable in a computerised discovery metadata service such as that being

developed for the WIS. It is difficult to carry out searches on free text, since the same thing can be

written in different ways, for example ―WIS‖, ―WMO Information System‖, ― Système

d'information de l'Organisation météorologique mondiale. Hence, free text entries are discouraged

where the metadata is searchable.

By way of example, a Google search for the term ‘ANZLIC’ returns About 19,200 results (0.14

seconds). A semi-structured search for the term ‘ANZLIC metadata profile site:au’ returns About

2,320 results (0.20 seconds).This is better; it’s still a considerable effort to sift through these results.

Encoding the metadata with specific keywords (a controlled vocabulary) and providing that structure

to the users significantly improves the ability to locate the target resource.

Where only a limited number of options are available, code lists are specified. For some metadata

elements, such as TopicCategory, these may not correspond exactly to the theme of the dataset, and

the nearest option should be chosen. Where code lists are used, input and output facilities in a

metadata service should identify the corresponding element value. Where simple code lists are

insufficient a wide range of controlled vocabularies can be used, ranging from ‘flat’ vocabularies with

no structure (very similar to simple code lists), through multi-level vocabularies (taxonomies) and

relational vocabularies (ontologies). These schemes all provide a fixed domain of terms for a user to

choose from, but can offer significant utility in understanding that domain.

Obligation

As with other metadata specifications, elements in the WMO Core Metadata Profile are given as

mandatory, conditional or optional. Mandatory elements must be completed, and most software

tools do not allow the metadata to be entered if any mandatory elements are missing. Conditional

elements have a condition associated with them, and should be supplied when that condition is

fulfilled. Such conditions usually define the applicability of the element. Optional elements may not

always be completed. This can be for a number of reasons, for example if the element is not relevant

or its value is not known. In practice, optional elements are really conditional, and there is a set of

circumstances in which a value should be given, roughly corresponding to ―is it relevant?‖ and ―is

its value known?‖ Optional elements should not be ignored.


Element domains

Each metadata element has a range of allowable values, called its domain. These may be values in a

given range (e.g. positive integers) or a set of code values chosen from a list. Specifying the domain

helps with both the initial creation of data and quality checking. In some cases, default values may

be used, for example for elements relating to the metadata itself.

Spatial references

By definition, geographic data contains some form of spatial reference. The spatial reference

identifies the position of the object of interest in the real world. Spatial references can be given in a

number of forms, not just as Grid References. They can take the form of the name or identifier of a

geographic location which can be described in a gazetteer. Examples are property addresses,

postcodes and census areas. These spatial references are a key means of searching the data by

location, not only within the data resource, but also positioning the data resource in the world (e.g.

data for Scotland). A consistent set of spatial references enables spatial searches to be made for

datasets in a metadata service.

Date fields

Metadata can contain a multitude of dates identifying the different stages in the life cycle of the

data. Key dates are included in metadata. To enable searches to be carried out (e.g. date relating to

the period 1990 to 1999), these dates need to be recorded in standardised form. Unfortunately,

different standards are used in different places. The WMO Core Metadata Profile recommends that

the extended format defined in ISO 8601 (YYYY-MM-DD) is used. This standard also has a rich

mechanism to describe date-time, periods, durations etc.


5. Metadata standards for spatial resources

A (metadata) standard establishes:

• common terms;

• common definitions;

• common structure (whether an element is mandatory, conditional on another element, or

optional); and

• a method for extending the profile to address specialized or custom needs.

The International Standards Organisation Technical Committee for Geographic Information /

Geomatics (ISO TC/211) is responsible for creating a suite of standards associated with geographic

information, including several relating explicitly to metadata.

Other metadata standards are in usage around the world, such as Dublin Core

[http://www.dublincore.org/] and US Federal Geographic Data Committee’s metadata standard

(eponymously termed FGDC) [http://www.fgdc.gov/metadata/geospatial-metadata-standards].

However, the WMO policy is to employ the geographic information standards from ISO TC/211. This

is reflected in the WIS Technical Regulations WMO-No. 49:

5.2.1 This specification requires that each metadata record uploaded shall be represented in

compliance with the WMO Core Metadata Profile of ISO 19115 […]

ISO 19115 specifies a conceptual schema for geospatial information metadata; it is the foundation

for the WMO Core Metadata Profile. A set of minor inconsistencies related directly to the original

ISO 19115:2003 version are resolved in ISO 19115:2003/Cor. 1:2006. ISO 19115/Cor.1 supersedes

ISO 19115.

ISO 19115-2:2009 extends ISO 19115 to support imagery and gridded data specific requirements.

ISO/TS 19139 defines a set of encoding rules which can generally be applied to any of the spatial

conceptual standards. It proposes an XML Schema Implementation of ISO 19115 and the parts of the

conceptual foundation standards involved when implementing ISO 19115.

An XML Schema implementation of ISO 19115-2 has been proposed by France to ISO/TC 211 as a

new project ISO 19139-2, and is awaiting final publication from ISO TC/211.

These ISO/TS 19139 based XML schemas implementations are applicable to interchanges of

metadata and related information by transfer. They are also applicable more generally for a local or

remote storage of information when they are not accessed via a standard service. It is also

recommended that XML schemas implementations based on ISO/TS 19139 encoding rules should be

adopted when no standard XML schema Implementation are available.

http://www.dublincore.org/

http://www.fgdc.gov/metadata/geospatial-metadata-standards


6. A short primer to XML conventions

The WIS metadata will be encoded in XML according to the schema implementation defined in

ISO/TS 19139. To illustrate examples, this document contains snippets of XML code.

It is our aim to provide tooling for metadata authors that enables them to create metadata records

without seeing a single <XML> angle bracket! However, for the purpose of this guide, XML is used to

illustrate how metadata may be encoded. In the fullness of time, when tools are available, it is XML

that will be created behind the scenes. In the interim, it will be helpful for metadata authors to have

some familiarity with the ‘raw’ metadata record.

Some familiarity with XML is assumed; such as understanding the concept of namespaces, attributes

and schemas. Detailed knowledge is not a pre-requisite. If some additional insight is required on

XML and the associated technologies, the Internet is full of material to discover.

As a starting point, the specifications at the World Wide Web Consortium (W3C) are available here:

http://www.w3.org/TR/REC-xml/. XML.com [http://www.xml.com/] is also a great resource.

The examples are considered fragments in that they are not complete XML documents. The

following conventions are used:

The root element when shown shall be gmd:MD_Metadata

XML element tags will generally be shown on a single line

XML will be tabbed in where possible to aid reading

Where an XML element, including the start tag, end tag and content, is too long to show on

a single line, it shall break across more than one line automatically (i.e. under the control of

the word processing justification and formatting)

In some cases it might be possible and expedient to express an XML element on a single line

but in doing so the tabbing order is broken down

Missing XML content, removed while forming the fragment, shall be represented by an

ellipsis (...)

The schemas used for the WMO Core Metadata Profile are specified ISO/TS 19139 and ISO/TC

19136.

These schemas, along with associated resources such as Code List dictionaries, are hosted by ISO at

the following address:

http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/

ISO 19139 incorporates modules from other ISO TC/211 Geographic Information standards, and

further breaks the metadata schemas into a number packages for easier management. The result is

that a metadata record encoded in ISO 19139 will incorporate multiple namespaces.

The namespace identifier for gmd shall be: http://www.isotc211.org/2005/gmd

http://www.w3.org/TR/REC-xml/

http://www.xml.com/

http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/

http://www.isotc211.org/2005/gmd


The namespace identifier for gco shall be: http://www.isotc211.org/2005/gco

The namespace identifier for gmx shall be: http://www.isotc211.org/2005/gmx

The namespace identifier for gml shall be: http://www.opengis.net/gml

The namespace identifier for xlink shall be: http://www.w3.org/1999/xlink

The namespace identifier for xsi shall be: http://www.w3.org/2001/XMLSchema-instance

The root element, and in fact any element in an XML instance, may have an attribute called

xsi:schemaLocation which contains a value or set of values hinting at the physical location of

schemas which may be used for validation. Since this attribute provides only a hint validating parsers

are allowed to ignore it and use other means of locating the relevant schemas.

Currently, the WMO Core Metadata Profile is unable to use ISO’s officially hosted schemas as they

(correctly) refer to the gml/3.2 namespace (which is associated with GML 3.2.1 from ISO 19136).

Unfortunately, the GML 3.2 (from the DRAFT ISO 19136) is the commonly adopted schema within

the WIS implementation community. Whilst very similar, the differences cause validation errors for

content using the gml/3.2 namespace.

This issue is expected to be resolved by the next release of the WMO Core Metadata Profile.

Changes are expected to be invisible to users.

In the interim, the WMO Core Metadata Profile version 1.2 makes use of the schemas hosted at

NOAA’s National Geophysical Data Center (NGDC).

An example of the complete namespace declaration for WMO Core Metadata Profile version 1.2 is

shown below:

<gmd:MD_Metadata

xmlns:gco="http://www.isotc211.org/2005/gco"

xmlns:gmd="http://www.isotc211.org/2005/gmd"

xmlns:xlink="http://www.w3.org/1999/xlink"

xmlns:gml="http://www.opengis.net/gml"

xmlns:gmx="http://www.isotc211.org/2005/gmx"

xmlns:gts="http://www.isotc211.org/2005/gts"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.isotc211.org/2005/gmi

http://www.ngdc.noaa.gov/metadata/published/xsd/schema.xsd">

All namespaces in the example are defined explicitly. The use of a default namespace is currently

customary in XML records and is an acceptable construction in metadata XML for WIS.

Including explicit namespace prefixes for all elements in an XML record is the recommended and

preferred practice in metadata XML for WIS – but this is not mandatory. In this practice all

namespaces should be declared with a prefix and each element in the XML record should explicitly

include its namespace prefix.

http://www.isotc211.org/2005/gco

http://www.isotc211.org/2005/gmx

http://www.opengis.net/gml

http://www.w3.org/1999/xlink

http://www.w3.org/2001/XMLSchema-instance


Normal practice – default namespace declaration:

<MD_Metadata xmlns="http://www.isotc211.org/2005/gmd" … >

<fileIdentifier>

<gco:CharacterString>urn:x-wmo:md:no.met::HIRLAM12</gco:CharacterString>

</fileIdentifier>

…

</MD_Metadata>

Preferred practice – explicit namespace declaration:

<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd" … >

<gmd:fileIdentifier>


</gmd:fileIdentifier>

…

</MD_Metadata>

Use of explicit namespace declarations simplifies the process of incorporating XML fragments from

multiple sources to create a single metadata record.

Another convention that is used within this guidance

document is use of XPath [http://www.w3.org/TR/xpath/] to

describe the traversal of the XML structures.

The figure (left) provides a UML excerpt from the WMO Core

Metadata Profile.

To fully describe the ‘onLine’ element at the bottom we have

to traverse the ‘path’ from the root element MD_Metadata,

starting with a ‘/’ to indicate that we are starting from the

root:

/MD_Metadata/distributionInfo/MD_Distribution/

transferOptions/MD_DigitalTransferOptions/online

This can be abbreviated using wildcard characters (*) to:

/*/distributionInfo/*/transferOptions/*/online

http://www.w3.org/TR/xpath/


7. Profiling ISO 19115

ISO 19115 provides a built-in mechanism to modify the standard to suit the needs of a particular

community. The diagram below (known as the ‘fried-egg diagram’) suggests how a community will

choose to use only those elements outside the core of the ISO 19115 metadata model that meet

their needs. This is known as a ‘type-1’ profile (restriction only).

If additional requirements for that community cannot be satisfied within the standard, that

community are free to extend the standard as appropriate – a ‘type-2’ profile (extension). Clearly,

those extensions will not be interoperable outside their community. This is mitigated to some extent

by mapping the extensions to standard elements so that a generalist can still use the specialist data,

albeit without the specific semantics intended by the specialist’s community.

The benefits of developing a community profile are that one achieves further standardisation within

that community; all participants agree to use the same terms and mechanisms to describe their

content. This is especially important with ISO 19115 as it contains 400+ elements and explicitly

states that you should not try to use it all!

For reference, a UML representation of the full metadata model from ISO 19115:2003 can be found

at Annex C of this document.


For example, in Australia and New Zealand, the ANZLIC Metadata Profile provides the structure to

describe resources by defining metadata elements and establishing a common set of metadata

terminology, definitions and extension procedures, assisting organisations to access and share its

data and being compliant to the ISO 19100 series.

Further implementation of the ANZLIC Metadata Profile will promote interoperability between

information communities in Australia and New Zealand, as well as the rest of the world.

Their benefits are cited as being able to:

• Provide data producers with appropriate information to characterise their geographic data

and associated resources.

• Facilitate the organisation and management of metadata for geographic data and associated

resources.

• Enable users to apply geographic data in the most efficient way by knowing its basic

characteristics.

• Facilitate data discovery, retrieval and re-use. Users and applications will be better able to

locate, access, evaluate, purchase and utilise geographic data.

• Enable users to assess whether geographic data are suitable for their intended purpose.

• Leverage off existing software developed by major vendors and the global spatial

community.

• Enable transactions by web services using metadata about specific feature types, features,

attribute types or specific attributes.

The WMO Core Metadata Profile seeks to provide similar benefits for the WMO community. At this

stage it is heavily focused on supporting WIS by enabling common and consistent metadata records

to be published to the WIS Discovery-Access-Retrieval (DAR) catalogue. However, elements of ISO

19115 that are NOT included in the WMO Core Metadata Profile and are required to meet local

needs can simply be added without impacting interoperability.


To create a valid profile, one has to understand the needs of the community. Within WMO, this is

simplified by the provision of WIS Technical Specification [5.9 WIS-TechSpec-8: DAR Catalogue

Search and Retrieval] which outlines the mechanisms by which WIS DAR Catalogue content may be

searched according to indexed metadata attributes. At a minimum, for text-based searches, these

include:

I) abstract

II) title

III) author

IV) keywords

V) format

VI) identifier

VII) type

VIII) crs (coordinate reference system)

For date-based searches, these include:

I) creationDate

II) modificationDate

III) publicationDate

IV) beginningDate

V) endingDate

The user is also able to search according to location or geographical extent (bounding box is

specified in decimal degrees, north, west, south and east).

The fields defined for use in search is important to understand when preparing metadata records

that are intended to be discovered by the user community.


8. Managing metadata and catalogues

8.1 WMO Technical Regulations

The WIS Technical Regulations WMO-No. 49 (paragraph A.3.3) states:

A.3.3.4 WIS functions and operation shall be based on catalogues that contain metadata

describing data and products available across WMO, plus metadata describing dissemination

and access options. These catalogues shall be maintained by WIS Centres.

A.3.3.5 Through collaboration across all GISCs, each GISC shall provide comprehensive search

across catalogues. [...]

A.3.3.6 […] DCPCs shall maintain catalogues of their holdings and services, and provide

appropriate parts of these catalogues to the GISCs to ensure a comprehensive catalogue of

WIS holdings.

A.3.3.7 […] NCs shall provide associated metadata to other WIS Centres to become part of

the comprehensive catalogue of WIS holdings.

More information on the WIS data management and information exchange functions are described

in the practices, procedures and specifications set out in Annex VII (Manual on the WMO

Information System (WMO No. 1060)). Relevant excerpts2 from the ‘Manual on WIS’ are provided

below:

Para 2.3 [Interaction among WIS Centres]

[...] Data, products and metadata shall flow to a GISC from DCPCs and from NCs within its

area of responsibility. [...]

Para 2.5 [Discovery, Access and Retrieval Function] indicates metadata responsibilities of

participants …

As required per WMO No. 49, Vol. I, A.3, WIS shall be based on catalogues that contain

metadata describing the full set of data and products available across WMO and how these

may be retrieved. The Discovery, Access and Retrieval (DAR) function of WIS shall be the

primary realization of the WIS comprehensive catalogue, maintained collaboratively by all

WIS Centres.

The Technical Specification [5.2 WIS-TechSpec-1: Uploading of Metadata for Data and Products]

mandates the use of WMO Core Metadata Profile of ISO 19115:

5.2.1 This specification requires that each metadata record uploaded shall be represented in

compliance with the WMO Core Metadata Profile of ISO 19115 with a unique identifier.

2 Excerpts are sourced from Draft 5; minor amendments may have occurred for the final published version


8.2 Metadata management

8.2.1 Obligations

WIS Technical Regulations WMO-No. 49 mandate the responsibility for maintaining catalogues (of

metadata) within the WIS. This is further expanded in Annex VII (Manual on the WMO Information

System (WMO No. 1060)):

Para 2.1.1 indicates the types Centres operated within WIS. Participants will be affiliated to

one of these types of Centre.

2.1.1 In keeping with WMO No. 49, Vol I, A.3, Centres operated by WMO Members and their

collaborating organizations shall be categorized as one of the three types of WIS Centres

forming the core infrastructure of WIS:

- Global Information System Centres (GISCs),

- Data Collection or Production Centres (DCPCs),

- National Centres (NCs).

[...]

Para 2.3 [Interaction among WIS Centres]

[...] Data, products and metadata shall flow to a GISC from DCPCs and from NCs within its

area of responsibility. [...]

Para 2.5 [Discovery, Access and Retrieval Function] indicates metadata responsibilities of

participants …

As required per WMO No. 49, Vol. I, A.3, WIS shall be based on catalogues that contain

metadata describing the full set of data and products available across WMO and how these

may be retrieved. The Discovery, Access and Retrieval (DAR) function of WIS shall be the

primary realization of the WIS comprehensive catalogue, maintained collaboratively by all

WIS Centres.

Para 4 further illustrates the functional requirements for DCPCs and NCs, indicating that

they:

[…] shall provide metadata describing the information it makes available through the WIS

comprehensive catalogue […]

Clearly, the responsibility for metadata creation and maintenance lies with the Members operating

NCs and DCPCs.


8.2.2 Initial WIS deployment – a ‘baseline’ metadata catalogue

To support initial deployment of WIS, Météo France will create reference (or baseline) metadata for

the initial population of the WIS DAR catalogue on behalf of Members. This ‘baseline’ metadata set

will only describe those products routinely exchanged on via the GTS. Météo France provide a

software tooling to automate the process of creating WMO Core Profile records from Volume C1 and

the ‘Additional Data’ catalogue. Météo France will ensure that their metadata generation tools

comply with the conformance tests for the WMO Core Metadata Profile. These ‘baseline’ metadata

records will be marked as DRAFT. Tooling will be provided to help review & correction of these

metadata records.

Members are required to review the automatically generated WMO Core Profile records that

describe data products for they are responsible, amending the records as necessary. Once editing is

complete, Members must provide their final set of WMO Core Profile metadata records to Météo-

France, for insertion in the reference set and upload to the WIS DAR catalogue.

Météo France has agreed to continue maintenance of the reference WIS DAR catalogue on behalf of

Members who are unable to provide their WMO Core Profile metadata records to the WIS DAR

catalogue via a GISC; for example, if their GISC is not yet fully functional. Météo France will collate

amendments (perhaps using METNO bulletins) and re-publish the amended metadata records to the

WIS DAR catalogue. The duration of this service awaits agreement with Météo France.

Météo France ‘baseline’ metadata will be marked as DRAFT using the following scheme:

gmd:MD_Metadata/gmd:metadataMaintenance/*/gmd:contact/*/gmd:organisationName =

"Meteo France (on behalf of «NC or DCPC» by interim agreement with ICG-WIS)"

gmd:MD_Metadata/gmd:metadataMaintenance/*/gmd:contact/*/gmd:contactInfo/*/gmd:

address/*/gmd:electronicMailAddress = "[email protected]"

8.2.3 Procedures

Metadata records describing GTS products intended for global exchange will emulate the practices

established to populate Vol C1. Of particular note: metadata ownership resides with the data-

provider organization. Only the data-provided organization has the authority to create or update

metadata for their products they provide.

Each data-provider is responsible for the accuracy of their metadata. Note that data that does not

have a corresponding metadata record will not be visible in the catalogue: the implication is that it

will not be discoverable!

The maintenance schedule for metadata will be identical to those in the Manual on GTS for

maintaining Volume C1.

Each NC or DCPC will be affiliated with a specific GISC. NC or DCPCs must agree a mechanism to

publish (& delete) metadata records with their affiliated GISC. Bi-lateral agreement between NC /


DCPC and their affiliated GISC must include information on metadata exchange and deletion

mechanisms.

GISCs do not create any original metadata – they only publish content from NCs and DCPCs.

However, it is the GISC’s responsibility to ensure that their affiliated NCs or DCPCs are complying

with the metadata management policies. The WMO Secretariat currently maintains a list of

additional data separately from Volume C1 on the basis on the information provided by the

Permanent Representatives.

8.2.4 Uploading metadata to the WIS DAR catalogue

The Technical Specification [5.2 WIS-TechSpec-1: Uploading of Metadata for Data and Products]

identifies the mechanisms provided by GISCs to enable uploading metadata to the WIS DAR

catalogue:

5.2.5 For updating the DAR Metadata Catalogue, WIS Centres should support two kinds of

maintenance facilities: a file upload facility for batch updating (add, replace, or delete

metadata records treated as separate files); and an online form for changing metadata

entries in the DAR Metadata Catalogue (add, change, or delete of elements in a record as

well as whole records).

The mechanism for uploading metadata to the WIS DAR catalogue must defined according to bi-

lateral agreement between NC / DCPC and their affiliated GISC.

8.2.5 Deleting metadata from the WIS DAR catalogue

Only the data-owner has the authority to delete metadata records. The circumstances allowing

deletion of metadata records include:

when incorrect metadata is mistakenly or maliciously published; or

when product or information is no longer available the metadata record must be removed from

the DAR catalogue.

When a GISC is requested to delete a metadata record, it must remove the record from the DAR

catalogue (so that it can no longer be discovered), but stores the record temporarily for a period of

time prior to purging. The recommended ‘grace period’ is 7-days.

Notifying an affiliated GISC regarding the deletion of metadata records is a subject to local

agreement; bi-lateral agreement between NC / DCPC and their affiliated GISC must include

information on metadata exchange and deletion mechanisms.

Potential mechanisms include:

If OAI-PMH harvesting used to publish metadata to the GISC, use the OAI-PMH protocol; or


Publication of a service message (format to be agreed bi-laterally) to GISC requesting

deletion of record (using gmd:MD_Metadata/gmd:fileIdentifier as primary key); or

GISCs may provide metadata editor to allow data originator to delete the record themselves.

Note that an NC or DCPC may choose to maintain a historical archive of metadata records, even if

the dataset is no longer available.

Note to implementers:

OAI-PMH is the mandatory mechanism for GISC-to-GISC synchronization of DAR catalogues

OAI-PMH can (optionally) support propagation of deletion. The OAI-PMH protocol will be

used to achieve GISC-to-GISC synchronization of deleted records.

8.2.6 Harvesting metadata from external providers

It is desirable for the WIS to expose information in its comprehensive catalogue from external

communities. To do this, a WIS centre may choose to harvest metadata from external providers.

Clearly, these external providers are not under the jurisdiction of WMO, so are not bound by WMO

Technical Regulations. However, the WIS centre harvesting the external resource has a responsibility

to ensure content that it makes available within WIS is compliant with the operating procedures,

such as the provision of (globally) unique identifier for each metadata record.

Modifying the unique identifier for a metadata record (gmd:MD_Metadata/gmd:fileIdentifier) may

cause issues with harvesting processes used by systems such a Geonetwork [http://geonetwork-

opensource.org/] that are used to implement some parts of the WIS DAR catalogue; the unique

identifier is used as a primary key to identify records for harvesting. Changing this primary key may

result in the record appearing twice. To avoid needing to change the identifier dynamically during

harvest, it is envisaged that the addition of a WMO Core Profile compliant identifier will be added to

the metadata record by the external data provider according to bi-lateral arrangement a priori. Also,

those data custodians may choose to create new metadata records specifically for the WIS

community.

If the external data-provider is able to guarantee global uniqueness of their original

gmd:MD_Metadata/gmd:fileIdentifier this will remain acceptable as a primary key within WIS and

there is no requirement to add a WMO Core Profile compliant identifier.

WIS Centers should not modify gmd:MD_Metadata/gmd:fileIdentifer (as well as any other content)

when receiving metadata from external data provider, as far as they guarantee global uniqueness of

the fileIdentifier. UUID (Universal Unique Identifier) is considered globally unique in this respect.

However, a WIS Center may agree with the data provider to give a fileIdentifier compliant to the

WMO Core Profile. In that case previously given fileIdentifier is preserved in:

/*/dataQualityInfo/*/lineage/*/source/*/sourceCitation/*/identifier/*/code

http://geonetwork-opensource.org/

http://geonetwork-opensource.org/


8.2.7 Metadata files and file-naming conventions

File-naming conventions are explicitly referenced in Annex VII (Manual on the WMO Information

System (WMO No. 1060)) Para 5.1.6.

5.1.6 The WMO file naming convention shall be used for files and the associated metadata

record whenever it is necessary. The WMO file naming convention is documented in GTS

Manual (WMO No. 386, Vol. 1, Part II, Attachment II-15).

Each metadata file must contain one, and only one, record. Valid root elements are:

DS_Aggregate (implying all concrete sub-classes)

MI_Metadata

MD_Metadata

The relationships between metadata, datasets and aggregations are shown in the figure below:


MI_Metadata (from ISO 19115-2) is a sub-class of the main MD_Metadata class from ISO 19115. It

includes optional elements to describe the acquisition of imagery and gridded data

(MI_AcquisitionInformation). This information is important within the WMO community. As such

there is a desire to use MI_Metadata as the default root element.

However, the use of MI_Metadata currently causes validation errors in some WIS system

implementations (see Section 6 for more information). For the WMO Core Metadata Profile version

1.2 the preferred root element is MD_Metadata. This limitation is expected to be resolved in version

1.2.1.

Metadata will be encoded in XML according to the schema implementation defined in ISO/TS 19139.

Section 6 of these guidelines provides more information on the XML encoding of metadata.

Each metadata file must be comprised of well-formed XML. [http://www.w3.org/TR/REC-xml/#sec-

well-formed]

Metadata files must be encoded in UTF-8 [RFC3626, http://en.wikipedia.org/wiki/UTF-8]

The guidance on what information should be provided in a single metadata file (i.e. which datasets

the metadata seeks to describe) is based on a number of concerns:

The granularity level described by each metadata record;

The need to accommodate a simple solution for GTS datasets intended for global exchange;

and

The association of metadata files and data-files (or groups of data-files)

Two cases are used below to illustrate the varying approaches:

A. Metadata record A describes a dataset of bulletins which are stored in the 24-hour cache of the GISC. The metadata record is equivalent (although more informative) to a record in WMO vol C1 & describes the normal contents of this type of bulletin; for example SYNOPS from several observation stations; including MLO (Mauna Loa, Hawaii).

B. Metadata record B describes a long-term climate record from station MLO which is comprised of a collection of SYNOPTIC observations from, say, 1954.

http://www.w3.org/TR/REC-xml/%23sec-well-formed

http://www.w3.org/TR/REC-xml/%23sec-well-formed

RFC3626,%20http:/en.wikipedia.org/wiki/UTF-8


Whilst both datasets are continually changing, both metadata records are ‘quasi-static’; only needing to be changed when the observation regime changes (i.e. a new instrument is deployed or the exact observation location changes). The critical differences between records A & B in this example are:

Temporal extent: A has a relative temporal extent in any 24-hour period, whilst B has a temporal extent from 1954 to (almost) present day;

Citation authority: authority for A is int.wmo.wis, whilst B is gov.noaa Quality control: the dataset described by B may have undergone additional quality control to

validate the observation record for inclusion in a long-term archive

Whilst there may be significant overlap between A and B, one cannot assume that overlap exists.

Metadata records A and B describe entirely different products!

For efficiency, some Regional Transportation Hubs (RTH) ‘batch’ bulletins into groups (a.k.a.

messages) for efficient transfer. This is not evident to the end users, hence the content of a

transport-level GTS message is not required to be described by a metadata record. The

user/consumer is interested in the discrete bulletins which are currently catalogued in Volume C1

and will be exposed via the WIS Discovery Access and Retrieval (DAR)-metadata catalogue.


All files (including metadata) exchanged via the GTS must conform to the WMO file-naming-convention (see Attachment II-15 to the Manual on the GTS).

There are two types of data transfer in the GTS: file transfer and legacy bulletin. Legacy bulletins are solely identified by their abbreviated heading line (AHL), not by the filename of their transfer container (a.k.a. message) file.

Whilst OAI-PMH has been agreed as the protocol for GISC-GISC metadata harvesting, the WIS functional architecture indicates that the default mechanism for National Centres (NC) and DCPCs to pass their metadata records to their affiliated GISC is via sending of files. The meeting noted that the Internet connectivity is not always available and transfer via GTS is necessary in such case.

Therefore, filenames of all metadata files transferred via the GTS must conform to the endorsed file-naming-convention.

The file-naming-convention is summarized as:

«productPart»_«originatorPart»_«YYYYMMDDhhmmss»[_«additionalPart»].«type».[«compression»]

where «productPart» is «pflag»_«productidentifier», and «pflag» describes the format of «productidentifier»,

«originatorPart» is C_«CCCC», where «CCCC» is 4-letter code for the originating telecommunications centre, and

«type» is general format type from fixed acceptable list.

There are four types of «productPart» (hence values of «pflag») defined:

T_«TTAAii» and A_«TTAAii»«CCCC»«YYGGgg»[«BBB»] are provided for mapping bulletins into file transfer. The latter (A_ form) gives all AHL information, while the former (T_ form) is sufficient for bulletins not using «BBB» for amendment/correction (ex. NWP output). «YYGGgg» is day-in-month, hour, and minute in UTC.

Routing of bulletins between RTHs is specified using «TTAAii» and «CCCC».

The file-naming-convention is designed in order to resolve the limitations of too narrow namespace «TTAAii», and following two «pflag»s are prepared for that purpose.

W_«WMO Product Identifier» is globally unique identifier of the product, where «WMO Product Identifier» is a comma-separated list of data properties, including originating centre, data category, and other information, optionally followed by varying date and «BBB». Invariant string is intended to be used in routing control.

Z_«local product identifier» is a effectively a free-form identifier type, which is unique only within the originating centre.

Note: W_«WMO Product Identifier» scheme employs commas (,) to separate elements – this may create problems if these file-names are ever integrated into other lists or URLs as the comma is commonly used as a list delimiter in software systems.

Eventually bulletins and T_ and A_ product-identifiers will be phased out in favour of file transfer with W_ and Z_ identifiers. However, currently Volume C1 and the Routing Catalogue only covers bulletins, which have to be mapped to either T_ or A_ types of filename.

As a DAR metadata record is considered to be quasi-static (i.e. it is unlikely to change over the period

of days or months) certain instance-specific elements of the data-filename must be excluded from

the name of any associated metadata-identifier. For example, an ‘A_’ type product-identifier


‘«TTAAii»«CCCC»«YYGGgg»*«BBB»+’ would be truncated to ‘«TTAAii»«CCCC»’ to provide a unique

identifier that does not vary over time.

The WMO file-naming convention «pflag» has been modified to enable specific designation of

metadata files. New «pflag»s are:

TM

WM

ZM

There is no requirement for «pflag» = AM. For example, see these two data filenames that could

represent the same data content:

a. A_SMJP01RJTD271200_C_RJTD_201009271232.txt

b. T_SMJP01_C_RJTD_201009271232.txt

For filename (a), the [CCCC] "RJTD" and [YYGGgg] "271200" are duplicate information. Because WIS

metadata does not describe data instances, we will NEVER include the [BBB] in the metadata file-

name. Given these points, filenames created according to the «pflag»s TM and AM rules would carry

the same information. «pflag» = TM should always be used for the metadata file that describes

instances of files with «pflag» = T OR «pflag» = A.

The metadata filename relating the example data file-names above would be the same irrespective

of whether the filename is «pflag» = T or «pflag» = A:

c. TM_SMJP01_C_RJTD_201009271232.txt

Resulting from these constraints, the rules for metadata filenames are:

must comply with the WMO file-naming-convention;

must use «pflag» TM, WM or ZM as appropriate;

should truncate W_ product identifiers to form an invariant string; i.e. the date and amendment

/ correction code will be excluded

must ensure that Z_ product identifier are globally unique within the WIS

must use the «YYYYMMDDhhmmss» element from the top-level structure of WMO file-naming

convention to express the metadata publication / update date-time (this must represent the

same date-time as the MD_Metadata/dateStamp element); and

use an ‘.xml’ extension.

Examples:

TM_FCUK31_C_EGRR_20100310180000.xml

TM_HHXA05_C_BABJ_20100427083000.xml

WM_FR-meteofrance-toulouse,GRIB,ARPEGE-75N10N-60W65E_C_LFPW_20100428115800.xml


The '.met' file extension previously allocated to metadata will be deprecated.

8.2.8 Metadata versioning

The sequence (time-order) of metadata files with the same fileIdentifier will be assessed according

to the metadata date-time stamp. Thus, WIS implementers will assess the uniqueness of a metadata

record using only the fileIdentifier element and metadata creation date-time stamps:

gmd:MD_Metadata/gmd:fileIdentifier

gmd:MD_Metadata/gmd:dateStamp


9. Multi-lingual metadata

The core entities of the WIS, GISCs, will always operate on the primary English metadata.

At a minimum, metadata will be published in English. The abstract must primarily be in English;

noting that alternative language versions may be provided.

Where a 3rd party wishes add translation to a metadata record, they must propose changes to the

metadata custodian (data-owner) for the record. Only the metadata custodian (or their delegated

agent) has the authority to update the metadata. Updates will be propagated via the WIS via the

normal mechanism.

The default language and character set of the metadata record is identified in the

gmd:MD_Metadata/gmd:language and gmd:MD_Metadata/gmd:characterSet elements:

<gmd:language>

<gmd:LanguageCode

codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCo

delists.xml#LanguageCode" codeListValue="eng">eng</gmd:LanguageCode>

</gmd:language>

<gmd:characterSet>

<gmd:MD_CharacterSetCode


delists.xml#MD_CharacterSetCode" codeListValue="utf8">UTF 8</gmd:MD_CharacterSetCode>

</gmd:characterSet>

Each alternate language for the metadata is defined via a gmd:MD_Metadata/gmd:locale element:

<gmd:locale>

<gmd:PT_Locale id="locale-fr">

<gmd:languageCode>

<gmd:LanguageCode


delists.xml#LanguageCode" codeListValue="fra"/>fra

</gmd:languageCode>

<gmd:characterEncoding>



delists.xml#MD_CharacterSetCode" codeListValue="utf8"/>UTF 8

</gmd:characterEncoding>

</gmd:PT_Locale>

</gmd:locale>

Each metadata element with a CharacterString type and free text domain can be instantiated with a

gmd:PT_FreeText_PropertyType type:

<gmd:abstract xsi:type="gmd:PT_FreeText_PropertyType">

<gco:CharacterString>Abstract in english</gco:CharacterString>


<gmd:PT_FreeText>

<gmd:textGroup>

<gmd:LocalisedCharacterString locale="#locale-fr">Résumé en français</gmd:LocalisedCharacterString>

</gmd:textGroup>

<gmd:textGroup>

<gmd:LocalisedCharacterString locale="#locale-sp">Resumen en espanol</gmd:LocalisedCharacterString>

</gmd:textGroup>

</gmd:PT_FreeText>

</gmd:abstract>

This example assumes that an additional Spanish locale “locale-sp” was also defined. Also note the

use of an abbreviated XPointer version of a URI to refer to the location of an explicitly identified

element within the same file:

<gmd:LocalisedCharacterString locale="#locale-fr">Résumé en français</gmd:LocalisedCharacterString>

refers to

<gmd:PT_Locale id="locale-fr"> … </gmd:PT_Locale>

The abstract element is provided in the default language with a common gco:CharacterString

element. An additional gmd:PT_FreeText element is present, containing possibly a gmd:textGroup

element for every alternate translation.

Translations may be defined in translation files instead of being embedded in the metadata record.

In this case, it is simpler to group in a single file the definition of one alternate language and the

associated translations, each translated string identified by a unique id attribute. Here is an example

translation file (named “translation-fr.xml”):

<gmd:PT_LocaleContainer … >

<gmd:description>

<gco:CharacterString>This file contains all the French translations for my metadata

record(s)</gco:CharacterString>

</gmd:description>

<gmd:locale>

<gmd:PT_Locale id="locale-fr">

<gmd:languageCode>

<gmd:LanguageCode


delists.xml#LanguageCode" codeListValue="fra"/>fra

</gmd:languageCode>

<gmd:characterEncoding>



delists.xml#MD_CharacterSetCode" codeListValue="utf8"/>UTF 8

</gmd:characterEncoding>

</gmd:PT_Locale>

</gmd:locale>

<gmd:date>



</gmd:date>

<gmd:responsibleParty>



</gmd:responsibleParty>

<gmd:localisedString>

<gmd:LocalisedCharacterString locale="#locale-fr" id="abstractfr">Résumé en

français</gmd:LocalisedCharacterString>

</gmd:localisedString>



</gmd:PT_LocaleContainer>

The translated values of textual metadata elements are then referenced in the multi-lingual

metadata as follows:

<gmd:abstract xsi:type="gmd:PT_FreeText_PropertyType">

<gco:CharacterString>Abstract in english</gco:CharacterString>

<gmd:PT_FreeText>

<gmd:textGroup xlink:href="translation-fr.xml#abstractfr"/>

</gmd:PT_FreeText>

</gmd:abstract>

Multi-lingual Code Lists and other controlled vocabularies

ISO 19139 also provides mechanisms for multi-lingual reference data, such as Code Lists and other

dictionaries. Please refer to ISO/TS 19139 for more information.

It is anticipated that a future release of the WMO Core Metadata Profile will include multi-lingual

versions of the reference data.

Where controlled vocabularies sufficiently complex that they cannot be easily accommodated within

a Code List, alternative mechanisms such as the Simple Knowledge Organisation System (SKOS)

[http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/] can be used.

For information, an example of a multi-lingual SKOS vocabulary is provided at Annex F of this

document.

http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/


10. WMO Core Metadata Profile – UML models

Some familiarity with UML Class models is assumed. Note that the default multiplicity for element is

one [1] – i.e. a mandatory element. Other multiplicities are:

• [0..1] zero or one (optional)

• [0..*] zero to many (optional)

• [1..*] one to many (mandatory)

The data dictionary describing the elements of the WMO Core Metadata Profile can be found at

Annex A. The data dictionary provides detailed advice and examples on the usage of the WMO Core

Metadata Profile elements.

The figure below describes the MINIMUM metadata record that is compliant to the WMO Core

Metadata Profile. It contains only the MANDATORY elements.


The figure below describes the CORE metadata record and includes all the OPTIONAL elements of

the WMO Core Metadata Profile.


The figure below describes the «DataTypes» included in the WMO Core Metadata Profile.


11. WMO Core Metadata Profile – extensions to ISO 19115

The WMO Core Metadata Profile is a ‘type-1’ profile. This implies it only RESTRICTS the original

standard and adds / amends Code Lists.

Additional Restrictions

Please refer to the data dictionary (Annex A) for more information on these restrictions.

Target element(s) Description 1 MD_Metadata/fileIdentifier a. MANDATORY obligation

b. If metadata record describes data exchanged via the GTS, the strict convention for constructing the unique identifier shall be applied

2 MD_Metadata/hierarchyLevel a. Multiplicity limited to zero or one [0..1]

3 MD_Metadata/hierarchyLevelName a. Multiplicity limited to zero or one [0..1]

4 MD_Metadata/identificationInfo/ MD_Identification/descriptiveKeywords

a. MANDATORY obligation; a minimum of one descriptive keyword must be supplied referencing the WMO_CategoryCode «CodeList». The MD_Keywords/type for this entry shall be “theme” (from MD_KeywordTypeCode «CodeList»)

b. All keyword elements sourced from a particular thesaurus shall grouped into a single instance of the MD_Keywords class.

5 MD_Metadata/identificationInfo/ MD_DataIdentification/topicCategory

a. MANDATORY obligation

6 MD_Metadata/identificationInfo/ MD_DataIdentification/extent/ EX_Extent/geographicExtent/

a. MANDATORY obligation; a minimum of one instance of EX_GeographicBoundingBox shall be supplied

For compliance with the INSPIRE implementing rules [http://inspire.jrc.ec.europa.eu/] some

additional restrictions should be observed. These are not part of the WMO Core Metadata Profile,

but are included for completion.

Target element(s) Description 8 MD_Metadata/identificationInfo/

MD_Identification/resourceConstraints/ MD_Constraints/useLimitation

a. MANDATORY obligation; if no conditions apply, then a phrase such as “No conditions apply” should be recorded

2 MD_Metadata/dataQualityInfo/ DQ_DataQuality/report

a. MANDATORY obligation; used to indicate conformance with INSPIRE Implementing Rules

http://inspire.jrc.ec.europa.eu/


Amendments to Code Lists / new Code Lists

Please refer to Annex B for more information on the Code List extensions. An XML encoding of these

CodeLists is provided in Annex G.

Target Code List Change Description 1 CI_DataTypeCode amendment Additional term «reference» [004]

2 WMO_DataLicenseCode new WMO Data License applied to the data resource – derived from WMO Resolution 25 and Resolution 40 (http://www.wmo.int/pages/about/exchangingdata_en.html)

3 WMO_GTSProductCategoryCode new Product category used for prioritising messages on the WMO Global Telecommunications System (GTS)

4 WMO_CategoryCode new Additional topic categories for WMO community



Annex A – Data Dictionary & usage guidance notes

Note: items in the data dictionary marked in RED are amendments to ISO 19115 required to comply

with the WMO Core Metadata Profile


A Metadata Package data dictionaries

A.1 Metadata entity set information

Name / Role name Definition Obligation / Condition

Maximum occurrence

Data type Domain

1 MD_Metadata root entity which defines metadata about a resource or resources

M 1 Class Lines 2-17

2 fileIdentifier unique identifier for this metadata file

M 1 CharacterString URN – structure defined below (A.1.2)

3 language language used for documenting metadata

O 1 CharacterString ISO 639-2 recommended

4 characterSet full name of the character coding standard used for the metadata set

O 1 Class MD_CharacterSetCode «CodeList» UTF-8 recommended

5 hierarchyLevel scope to which the metadata applies

O 1 Class MD_ScopeCode «CodeList»

6 hierarchyLevelName name of the hierarchy levels for which the metadata is provided

O 1 CharacterString Free text

7 contact party responsible for the metadata information

M N Class CI_ResponsibleParty «DataType» A.9.3

8 dateStamp date that the metadata was created M 1 Class Date

9 metadataStandardName name of the metadata standard (including profile name) used

O 1 CharacterString See below (A.1.7)

10 metadataStandardVersion version of the metadata standard (version of the profile) used

O 1 CharacterString See below (A.1.7)

11 locale provides information about alternative localisations for linguistic extension

O N Class PT_Locale (from ISO 19139)

12 Role name: metadataExtensionInfo

information describing metadata extensions

O N Association MD_ExtensionInformation A.8

13 Role name: metadataMaintenance

provides information about the frequency of metadata updates, and the scope of those updates

O 1 Association MD_MaintenanceInfomation A.6

14 Role name: identificationInfo

basic information about the resource(s) to which the metadata applies

M N Association MD_DataIdentification A.2


15 Role name: metadataConstraints

provides restrictions on the access and use of metadata

O N Association MD_Constraints A.4

16 Role name: distributionInfo

provides information about the distributor of and options for obtaining the resource(s)

O 1 Association MD_Distribution A.7

17 Role name: dataQualityInfo

provides overall assessment of quality of a resource(s)

O N Association DQ_DataQuality A.5


A.1.1 gmd:MD_Metadata

19115 metadata is structured with one class gmd:MD_Metadata providing general information on

the metadata, and several association classes (identification info, quality info, maintenance info,

etc…) providing information on the resource itself. The multiplicity of these association classes is not

restrained to 1 in 19115, which enable in theory to describe several resources within the same

instance of gmd:MD_Metadata.

It is however strongly recommended to describe only one resource for each instance of

gmd:MD_Metadata, to simplify the structure of the file.

A.1.2 gmd:MD_Metadata/gmd:fileIdentifier

gmd:MD_Metadata/gmd:fileIdentifier is commonly used to provide a sort of identifier of the

metadata set. The name of the property implies that the metadata set is stored in a dedicated file,

which is not necessarily the case. However, in the case of metadata records published to the WIS

Data Access and Retrieval (DAR) Catalogue each metadata record will be encoded within a file.

Metadata identifiers do not need to explicitly match the filenames of the datasets they describe.

The WMO Core Metadata Profile recommends that gmd:MD_Metadata/gmd:fileIdentifier is a URI

(Universal Resource Identifier) structured as follows:

fixed string "urn:x-wmo:md:"

citation authority

Examples:

"int.wmo.wis"

"gov.noaa"

"edu.ucar.ncar"

"uk.gov.metoffice"

Citation authority "int.wmo.wis" is used for all datasets intended for global exchange

Citation authority for other datasets remains with the dataset provider, expressed using a

reverse-DNS name

A register of citation authorities will be developed and maintained by WMO secretariat to

support the WIS function.

separator colon ‘:’

empty string, reserved for future extension

separator colon ‘:’

unique identifier:

o if a GTS «TTAAii» and «CCCC» is allocated for the product (i.e. where the datasets

described by the metadata record employ the WMO file-naming convention P-flag = “T”

or P-flag=”A”) use «TTAAii»«CCCC» for the unique identifier;


o else if a WMO Product Identifier is allocated for the product (i.e. WMO file-naming

convention P-flag=”W”) use a truncated WMO product identifier field of the associated

data-files, excluding the date-stamp and any other varying elements as necessary; or

o else use a locally-unique identifier for the citation authority (not recommended for data

and products intended for global exchange).

Examples:

urn:x-wmo:md:int.wmo.wis::FCUK31EGRR

urn:x-wmo:md:cn.gov.cma::NMC.NWP.HCXA05BABJ

urn:x-wmo:md:int.wmo.wis::FR-meteofrance-toulouse,GRIB,ARPEGE-75N10N-

60W65E_C_LFPW

The structure is mandatory for metadata records that describe products exchanged via the GTS.

If an external data-provider is able to guarantee global uniqueness of their original

gmd:MD_Metadata/gmd:fileIdentifier this will remain acceptable as a primary key within WIS and

there is no requirement to add a WMO Core Profile compliant identifier.

Note: gmd:MD_Metadata/gmd:fileIdentifier elements are treated as CASE-INSENSITIVE when

assessing metadata records for duplication.

Best practice amongst OGC & others indicates that they are beginning to favour persistent URLs over

URNs as they are resolvable; an example would be: "cma.gov.cn/md/HCXA20BABJ.NMC.NWP". This

change may be reflected in future versions of this WMO Core Metadata Profile.

Where possible, the metadata identifier should map onto the invariant elements of the data-

filename to help a human reader infer the connection. Examples:

Data-filename instance: “A_SMCI01BABJ281200_C_BABJ_20100428120000.txt”

gmd:MD_Metadata/gmd:fileIdentifier=”urn:x-wmo:md:int.wmo.wis::SMCI01BABJ”

Data-filename instance: “W_FR-meteofrance-toulouse,GRIB,ARPEGE-75N10N-

60W65E_C_LFPW_20061001000000.bin”

gmd:MD_Metadata/gmd:fileIdentifier=”urn:x-wmo:md:int.wmo.wis::FR-meteofrance-

toulouse,GRIB,ARPEGE-75N10N-60W65E_C_LFPW”

As WIS will assess the uniqueness of a metadata record using only the fileIdentifier element

(gmd:MD_Metadata/gmd:fileIdentifier) and metadata creation date-time stamp

(gmd:MD_Metadata/gmd:dateStamp) version numbering or date-stamps are explicitly forbidden

from the gmd.fileIdentifier element. The gmd:MD_Metadata/gmd:dateStamp is the correct place for

this information. It may also optionally appear in the metadata filename (see Section 8.2.7).

Changing the gmd:fileIdentifier element in any way will appear to be a new product to the WIS!

Note to implementers:

I. The gmd:dateStamp within the metadata record should be distinguished from the

datestamp in OAI-PMH wrapper XML, which appears as oai:header/oai:datestamp.

Note that the OAI-PMH Implementation Guideline mandates that the OAI-PMH

Aggregators (i.e. a WIS Centre that provides metadata harvested from somewhere


else) must use local harvesting time as oai:datestamp. In other words, OAI-PMH

providers of GISCs and RTH-type of DCPCs must not use gmd:dateStamp as

oai:datestamp, because connected GISC cannot use incremental harvesting from

such provider. In some implementations the timestamp of metadata files are given

as oai:datestamp, and the operator can cause re-synchronization by changing

metadata file time stamps (such as touch(1) command). This is intended behaviour,

and developers should follow this methodology so as not to disable this

functionality.

II. OAI-PMH requires the identifier must comply with generic URI syntax (RFC2396, now

obsoleted by RFC3986). The naming convention defined in Recommendation 2

above is compliant to URN scheme of URI. The namespace identifier of URN (i.e. "x-

wmo") begins with "x-", which indicates an experimental namespace not registered

to IANA (cf. RFC3406). In the long term, the WIS community may wish to apply to

IANA for registration of formal namespace "wmo" under URN, or namespace under

"info:" URI scheme if the review process for URN does not work (http://info-

uri.info/registry/docs/misc/faq.html#use_urn describes such high burden).

Example XML encoding:

<gmd:fileIdentifier>


</gmd:fileIdentifier>

A.1.3 gmd:MD_Metadata/gmd:language and gmd:MD_Metadata/gmd:characterSet

It is recommended to select a value from the ISO 639-2 controlled vocabulary which uses three-

letter primary tags with optional subtags.

The Library of Congress (US) maintains a resource providing more information on this vocabulary:

http://www.loc.gov/standards/iso639-2/

The CodeList itself can be located here: http://www.loc.gov/standards/iso639-2/php/code_list.php

The WMO Core Metadata Profile strongly recommends that metadata files should be encoded in

UTF-8 [RFC3626, http://en.wikipedia.org/wiki/UTF-8]


<gmd:language>

<gmd:LanguageCode

codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xm

l#LanguageCode" codeListValue="eng">eng</gmd:LanguageCode>

</gmd:language>

<gmd:characterSet>



http://info-uri.info/registry/docs/misc/faq.html%23use_urn

http://info-uri.info/registry/docs/misc/faq.html%23use_urn

http://www.loc.gov/standards/iso639-2/

http://www.loc.gov/standards/iso639-2/php/code_list.php

RFC3626,%20http:/en.wikipedia.org/wiki/UTF-8


l#MD_CharacterSetCode" codeListValue="utf8">utf8</gmd:MD_CharacterSetCode>

</gmd:characterSet>

A.1.4 gmd:MD_Metadata/gmd:hierarchyLevel and

gmd:MD_Metadata/gmd:hierarchyLevelName

Fundamental to ISO19115 are the concepts of dataset (DS_DataSet) and aggregations

(DS_Aggregate). The hierarchy level is described in each metadata record via the gmd:hierarchyLevel

element; selecting the appropriate value from the MD_ScopeCode «CodeList».

Aggregations, or collections, of datasets can be of many types including series, platforms & sensors

etc. Every type of aggregation can include subsets and/or discrete datasets. The relationships

permitted within the ISO19115 conceptual model allow one to create a hierarchy of related

aggregations and datasets. This enables data providers to structure their metadata for improved

clarity & browsing.

NCAR’s Community Data Portal, the THREDDS (Thematic Realtime Environmental Distributed Data

Services) Project and NOAA’s National Geophysical Data Centre *http://www.ngdc.noaa.gov/] have

gained experience from structuring datasets within hierarchies. These dataset hierarchies can be

used to structure a browsable network of related datasets. Such browsable networks can be used to

supplement other browse-hierarchies inferred from the categorization of metadata records using

structured taxonomies etc. Reference information can be found at here:

http://www.unidata.ucar.edu/projects/THREDDS

Referring to the needs of WIS, the main focus is to enable the discovery of datasets. Building a

browse-hierarchy from a network of related metadata records will add value in the long-term.

However, this does not offset the additional complexity & risk of implementation during the

development-phase of the WIS.

In order to maintain simple GISC implementation, discrete metadata records will be used to

describe GTS products intended for global exchange, defining the hierarchy level as «dataset».

DCPCs and NCs may choose to describe their dataset at whichever level in the ‘hierarchy’ is deemed

appropriate. For example, a single TIGGE metadata record may describe 10000 data-files or more,

thus avoiding the need to create many hundreds or thousands of metadata records (TIGGE

reference: http://tigge.ecmwf.int/).

More information regarding the use of hierarchy levels to structure WMO Core Metadata will be

provided in future releases of this guidance. For reference, ISO 19115:2003 Annex H provides more

information about metadata hierarchy levels.

The element hierarchy level name may be used to provide an alternative name for this hierarchical

level within a particular organisation, to give more details, or to provide the level in another

language.

For example, within French IGN, the code gmd:MD_HierarchyLevel = “dataset” correspond to the

term “lot”, provided within the gmd:hierarchyLevelName field.

http://www.ngdc.noaa.gov/

http://www.unidata.ucar.edu/projects/THREDDS

http://tigge.ecmwf.int/


These elements have a multiplicity of 0..* in 19115. However, for the same reasons described in

A.1.1, the multiplicity in the WMO Core Metadata Profile is limited to 0..1.


<gmd:hierarchyLevel>

<gmd:MD_ScopeCode


l#MD_ScopeCode" codeListValue="dataset">dataset</gmd:MD_ScopeCode>

</gmd:hierarchyLevel>

<gmd:hierarchyLevelName>

<gco:CharacterString>Basic HIRLAM Model Output</gco:CharacterString>

</gmd:hierarchyLevelName>

Side note:

As implementation experience with WIS increases, IPET-MDI (WMO Inter Programme Expert

Team – Metadata and Data Interoperability) will continue to review the value of structured

dataset-hierarchies against the potential cost and risk of implementation. This may lead to

updated recommendations that positively endorse the use of dataset-hierarchies for DCPCs

or NCs dataset aggregations and perhaps even products intended for global exchange served

by the GISCs. The current recommendations imply that NMHSs such as JMA will be required

to create and maintain many thousands of metadata records to describe their GRIB bulletins

(approx. 21000 products). It is recognized that the query service at the GISC is likely to

return large numbers of positive hits to any query for JMA GRIB data, which is not

particularly helpful for the user. However, there is nothing to stop JMA from exposing a

richer, more sophisticated service interface(s) as a DCPC that provides higher levels of

control to the user. These interfaces would likely be described by fewer, more coarse-

grained metadata records, thus returning fewer positive hits to an initial query in the DAR

catalogue. In this case, the user experience is likely to be significantly improved

A.1.5 gmd:MD_Metadata/gmd:contact

The metadata point of Contact provides information on the person or organisation responsible for

the content of the metadata. (not for the organisation who set up the structure of the metadata).

It is recommended to provide (or require) a least a name and an e-mail address.

A.1.6 gmd:MD_Metadata/gmd:dateStamp

Where the WMO file-naming convention is used for the metadata record, the

gmd:MD_Metadata/gmd:dateStamp element shall match the dateStamp used within the filename.

Use a single date as specified by ISO 8601 in the extended date format (YYYY-MM-DD), where YYYY is

the year, MM is the month and DD is the day. Time (HH:MM:SS, where HH is the hour, MM the

minutes and SS the seconds) may be added if required, separated from the day by “T”. Refer to

Wikipedia for more information on ISO 8601: http://en.wikipedia.org/wiki/ISO_8601

http://en.wikipedia.org/wiki/ISO_8601


This should be updated whenever the metadata is updated due to a change in the dataset, or when

it is reviewed and confirmed as wholly correct.

In combination with the gmd:MD_Metadata/gmd:fileIdentifier element, the

gmd:MD_Metadata/gmd:dateStamp element shall be used to assess the uniqueness of a metadata

record. The dateStamp serves as a mechanism to discriminate between versions of metadata

records with the same fileIdentifier. The WIS will always choose the file with the most recent

dateStamp when selecting the appropriate metadata record.


<gmd:dateStamp>

<gco:DateTime>2010-11-08T09:44:24.165</gco:DateTime>

</gmd:dateStamp>

A.1.7 gmd:MD_Metadata/gmd:metadataStandardName and

gmd:MD_Metadata/gmd:metadataStandardVersion

gmd:MD_Metadata/gmd:metadataStandardName must always use the following text:

<gmd:metadataStandardName>

<gco:CharacterString>ISO 19115-2 Geographic information - Metadata - Part 2: Extensions for imagery and gridded

data</gco:CharacterString>

</gmd:metadataStandardName>

<gmd:metadataStandardVersion>

<gco:CharacterString>ISO 19115-2:2009-02-15</gco:CharacterString>

</gmd:metadataStandardVersion>

This describes the full title and short-name used to unambiguously identify the ISO19115-2

Geographic Information Metadata standard.


A.2 Identification information


Maximum occurrence

Data type Domain

18 MD_DataIdentification basic information required to uniquely identify a dataset

M 1 Specialised Class (MD_Identification)

Lines 19-29

19 citation citation data for the resource(s) M 1 Class CI_Citation «DataType» A.9.3

20 abstract brief narrative summary of the content of the resource(s)

M 1 CharacterString Free text

21 pointOfContact identification of, and means of communication with, person(s) and organization(s) associated with the resource(s)

O 1 Class CI_ResponsibleParty «DataType» A.9.3

22 spatialRepresentationType method used to spatially represent geographic information

O N Class MD_SpatialRepresentation TypeCode «CodeList»

23 spatialResolution factor which provides a general understanding of the density of spatial data in the dataset

O N Class MD_Resolution «union» See below (A.2.6)

24 language language(s) used within the dataset

M N CharacterString ISO 639-2 recommended

25 topicCategory main theme(s) of the dataset M N Class MD_TopicCategoryCode «Enumeration»

26 Role name: resourceMaintenance

provides information about the frequency of resource updates, and the scope of those updates

O N Association MD_MaintenanceInformation A.8

27 Role name: descriptiveKeywords

provides category keywords, their type, and reference source

M N Association MD_Keywords A.3

28 Role name: extent

extent information including the bounding box, bounding polygon, vertical, and temporal extent of the dataset

M N Association EX_Extent «DataType» A.9.1

29 Role name: resourceConstraints

provides information about constraints which apply to the resource(s)

O N Association MD_Constraints A.4


A.2.1 gmd:MD_DataIdentification

The WMO Core Metadata Profile is currently focused on data discovery to support WIS. As such, the

profile ignores the SV_ServiceIdentification class and conflates the «abstract» MD_Identification

with its concrete sub-type MD_DataIdentification.

A.2.2 gmd:MD_Identification/gmd:citation

See A.9.3 for details on CI_Citation.

It is mandatory to provide the /*/identificationInfo/*/citation/*/title and

/*/identificationInfo/*/citation/*/date.

The dataset title is one of the key elements for the discovery of a dataset. The usual name on which

the dataset is identified should be provided here. If this usual name is an acronym, the complete

name may be provided as an alternativeTitle.

A.2.3 gmd:MD_Identification/gmd:abstract

The abstract should provide a clear and concise statement that enables the reader to understand the

content of the dataset.

For guidance when completing the abstract, consider these points:

1. State what the “things” are that are recorded.

2. State the key aspects recorded about these things.

3. State what form the data takes.

4. State any other limiting information, such as time period of validity of the data.

5. Add purpose of data resource where relevant (e.g. for survey data).

6. Aim to be understood by non-experts.

7. Do not include general background information.

8. Avoid jargon and unexplained abbreviations.


<gmd:abstract>

<gco:CharacterString>

Products from the METNO Numerical Weather Prediction model. METNO is running the HIRLAM model. Check out

http://www.hirlam.org/ for details.

The model output has been subsetted, reprojected and reformatted using FIMEX (http://wiki.met.no/fimex/).

Contained fields: Potential temperature [K], Geopotential height [m**2 s**-2], U velocity [m s**-1], V velocity [m s**-1],

Vertical velocity [Pa s**-1] and Relative humidity [%]

Levels [hPa]: 1000, 925, 850, 700, 500, 400, 300, 250, 200, 150, 100, 70, 50, 30 and 10


Forecast Offset Times [Hours]: 0, 3, 6, 9, 12, 15, 18, 21, 24, 30, 36, 42, 48, 54, 60 and 66

Grid resolution [degrees]: 0.216 X 0.216

</gco:CharacterString>

</gmd:abstract>

A.2.4 gmd:MD_Identification/gmd:pointOfContact

See A.9.3 for more information on CI_ResponsibleParty.

It is recommended to provide (or require) a least a name and an e-mail address.

A.2.5 gmd:MD_Identification/gmd:resourceFormat

One question regarding the format is whether it is wanted to express the format of the resource or

the format in which the data may be distributed. The distribution format (see A.7) is the one defined

in the ISO Core, but when data is interchange by transfer, the resource format is relevant. Yet, in

that case, the resource format is also a distribution format (it is the format in which the data is

effectively distributed). In order to follow the ISO Core, it is consequently recommended to use the

distribution format because it is relevant when distributing the data both by transfer or

transmission.

For this reason, gmd:MD_Identification/gmd:resourceFormat is not described explicitly in the WMO

Core Metadata Profile.

A.2.6 gmd:MD_DataIdentification/gmd:spatialResolution

The purpose of this element is to provide an indication of how detailed the spatial data is. It is

equivalent to the ground sample distance. It should not be confused with the scale of a map which is

purely a display attribute (the spatial resolution should be defined in the specification of the data

resource).

The domain of this element is MD_Resolution «union»; which is comprised of two elements:

equivalentScale (type MD_RepresentativeFraction); and

distance (type Distance).

The WMO Core Metadata Profile recommends the use of the simpler distance measure. Example:

<gmd:spatialResolution>

<gmd:MD_Resolution>

<gmd:distance>

<gco:Distance

uom="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/uom/ML_gmxUom.xml#deg">

1</gco:Distance>

</gmd:distance>

</gmd:MD_Resolution>

</gmd:spatialResolution>

This example describes a 1° x 1° resolution. The unitsOfMeasure dictionary referenced also includes

meters (m) and radians (rad).


A.2.7 gmd:MD_DataIdentification/gmd:language

Refer to guidance above: A.1.3

If there is no textual information in the data resource, then it is recommended that a nil value should

be recorded.

A.2.8 gmd:MD_DataIdentification/gmd:topicCategory

The purpose of this element is to provide a basic classification for the data resource for use in initial

searches.

The CodeList provided by ISO 19115 for this element is large. It may appear useless for the needs of

one specific community, but it is mandatory in 19115 to facilitate the discovery of information within

a catalogue where data from multiple communities are stored.

Select one or more categories that most closely represent the topic of the data resource. If in doubt,

go by the topic categories rather than the examples. It is not necessary to include all categories

which may be applicable, but only a limited number of most relevant should be chosen (e.g.

topographic maps should not be classified as farming).

The MD_TopicCategory «Enumeration» is listed here for reference:

Name Domain code

Definition

farming 001 rearing of animals and/or cultivation of plants Examples: agriculture, plantations, herding, pests and diseases affecting crops and livestock

biota 002 flora and/or fauna in natural environment Examples: wildlife, vegetation, biological sciences, ecology, sea-life, habitat

boundaries 003 legal land descriptions Examples: political and administrative boundaries

climatologyMeteorologyAtmosphere 004 processes and phenomena of the atmosphere Examples: weather, climate, atmospheric conditions, climate change, precipitation

economy 005 economic activities, conditions and employment Examples: production, labour, revenue, commerce, industry, tourism and ecotourism, forestry, fisheries, commercial or subsistence hunting, exploration and exploitation of resources such as minerals, oil and gas

elevation 006 height above or below sea level Examples: altitude, bathymetry, digital elevation models, slope, derived products

environment 007 environmental resources, protection and conservation Examples: environmental pollution, waste storage and treatment, environmental impact assessment, monitoring environmental risk, nature reserves, landscape

geoscientificInformation 008 information pertaining to earth sciences Examples: geophysical features and processes, geology, minerals, sciences dealing with the composition, structure and origin of the earth’s rocks, risks of earthquakes, volcanic activity, landslides, gravity information, soils, permafrost, hydrogeology, erosion

health 009 health, health services, human ecology, and safety


Examples: disease and illness, factors affecting health, hygiene, substance abuse, mental and physical health, health services

imageryBaseMapsEarthCover 010 base maps Examples: land cover, topographic maps, imagery, unclassified images, annotations

intelligenceMilitary 011 military bases, structures, activities Examples: barracks, training grounds, military transportation, information collection

inlandWaters 012 inland water features, drainage systems and their characteristics Examples: rivers and glaciers, salt lakes, water utilization plans, dams, currents, floods, water quality, hydrographic charts

location 013 positional information and services Examples: addresses, geodetic networks, control points, postal zones and services, place names

oceans 014 features and characteristics of salt water bodies (excluding inland waters) Examples: tides, tidal waves, coastal information, reefs

planningCadastre 015 information used for appropriate actions for future use of the land Examples: land use maps, zoning maps, cadastral surveys, land ownership

society 016 characteristics of society and cultures Examples: settlements, anthropology, archaeology, education, traditional beliefs, manners and customs, demographic data, recreational areas and activities, social impact assessments, crime and justice, census information

structure 017 man-made construction Examples: buildings, museums, churches, factories, housing, monuments, shops, towers

transportation 018 means and aids for conveying persons and/or goods Examples: roads, airports/airstrips, shipping routes, tunnels, nautical charts, vehicle or vessel location, aeronautical charts, railways

utilitiesCommunication 019 energy, water and waste systems and communications infrastructure and services Examples: hydroelectricity, geothermal, solar and nuclear sources of energy, water purification and distribution, sewage collection and disposal, electricity and gas distribution, data communication, telecommunication, radio, communication networks

As with all «Enumeration»s, this list cannot be extended.

The most appropriate category for the WMO Core Metadata Profile is

climatologyMeteorologyAtmosphere.

As the WMO Core Metadata Profile is concerned (at this stage) only with datasets, the element is

MANDATORY.


<gmd:topicCategory>

<gmd:MD_TopicCategoryCode>climatologyMeteorologyAtmosphere</gmd:MD_TopicCategoryCode>

</gmd:topicCategory>


A.3 Keywords information


Maximum occurrence

Data type Domain

30 MD_Keywords Keywords, their type and reference source

M N Aggregated Class (MD_Identification)

Lines 31-33

31 keyword commonly used word(s) or formalised word(s) or phrase(s) used to describe the subject

M N CharacterString Free text

32 type subject matter used to group similar keywords

O 1 Class MD_KeywordTypeCode «CodeList»

33 thesaurusName name of the formally registered thesaurus or a similar authoritative source of keywords

O 1 Class CI_Citation «DataType» A.9.3


A.3.1 gmd:MD_Keywords

The purpose of this element is to indicate the general subject area of the data resource using

keywords. This enables searches to eliminate resources that are of no interest. Ideally, a

standardised set of keywords should be used, so that resources can be identified in any search. This

element is similar to Topic, which has a coded list of high-level categories; whereas Keyword allows

more appropriate terms to describe the data resource.

Keyword values should if possible be taken from a list of standard subject categories, and terms

covering the subject of the data resource should be selected.

Place-names (such as observation stations and other static sensor platforms) will be expressed as

both keyword (type=place) and geographicIdentifiers:

• MD_Metadata/identificationInfo/*/descriptiveKeywords/*/keyword

• MD_Metadata/identificationInfo/*/descriptiveKeywords/*/type = "place"

• MD_Metadata/identificationInfo/*/extent/*/geographicElement/*/geographicIdentifier/MD

_Identifier

Example XML encoding of a known geographic location use as a keyword:

<gmd:descriptiveKeywords>

<gmd:MD_Keywords>

<gmd:keyword>

<gco:CharacterString>http://wis.wmo.int/WMOVolumeAGazeteer.xml#ESSW</gco:CharacterString>

</gmd:keyword>

<gmd:keyword>

<gco:CharacterString>http://wis.wmo.int/WMOVolumeAGazeteer.xml#ESSB</gco:CharacterString>

</gmd:keyword>

…

<gmd:type>

<gmd:MD_KeywordTypeCode codeList=" http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml

#MD_KeywordTypeCode" codeListValue="place"/>

</gmd:type>

<gmd:thesaurusName>

<gmd:CI_Citation>

<gmd:title><gco:CharacterString>WMO Publication No. 9, Volume A, Observing Stations and WMO Catalogue of

Radiosondes</gco:CharacterString></gmd:title>

…

</gmd:CI_Citation>

</gmd:thesaurusName>

</gmd:MD_Keywords>

</gmd:descriptiveKeywords>


Currently, the International Meteorological Vocabulary (WMO-No. 182), NASA Global Change Master

Directory (GCMD) vocabulary and the WMO_CategoryCode «CodeList» are the recommended

choices for specifying thematic keywords.

Example XML encoding of International Meteorological Vocabulary thematic keywords:


<gmd:MD_Keywords>

…

<gmd:keyword>

<gco:CharacterString>Wind -- direction -- pressure level</gco:CharacterString>

</gmd:keyword>

<gmd:keyword>

<gco:CharacterString>Humidity -- pressure level</gco:CharacterString>

</gmd:keyword>

<gmd:type>

<gmd:MD_KeywordTypeCode


l#MD_KeywordTypeCode" codeListValue="theme">theme</gmd:MD_KeywordTypeCode>

</gmd:type>

<gmd:thesaurusName>

<gmd:CI_Citation>

<gmd:title>

<gmx:Anchor xlink:href="http://www.wmo.int/pages/prog/www/WDM/IPET-MDI-I/documents/doc2-1-2-IR4.doc">

MODIFIED WMO No. 182, International Meteorological Vocabulary

</gmx:Anchor>

</gmd:title>

…

</gmd:CI_Citation>


</gmd:MD_Keywords>


Note the recommended use of double-hyphens (--) to delimit the flattened keyword structure. Such

a practice would not be necessary if a more sophisticated vocabulary that provisions a unique

identifier to every term within the multi-level hierarchies were used.

Example XML encoding of NASA GCMD keywords:


<gmd:MD_Keywords>

<gmd:keyword>

<gco:CharacterString>Atmosphere > Altitude > Geopotential Height</gco:CharacterString>

</gmd:keyword>

<gmd:keyword>

<gco:CharacterString>Atmosphere > Atmospheric Water Vapor > Humidity</gco:CharacterString>

</gmd:keyword>

<gmd:type>

<gmd:MD_KeywordTypeCode



l#MD_KeywordTypeCode" codeListValue="theme">theme</gmd:MD_KeywordTypeCode>

</gmd:type>

<gmd:thesaurusName>

<gmd:CI_Citation>

<gmd:title>

<gco:CharacterString>Global Change Master Directory (GCMD) Scientific Keywords, Version

6.0.0.0.0</gco:CharacterString>

</gmd:title>

</gmd:CI_Citation>


</gmd:MD_Keywords>


Note the use of ‘>’ to represent the angle bracket ‘>’ normally used to delimit the GCMD keyword

structure. Angle brackets do not mix well with XML!

Other recommended thematic vocabularies include:

• CF Standard Names [http://cf-pcmdi.llnl.gov/documents/cf-standard-names/]

• GEMET Thesaurus [http://www.eionet.europa.eu/gemet]

• INSPIRE Spatial Data Themes [http://www.eionet.europa.eu/gemet/inspire_themes]

WMO maintains a large number of resources that are candidates for reference as keyword thesauri.

The majority of these are specified in relation to the WMO Table Driven Code Forms (BUFR and

GRIB). Information regarding these resources can be found here:

http://www.wmo.int/pages/prog/www/WMOCodes/TDCFtables.html

Categories and parameters:

• WMO BUFR Table A – Data Category

• WMO Common Code Table C-13: Data sub-categories of categories defined by entries in

BUFR Table A

• WMO Common Code Table C-14: Atmospheric chemical or physical constituent type

• WMO GRIB Code Table 0.0 Discipline of processed data

• WMO GRIB Code Table 1.3 Production status of data

• WMO GRIB Code Table 1.4 Type of data

• Multi-level parameter dictionary:

o WMO GRIB Code Table 4.0 Product ‘type’3

o WMO GRIB Code Table 4.1 Parameter category by product discipline

o WMO GRIB Code Table 4.2 Parameter number by product discipline and parameter

category

3 The exact title of the Code Table is ‘Product definition template number’

http://cf-pcmdi.llnl.gov/documents/cf-standard-names/

http://www.eionet.europa.eu/gemet

http://www.eionet.europa.eu/gemet/inspire_themes



WMO GRIB Code tables 4.201 (Precipitation type) to 4.223 (Fire detection indicator) provide Code

List domains for many of the GRIB parameters.

Geographic identifiers:

• ISO 3166 3-numeric country codes

• WMO Code Tables and Flag Tables Associated with BUFR/CREX Table B

o Code table 0 01 003: WMO Region number/geographical area

o Code table 0 01 101: State identifier

• WMO Common Code Table C-11: Originating / generating centres

• WMO Common Code Table C-12: Sub-centres of originating centres defined by entries in

Common Table C-11

• WMO Volume A Observing Station Gazetteer

• ICAO Aerodrome Gazetteer [?]

Note that each station in the Volume A gazetteer shall be assigned a unique identifier to supplement

the (mostly unique) WMO Station Code.

Quality control:

• WMO GRIB Code Table 4.12 – Operating mode … a list of operating modes for instruments

such as ‘maintenance mode’

• WMO GRIB Code Table 4.13 – Quality Control Indicator … a Boolean flag indicating the

application of quality control procedures (or not!)

• WMO GRIB Code Table 4.14 – Clutter filter indicator

• … etc.

Instrument and Process types (that may be used in specifying the lineage of the resource):

• WMO Common Code Table C-2 Radiosonde/sounding system used

• WMO Common Code Table C-3 Instrument make and type for water temperature profile

measurement […]

• WMO Common Code Table C-4 Water temperature profile recorder types

• WMO Common Code Table C-5 Satellite identifier

• WMO Common Code Table C-8 Satellite instruments

• WMO GRIB Code Table 4.3 – Type of generating process

• WMO GRIB Code Table 4.6 – Type of ensemble forecast

• WMO GRIB Code Table 4.7 – Derived forecast

• WMO GRIB Code Table 4.10 – Type of statistical processing

Other miscellaneous controlled vocabularies managed by WMO include:

• WMO GRIB Code Table 3.1 – Grid definition template number … a list of the coordinate

reference systems in common usage

• WMO GRIB Code Table 3.15 – Physical meaning of vertical coordinates … a list of parameters

used in specifying vertical coordinate reference systems


• WMO GRIB Code Table 4.4 – Indicator of unit time range … a list of commonly used

durations4

• WMO GRIB Code Table 4.5 – Fixed surface types and units … a list of common vertical levels

such as ‘Isobaric surface’, ‘Cloud base level’ and ‘Mean sea level’.

• WMO Common Code Table C-6: List of units for Table Driven Code Forms … a ‘units of

measure’ dictionary

It is anticipated that (at least) a sub-set of these resources will be provided as web-accessible

resources to support future releases of the WMO Core Metadata Profile.

4 Note: this is similar to the deprecated Code List WMO_DataFrequencyCode (see Annex B)


A.4 Constraint information (includes legal)


Maximum occurrence

Data type Domain

34 MD_Constraints restrictions on the access and use of a resource or metadata

Use obligation from referencing object

Use maximum

occurrence from

referencing object

Aggregated Class (MD_Metadata and MD_Identification)

Line 35

35 useLimitation limitation affecting the fitness for use of the resource or metadata. Example, “not to be used for navigation”

O N CharacterString Free text

36 MD_LegalConstraints restrictions and legal prerequisites for accessing and using the resource or metadata


N Specialised Class (MD_Constraints)

Lines 37-38

37 useConstraints constraints applied to assure the protection of privacy or intellectual property, and any special restrictions or limitations or warnings on using the resource or metadata

O N Class MD_RestrictionCode «CodeList»

38 otherConstraints other restrictions and legal prerequisites for accessing and using the resource or metadata

C / accessConstraints or useConstraints

equal “otherRestrictions”?

N CharacterString Free text


A.4.1 Usage constraints

The purpose of this element is to describe any restrictions on usage of the data. Use constraints are

different from restrictions on public access which describes limitations on access to the data. A data

resource can have open access (e.g. to look at it), but restricted use.

Multiple entries are permitted to express a multitude of usage license conditions. A separate

MD_Constraints element should be used to express each set of constraints. Related constraints may

be grouped.

Any known constraints should be identified. If no conditions apply, then it is strongly recommended

that “No conditions apply” should be recorded for

*/resourceConstraints/MD_Constraints/useLimitation.

Best practice suggests that the absence of the

/*/identificationInfo/*/resourceConstraints/MD_LegalConstraints/useConstraints element implies

Unrestricted usage. However, as indicated above, this lack of restriction should be explicitly stated.

Within the WMO context, Resolution 40 and Resolution 25 Essential Data states ‘free and un-

restricted’ usage. Whilst this is very similar to ‘no constraints apply’ it is useful to explicitly to

indicate that data-providers are sharing this dataset under WMO Resolution 40 or Resolution 25.

Custom use constraints from NCs or DCPCs can be expressed as follows:

<gmd:resourceConstraints>

<gmd:MD_LegalConstraints>

<gmd:accessConstraints>

<gmd:MD_RestrictionCode


delists.xml#MD_RestrictionCode"

codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>

</gmd:accessConstraints>

<gmd:otherConstraints>

<gmx:Anchor

xlink:href="http://www.ordnancesurvey.co.uk/oswebsite/opendata/licence/docs/licence.pdf">OS OpenData

licence</gmx:Anchor>

</gmd:otherConstraints>

</gmd:MD_LegalConstraints>

</gmd:resourceConstraints>

This method uses gmx:Anchor extend the standard free-text field, providing both an xLink to the URL

of the data license and a human readable version.

The same mechanism can be used to explicitly cite WMO Resolution 25 and Resolution 40 (WMO

Resolution 40 and Resolution 25 are described online here:

http://www.wmo.int/pages/about/exchangingdata_en.html). Thus Essential Data can be marked as:

<gmx:Anchor xlink:href="http://www.wmo.int/pages/about/exchangingdata_en.html">WMO

Essential</gmx:Anchor>

http://www.wmo.int/pages/about/exchangingdata_en.html


Whilst Additional data is marked:

<gmx:Anchor xlink:href="http://www.wmo.int/pages/about/exchangingdata_en.html">WMO

Additional</gmx:Anchor>

To express WMO Resolution 25 and WMO Resolution 40 the new CodeList WMO_DataLicenseCode

«CodeList» should be referenced. It is included here for reference:

Name Domain Code Definition

1. WMO_DataLicenseCode WMO_DatLicCd WMO Data License applied to the data resource – derived from WMO Resolution 25 and Resolution 40 (http://www.wmo.int/pages/about/exchangingdata_en.html)

2. WMO Essential 001 WMO Essential Data: free and unrestricted international exchange of basic meteorological data and products

3. WMO Additional 002 WMO Additional Data: free and unrestricted access to data and products exchanged under the auspices of WMO to the research and education communities for non-commercial activities

To express the legal validity of a Terminal Aerodrome Forecast (TAF), we must define a period of

valid usage. The recommended method is:

MD_LegalConstraints/useLimitations/CharacterString="PT12H"

MD_LegalConstrains/useConstraints/MD_RestrictionCode="otherRestrictions"

MD_LegalConstraints/otherConstraints/CharacterString="Valid usage period after issue"

In this case, we will need to ensure that MD_LegalConstraints/useLimitations/CharacterString shall

be an ISO 8601 compliant PERIOD definition.

GTS Product Categories have been enumerated in a new WMO_GTSProductCategoryCode

«CodeList»


1. WMO_GTS_ProductCategoryCode

WMO_GTSCatCd Product category used for prioritising messages on the WMO Global Telecommunications System (GTS)

2. GTS Category 1 001 GTS Category 1 – highest priority products

3. GTS Category 2 002 GTS Category 2



GTS priority can be expressed as follows:

MD_Constraints/useLimitation/CharacterString="GTS Category 1"

Within WIS the primary focus is to provide metadata guidance for authors describing datasets

routinely exchanged and freely accessible via the GTS so that these data resources can be discovered

in the WIS DAR catalogue. For this reason, limitations on access have been ignored within this

metadata profile.


Should data providers / custodians need to express access constraints, please follow the guidance

supplied for the base ISO 19115 standard.


A.5 Data quality information (includes lineage)


Maximum occurrence

Data type Domain

39 DQ_DataQuality quality information for the data specified by a data quality scope


Use maximum

occurrence from

referencing object

Aggregated Class (MD_Metadata) Lines 40-42

40 scope the specific data to which the data quality information applies

M 1 Class DQ_Scope A.9.7

41 Role name: report

quantitative quality information for the data specified by the scope

C / lineage not provided?

N Association DQ_Element «Abstract» Use specific concrete sub-class DQ_DomainConsistency

42 Role name: lineage

non-quantitative quality information about the lineage of the data specified by the scope

C / report not provided?

1 Association LI_Lineage

43 Intentionally left blank

44 Intentionally left blank

45 DQ_DomainConsistency adherence of values to the value domains


Use maximum

occurrence from

referencing object

Specialised Class (DQ_Element)

Lines 46-47

46 measureIdentification code identifying a registered standard procedure

O 1 Class MD_Identifier «DataType» A.9.2

47 result value (or set of values) obtained from applying a data quality measure or the outcome of evaluating the obtained value (or set of values) against a specified acceptable conformance quality level

M 2 Class DQ_Result «Abstract» Use specific concrete sub-class DQ_ConformanceResult

48 DQ_ConformanceResult Information about the outcome of evaluating the obtained value (or set of values) against a specified


Use maximum

occurrence

Specialised Class (DQ_Result)

Lines 49-51


acceptable conformance quality level

from referencing

object

49 specification citation of product specification or user requirement against which data is being evaluated

M 1 Class CI_Citation «DataType» A.9.3

50 explanation explanation of the meaning of conformance for this result


51 pass indication of the conformance result where 0 = fail and 1 = pass

M 1 Boolean 1 = yes 0 = no

52 LI_Lineage information about the events or source data used in constructing the data specified by the scope or lack of knowledge about lineage


Use maximum

occurrence from

referencing object

Aggregated Class (DQ_DataQuality)

Line 53

53 statement general explanation of the data producer’s knowledge about the lineage of a dataset

C / (DQ_DataQuality.sco pe.DQ_Scope.level =

“dataset” or “series”)?

1 CharacterString Free text


A.5.1 gmd:DQ_Quality/gmd:report

The purpose of this is to record the conformity to a specification, such as the INSPIRE implementing

rules. It describes degree of conformity with the product specification or user requirement against

which the data is being evaluated.

This element is MANDATORY if claiming to be INSPIRE compliance. In this case, the author must

assess the conformity of the data resource against its product specification or the INSPIRE thematic

data specification. If these have not been finalised, then the data resource’s own specification

should be used.

Specification: citation of the product specification or user requirements against which the

data resource is evaluated. A title and a reference date have to be provided: e.g. D2.8.I.5

INSPIRE Data Specification on Addresses – Guidelines, publication, 2010-04-26

Degree (pass): degree of conformity with the specification. This is Boolean (true or false)

depending on the conformity

Explanation: meaning of conformance for this result. For example, include a statement

about which aspects of the specification the data resource conforms and any exceptions.

A.5.2 gmd:LI_Lineage

The purpose of this element is to give an indication of how the data resource was created. It is useful

in determining its fitness for purpose.

Where possible, include statements on the following:

source material;

process used to create the data, including resolution of measurement;

method of updating; and

any quality control processes.

As a minimum, it is recommended that a general statement is made about the provenance of the

dataset. For example:

High data quality controlled according to the procedures of the GTS

A.5.3 candidate controlled vocabularies for data quality and lineage

WMO maintains a large number of resources that are candidates for controlled vocabularies. The

majority of these are specified in relation to the WMO Table Driven Code Forms (BUFR and GRIB).

Quality control:

• WMO GRIB Code Table 4.12 – Operating mode … a list of operating modes for instruments

such as ‘maintenance mode’

• WMO GRIB Code Table 4.13 – Quality Control Indicator … a Boolean flag indicating the

application of quality control procedures (or not!)


• WMO GRIB Code Table 4.14 – Clutter filter indicator

• … etc.

Instrument and Process types (that may be used in specifying the lineage of the resource):

• WMO Common Code Table C-2 Radiosonde/sounding system used

• WMO Common Code Table C-3 Instrument make and type for water temperature profile

measurement […]

• WMO Common Code Table C-4 Water temperature profile recorder types

• WMO Common Code Table C-5 Satellite identifier

• WMO Common Code Table C-8 Satellite instruments

• WMO GRIB Code Table 4.3 – Type of generating process

• WMO GRIB Code Table 4.6 – Type of ensemble forecast

• WMO GRIB Code Table 4.7 – Derived forecast

• WMO GRIB Code Table 4.10 – Type of statistical processing


A.6 Maintenance information


Maximum occurrence

Data type Domain

54 MD_MaintenanceInformation information about the scope and frequency of updating


Use maximum

occurrence from

referencing object

Aggregated Class (MD_Metadata and MD_Identification)

Lines 55-58

55 maintenanceAndUpdate Frequency

frequency with which changes and additions are made to the resource after the initial resource is completed

M 1 Class MD_MaintenanceFrequency «CodeList»

56 userDefinedMaintenance Frequency

maintenance period other than those defined

O 1 Class TM_PeriodDuration

57 updateScope scope of data to which maintenance is applied

O N Class MD_ScopeCode «CodeList»

58 contact identification of, and means of communicating with, person(s) and organization(s) with responsibility for maintaining the resource

O N Class CI_ResponsibleParty «DataType» A.9.3


A.6.1 gmd:MD_MaintenanceInformation/gmd:maintenanceAndUpdateFrequency

This identifies how often the updated data resource, or the associated metadata, is made available

to the user (for instance a data resource may be updated continuously, but released to the user only

monthly).

The choices are listed in CodeList MD_MaintenanceFrequencyCode. However, if is often more

appropriate to provide a user-defined frequency of update:

*/gmd:MD_MaintenanceInformation/gmd:maintenanceAndUpdateFrequency = “continual”

*/gmd:MD_MaintenanceInformation/gmd:userDefinedMaintenanceFrequency = «ISO8801-compliant

duration»

Wikipedia provides a useful resource on ISO 8601: http://en.wikipedia.org/wiki/ISO_8601.

A.6.2 Marking metadata as DRAFT

Météo France ‘baseline’ metadata (created for initial deployment of WIS) will be marked as DRAFT

using the following scheme:

gmd:MD_Metadata/gmd:metadataMaintenance/*/gmd:contact/*/gmd:organisationName =

"Meteo France (on behalf of «NC or DCPC» by interim agreement with ICG-WIS)"

gmd:MD_Metadata/gmd:metadataMaintenance/*/gmd:contact/*/gmd:contactInfo/*/gmd:

address/*/gmd:electronicMailAddress = "[email protected]"



A.7 Distribution information


Maximum occurrence

Data type Domain

59 MD_Distribution information about the distributor of and options for obtaining the resource


Use maximum

occurrence from

referencing object

Aggregated Class (MD_Metadata)

Lines 60-62

60 Role name: distributionFormat

provides a description of the format of the data to be distributed

C / MD_Distributor. distibutorFormat

not documented?

N Association MD_Format

61 Role name: distributor

provides information about the distributor

O N Association MD_Distributor

62 Role name: transferOptions

provides information about technical means and media by which a resource is obtained from the distributor

O N Association MD_DigitalTransferOptions

63 MD_Format description of the computer language construct that specifies the representation of data objects in a record, file, message, storage device or transmission channel


Use maximum

occurrence from

referencing object

Aggregated Class (MD_Distribution,

MD_Identification, and MD_Distributor)

Lines 64-67

64 name name of the data transfer format(s) M 1 CharacterString Free text

65 version version of the format (date, number, etc.)


66 specification name of a subset, profile, or product specification of the format


67 Role name: formatDistributor

provides information about the distributor’s format

O N Association MD_Distributor

68 MD_Distributor information about the distributor Use obligation from referencing object

Use maximum

occurrence from

referencing object

Aggregated Class (MD_Distribution and

MD_Format)

Lines 69-71


69 distributorContact party from whom the resource may be obtained. This list need not be exhaustive

M 1 Class CI_ResponsibleParty «DataType» A.9.3

70 Role name: distributorFormat

provides information about the format used by the distributor

C / MD_Distribution.

distributionFormat not

documented?

N Association MD_Format

71 Role name: distributorTransferOptions

provides information about the technical means and media used by the distributor

O N Association MD_DigitalTransferOptions

72 MD_DigitalTransferOptions technical means and media by which a resource is obtained from the distributor


Use maximum

occurrence from

referencing object

Aggregated Class (MD_Distribution and

MD_Distributor)

Line 73

73 online Information about online sources from which the resource can be obtained

O N Class CI_OnlineResource «DataType» A.9.5


A.7.1 gmd:MD_Format

The purpose of this element is to identify the various options for data formats that may be provided.

Entries should be recognised formats for data transfer, either standard or proprietary.

A.7.2 online distribution information for GTS products

For GTS products intended for global exchange, the onlineResource attribute of the MD_Distributor

object should conform to the following syntax:

http://«hostname»/«path»/«MD_Metadata/fileIdentifier»

«hostname»/«path»/ refers to the location of the web-service that serves the GTS product on

behalf of the data-owner. This will normally be the NC or DCPC who is responsible for publishing

the product, but may be a GISC node who has agreed to serve the ‘source’ data-files on their

behalf

«MD_Metadata/fileIdentifier» is the globally unique identifier of the metadata record that

describes the product being served.

Example implementation of such web service is available at

http://www.gisc.kishou.go.jp/cgi-bin/gisccache

The onlineResource for SMJP02 RJTD would be defined as:

http://www.gisc.kishou.go.jp/cgi-bin/gisccache/urn:x-wmo:md:int.wmo.wis::SMJP02RJTD

A.7.3 online distribution information for the WIS 24-hour cache

GISCs will be able to identify GTS products (for global exchange) using the citation authority in the

mandatory «MD_Metadata/fileIdentifier», being "int.wmo.wis", irrespective of the approach used to

specify the online resource.

Each GISCs will maintain a 24-hour cache of the globally exchanged GTS products, and serve those

products to users from their local (or preferred) GISC node. GISCs will need to amend the metadata

returned to a user in response to a search query to (additionally) indicate their 24-hour product

cache as an onlineResource that the user may choose to access.

Metadata authors do not need to know how GISC systems achieve this amendment. The following

schematics describe the process for information purposes only.


A.8 Metadata extension information


Maximum occurrence

Data type Domain

74 MD_MetadataExtension Information

information describing metadata extensions


Use maximum

occurrence from

referencing object

Aggregated Class (MD_Metadata)

Line 75

75 extensionOnLineResource information about on-line sources containing the community profile name and the extended metadata elements. Information for all new metadata elements

M 1 Class CI_OnlineResource «DataType» A.9.5

A.8.1 Extension metadata


<gmd:metadataExtensionInfo>

<gmd:MD_MetadataExtensionInformation>

<gmd:extensionOnLineResource>

<gmd:CI_OnlineResource>

<gmd:linkage>



<gmd:URL>http://www.wmo.int/pages/prog/www/WDM/IPET-MDI-

I/report/Report_IPETMDI_I_20100503.htm</gmd:URL>

</gmd:linkage>

<gmd:name>

<gco:CharacterString>WMO Core Profile of ISO 19115, v1.2, IPET-MDI I implementing

guidelines</gco:CharacterString>

</gmd:name>

</gmd:CI_OnlineResource>

</gmd:extensionOnLineResource>

</gmd:MD_MetadataExtensionInformation>

</gmd:metadataExtensionInfo>


A.9 «DataType» definitions

A.9.1 Extent information


Maximum occurrence

Data type Domain

76 EX_Extent information about horizontal, vertical, and temporal extent

M Use maximum

occurrence from

referencing object

Class «DataType» Lines 77-78

77 Role name: geographicElement

provides geographic component of the extent of the referring object

M N Association EX_GeographicExtent «Abstract»

78 Role name: temporalElement

provides temporal component of the extent of the referring object

O N Association EX_TemporalExtent

79 EX_GeographicBoundingBox geographic position of the dataset NOTE This is only an approximate reference so specifying the coordinate reference system is unnecessary

M Use maximum

occurrence from

referencing object

Specialised Class (EX_GeographicExtent)

Lines 80-83

80 westBoundLongitude western-most coordinate of the limit of the dataset extent, expressed in longitude in decimal degrees (positive east)

M 1 Class Angle -180,0 <= West Bounding Longitude Value <= 180,0

81 eastBoundLongitude eastern-most coordinate of the limit of the dataset extent, expressed in longitude in decimal degrees (positive east)

M 1 Class Angle -180,0 <= East Bounding Longitude Value <= 180,0

82 southBoundLatitude southern-most coordinate of the limit of the dataset extent, expressed in latitude in decimal degrees (positive north)

M 1 Class Angle -90,0 <= South Bounding Latitude Value <= 90,0; South Bounding Latitude Value <= North bounding Latitude Value

83 northBoundLatitude northern-most, coordinate of the M 1 Class Angle


limit of the dataset extent expressed in latitude in decimal degrees (positive north)

-90,0 <= North Bounding Latitude Value <= 90,0; North Bounding Latitude Value >= South Bounding Latitude Value

84 EX_GeographicDescription description of the geographic area using identifiers


Use maximum

occurrence from

referencing object

Specialised Class (EX_GeographicExtent)

Line 85

85 geographicIdentifier identifier used to represent a geographic area

M 1 Class MD_Identifier «DataType»

86 EX_TemporalExtent time period covered by the content of the dataset


Use maximum

occurrence from

referencing object

Aggregated Class (EX_Extent)

Line 87

87 extent date and time for the content of the dataset

M 1 Class TM_Primitive


A.9.1.1 gmd:EX_GeographicExtent and subclasses

This element defines the geographical extent of coverage of the data resource. Noting that Extent is

the overall coverage of the data resource, not the individual objects in the data resource; i.e. the

boundary of the extent must enclose all objects described by the data resource.

ISO 19115 allows one to document the geographicalExtent of a resource as a BoudingBox, a

BoundingPolygon or a Geographic Description.

However, the WMO Core Metadata Profile mandates the provision of a GeographicBoundingBox as a

minimum. More geographical extents may also be provided as appropriate.

The GeographicBoundingBox is determined by four coordinates.

West bounding longitude: western-most limit of the data resource extent, expressed in

longitude in decimal degrees (positive east)

East bounding longitude: eastern-most limit of the data resource extent, expressed in

longitude in decimal degrees (positive east)

North bounding latitude: northern-most limit of the data resource extent, expressed in

latitude in decimal degrees (positive north)

South bounding latitude: southern-most limit of the data resource extent, expressed in

longitude in decimal degrees (positive north)

Longitude and latitude shall be recorded in a coordinate reference system that has the same axes,

units and prime meridian as WGS84.

Where the sensor platform is mobile (e.g. AMDAR, ships or bouys) the bounding box will describe

the maximum reasonable extent within which the platform may operate, potentially a global extent.

However, it should be noted that GTS practices (tables C1, C2 & C3 of the Manual on GTS) keep the

extent of the bulletin fixed and require that the data from mobile platforms is allocated to the

appropriate bulletin based on the location of the platform.

Note:

specifying datasets that include the north or south poles may be difficult using the

geographic bounding box. Similarly, best practices on acceptable units for lat/lon must be

provided (e.g. -180 to +180, -90 to +90; 0 to 360; or East/West notation.

The BoundingPolygon is a GML Object (GM_Object).

The GeographicDescription provides an identifier of the area, and should then point on a well-known

identifier, based on a published standard. For example: ISO 3166-3:1999 provides codes for the

representation of names of countries and their subdivisions.


Place-names (such as observation stations and other static sensor platforms) will be expressed as

both keyword (type=place) and geographicIdentifiers:

• MD_Metadata/identificationInfo/*/descriptiveKeywords/*/keyword

• MD_Metadata/identificationInfo/*/descriptiveKeywords/*/type = "place"

• MD_Metadata/identificationInfo/*/extent/*/geographicElement/*/geographicIdentifier/MD

_Identifier

Example XML encoding of geographic identifier using a WMO station gazetteer:

<gmd:geographicIdentifier>

<gmd:MD_Identifier>

<gmd:authority>

<gmd:CI_Citation id="volAgazeteer">

<gmd:title><gco:CharacterString>Vol A Gazeteer</gco:CharacterString></gmd:title>

…

</gmd:CI_Citation>

</gmd:authority>

<gmd:code>

<gco:CharacterString>http://wis.wmo.int/WMOVolumeAGazeteer.xml#ESSW</gco:CharacterString>

</gmd:code>

</gmd:MD_Identifier>

</gmd:geographicIdentifier>

There are a number of gazetteers managed by WMO and other authorities that are candidates for

reference as geographicIdentifiers:

• ISO 3166 3-numeric country codes

• WMO Code Tables and Flag Tables Associated with BUFR/CREX Table B

o Code table 0 01 003: WMO Region number/geographical area

o Code table 0 01 101: State identifier

• WMO Common Code Table C-11: Originating / generating centres

• WMO Common Code Table C-12: Sub-centres of originating centres defined by entries in

Common Table C-11

• WMO Volume A Observing Station Gazetteer

• ICAO Aerodrome Gazetteer [?]

Note that each station in the Volume A gazetteer shall be assigned a unique identifier to supplement

the (mostly unique) WMO Station Code.

It is anticipated that (at least) a sub-set of these resources will be provided as web-accessible

resources to support future releases of the WMO Core Metadata Profile.

A.9.1.2 gmd:EX_TemporalExtent

This is the date or date range that identifies the currency of the data. It may refer to the period of

collection, or the date at which it is deemed to be current.


This element should not be confused with Dataset reference date which is an identifying date for the

data resource.

Provide a date, or two dates defining the duration of the period, as defined by ISO 8601. Periods are

recorded as (from-date/to-date). Either from-date or to-date (but not both) may be left blank to

indicate uncertainty. The extended date format (YYYY-MM-DD) should be used, where YYYY is the

year, MM is the month and DD is the day. Time (HH:MM:SS, where HH is the hour, MM the minutes

and SS the seconds) may be added if required, separated from the day by “T”.

Examples:

2001-01-01

2009-05-02T09:10:01

1939/1945

/2003-03-31

2000/

19

More information relating to ISO 8601 can be found on Wikipedia:

http://en.wikipedia.org/wiki/ISO_8601.

Within the WMO Core Metadata Profile, the choice has been made to not use combined spatio-

temporal extents (EX_SpatialTemporalExtent). Maintaining the separate extent objects results in

simpler management of the metadata components.

A.9.2.3 Vertical Extents

Currently, the WMO Core Metadata Profile does not provide any guidance on the use of vertical

extents. It is anticipated that this will be added in later releases.

A.9.2.4 Tagging Extent elements for quick identification and indexing

Following best-practice developed at NOAA’s National Geophysical Data Centre (NGDC),

boundingExtent, boundingBoxExtent, boundingTemporalExtent, and boundingVerticalExtent

elements should be tagged using common terms for identification and easy re-use within the

metadata record:

• <gmd:EX_Extent id="boundingExtent">

• <gmd:EX_GeographicBoundingBox id="boundingGeographicBoundingBox">

• <gmd:EX_TemporalExtent id="boundingTemporalExtent">

• <gmd:EX_VerticalExtent id="boundingVerticalExtent">



A.9.2 Identifier information


Maximum occurrence

Data type Domain

88 MD_Identifier value uniquely identifying an object within a namespace

Use obligation/condition

from referencing object

Use maximum

occurrence from

referencing object


89 authority person or party responsible for maintenance of the namespace

O 1 Class CI_Citation «DataType»

90 code alphanumeric value identifying an instance in the namespace


91 RS_Identifier identifier used for reference systems



Use maximum

occurrence from

referencing object

Specialised Class (MD_Identifier)

Lines 92-93

92 codeSpace name or identifier of the person or organization responsible for namespace


93 version version identifier for the namespace



A.9.3 Citation and responsible party information


Maximum occurrence

Data type Domain

94 CI_Citation standardized resource reference Use obligation/condition


Use maximum

occurrence from

referencing object


95 title name by which the cited resource is known


96 alternativeTitle short name or other language name by which the cited information is known. Example: "DCW" as an alternative title for "Digital Chart of the World”


97 date reference date for the cited resource

M N Class CI_Date «DataType»

98 identifier value uniquely identifying an object within a namespace

O N Class MD_Identifier «DataType»

99 citedResponsibleParty name and position information for an individual or organization that is responsible for the resource

O N Class CI_ResponsibleParty «DataType»

100 presentationForm mode in which the resource is represented

O N Class CI_PresentationFormCode «CodeList»

101 CI_ResponsibleParty identification of, and means of communication with, person(s) and organizations associated with the dataset



Use maximum

occurrence from

referencing object


102 individualName name of the responsible personsurname, given name, title separated by a delimiter

C / organisationName and positionName

not documented?


103 organisationName name of the responsible organization

C / individualName and positionName

not



documented?

104 positionName role or position of the responsible person

C / individualName and

organisationName not

documented?


105 contactInfo address of the responsible party O 1 Class CI_Contact «DataType»

106 role function performed by the responsible party

M 1 Class CI_RoleCode «CodeList»

107 CI_Address location of the responsible individual or organization



Use maximum

occurrence from

referencing object


108 deliveryPoint address line for the location (as described in ISO 11180, Annex A)


109 city city of the location O 1 CharacterString Free text

110 administrativeArea state, province of the location O 1 CharacterString Free text

111 postalCode ZIP or other postal code O 1 CharacterString Free text

112 country country of the physical address O 1 CharacterString ISO 3166-3, other parts may be used

113 electronicMailAddress address of the electronic mailbox of the responsible organization or individual


114 CI_Contact information required to enable contact with the responsible person and/or organization



Use maximum

occurrence from

referencing object


115 phone telephone numbers at which the organization or individual may be contacted

O 1 Class CI_Telephone «DataType»

116 address physical and email address at which the organization or individual may be contacted

O 1 Class CI_Address «DataType»

117 onlineResource on-line information that can be used to contact the individual or organization

O 1 Class CI_OnlineResource «DataType»


A.9.3.1 gmd:CI_Citation/gmd:title

The purpose of this element is to provide a readily recognisable name for the data resource.

1. The title should be the formal or product name for the data resource, if existing.

2. If no name exists, then a title should be created that is short, encapsulates the subject, temporal

and spatial coverage of the data resource, and does not contain terms or jargon that make it

incomprehensible.

A.9.3.2 gmd:CI_Citation/gmd:alternativeTitle

The purpose of this element is to record any alternative titles by which the data resource is known.

1. There is no need to fill in this entry unless there are other names used for the dataset, for

example historic names.

2. Commonly used abbreviations or acronyms should be recorded.

3. Other language equivalents should be recorded where they exist, for example the Welsh language

title (although this title may refer to a different data resource).

4. Entries should be short and concise.

A.9.3.3 gmd:CI_ResponsibleParty

This informs the user about who is responsible for the data resource. This class comprises multiple

elements relating to the responsible organisation distributed amongst several discrete «DataTypes»:

1. contact position

2. organisation name

3. full postal address

4. telephone number

5. facsimile number

6. email address

7. web address

8. responsible party role


The responsible party roles are listed below:

Code Name Definition

1 resource provider party that supplies the resource

2 custodian party that accepts accountability and responsibility for the data and ensures appropriate care and maintenance of the resource

3 owner party that owns the resource

4 user party who uses the resource

5 distributor party who distributes the resource

6 originator party who created the resource

7 point of contact party who can be contacted for acquiring knowledge about or acquisition of the resource

8 principal investigator key party responsible for gathering information about or acquisition of the resource

9 processor party who has processed the data in a manner such that the resource has been modified

10 publisher party who published the resource

11 author party who authored the resource

Where there are, say, several distributors, then a separate entry should be given for each.


A.9.4 Date information


Maximum occurrence

Data type Domain

118 CI_Date reference date and event used to describe it



Use maximum

occurrence from

referencing object


119 date M 1 Class Date

120 dateType M 1 Class CI_DateTypeCode «CodeList»

A.9.5 Online resource information


Maximum occurrence

Data type Domain

121 CI_OnlineResource information about on-line sources from which the dataset, specification, or community profile name and extended metadata elements can be obtained



Use maximum

occurrence from

referencing object


122 linkage location (address) for on-line access using a Uniform Resource Locator address or similar addressing scheme such as http://www.statkart.no/isotc211

M 1 Class URL (IETF RFC1738 IETF RFC 2056)

123 protocol connection protocol to be used O 1 CharacterString Free text

124 name name of the online resource O 1 CharacterString Free text

125 description detailed text description of what the online resource is/does



A.9.4.1 gmd:CI_Date

The ISO 19115 element CI_Date requires providing a date type: publication, creation or revision

associated with the date itself. At least one date is required in 19115, with no conditions on the type

of this date.

Provide a date as defined by ISO 8601. The extended date format (YYYY-MM-DD) should be used,

where YYYY is the year, MM is the month and DD is the day. Time (HH:MM:SS, where HH is the hour,

MM the minutes and SS the seconds) may be added if required, separated from the day by “T”.

Examples:

• 2001-01-01

• 2010-11-11T21.09:18

• 19

More information relating to ISO 8601 can be found on Wikipedia:

http://en.wikipedia.org/wiki/ISO_8601.

The date should be completed to a resolution sufficient to identify the version. Thus if the data

resource is updated annually, only a year is required, whilst if it is updated weekly, a day is required.

Metadata authors should identify whether date refers to creation, last revision or publication.

A.9.5.1 gmd:CI_OnlineResource

The purpose of this element is to point to where the dataset may be downloaded. This may be

different from where it may be ordered online, which should be included in the web address of the

distributor.



A.9.6 Telephone information


Maximum occurrence

Data type Domain

126 CI_Telephone telephone numbers for contacting the responsible individual or organization



Use maximum

occurrence from

referencing object

Class «DataType» Line 127

127 voice telephone number by which individuals can speak to the responsible organization or individual

O N CharecterString Free text

A.9.7 Data quality scope information


Maximum occurrence

Data type Domain

128 DQ_Scope extent of characteristic(s) of the data for which quality information is reported


Use maximum

occurrence from

referencing object

Class «DataType»

Line 129

129 level hierarchical level of the data specified by the scope

M 1 Class MD_ScopeCode «CodeList»



Annex B – CodeList extensions


B.5.2 CI_DateTypeCode «CodeList»

Amendment only: additional term «reference» [004]


1. CI_DateTypeCode DateTypCd identification of when a given event occurred

2. creation 001 date identifies when the resource was brought into existence

3. publication 002 date identifies when the resource was used

4. revision 003 date identifies when the resource was examined or re-examined and improved or amended

5. reference 004 date identifies when the resource was referenced or accessed

WMO_DataLicenseCode «CodeList»

New CodeList for WMO Core Metadata Profile.


1. WMO_DataLicenseCode WMO_DatLicCd WMO Data License applied to the data resource – derived from WMO Resolution 25 and Resolution 40 (http://www.wmo.int/pages/about/exchangingdata_en.html)

2. WMO Essential 001 WMO Essential Data: free and unrestricted international exchange of basic meteorological data and products

3. WMO Additional 002 WMO Additional Data: free and unrestricted access to data and products exchanged under the auspices of WMO to the research and education communities for non-commercial activities

WMO_GTSProductCategoryCode «CodeList»



1. WMO_GTS_ProductCategoryCode

WMO_GTSCatCd Product category used for prioritising messages on the WMO Global Telecommunications System (GTS)

2. GTS Category 1 001 GTS Category 1 – highest priority products





WMO_CategoryCode «CodeList»


Name Domain Code

Definition

1. WMO_CategoryCode WMOCatCd Additional topic categories for WMO community

2. weatherObservations 001 weather observations

3. weatherForecasts 002 weather forecasts

4. meteorology 003 Meteorology

5. hydrology 004 Hydrology

6. climatology 005 Climatology

7. landMeteorologyClimate 006 land meteorology climate

8. synopticMeteorology 007 synoptic meteorology

9. marineMeteorology 008 marine meteorology

10. agriculturalMeteorology 009 agricultural meteorology

11. aerology 010 Aerology

12. marineAerology 011 marine aerology

13. oceanography 012 oceanography

14. landHydrology 013 land hydrology

15. rocketSounding 014 rocket sounding

16. pollution 015 pollution

17. waterPollution 016 water pollution

18. landWaterPollution 017 land water pollution

19. seaPollution 018 sea pollution

20. landPollution 019 land pollution

21. airPollution 020 air pollution

22. glaciology 021 Glaciology

23. actinometry 022 actinometry

24. satelliteObservation 023 satellite observation

25. airplaneObservation 024 airplane observation

26. observationPlatform 025 observation platform

It is noted that WMO provides and maintains a number of vocabularies that describe

categories of WMO products and activities:

GRIB Code table 0.0 – Discipline of processed data in the GRIB message

GRIB Code table 4.0 – Product definition

BUFR Table A – Data Category

Common Code Table C-13 – Data sub-categories

International Meteorological Vocabulary (WMO-No. 182)

[http://www.wmo.int/pages/prog/www/WMOCodes/TDCFtables.html].

It is anticipated that these resources will be provided as a web-accessible vocabularies to

support future releases of the WMO Core Metadata Profile and related standards.

As this CodeList provides a significant overlap with these resources, additional maintenance

should be avoided, suggesting the need to reconcile the TDCF Code Tables and

WMO_CategoryCode «CodeList» in future releases of the WMO Core Metadata Profile.



Deprecated CodeList extensions

WMO Core Metadata Profile version 1.1 identified a number of CodeList extensions that

have been deprecated (i.e. no longer in valid use). These are listed below, along with the

reasons for deprecation:

B.5.10 MD_CharacterSetCode «CodeList»


1. MD_CharacterSetCode CharSetCd name of the character coding standard used for the resource

«deprecated»

31. CP1251 030 Cyrillic code set

Advice from the Russian Institute for Hydrometeorological Information indicates that ISO

8859 code is in common use for the Cyrillic alphabet.

B.5.10 MD_MaintenanceFrequncyCode «CodeList»


1. MD_MaintenanceFrequencyCode

MaintFreqCd frequency with which modifications and deletions are made to the data after it is first produced

«deprecated»

14. Hourly 013 data is updated hourly

15. 3-hourly 014 data is updated every 3-hours



Recommendation 29 from IPET-MDI-1 [http://www.wmo.int/pages/prog/www/WDM/IPET-MDI-

I/report/Report_IPETMDI_I_20100503.htm] states:

Use of bespoke extensions to the MD_MaintenanceFrequencyCode code-list will be prohibited. As an

alternative the following must be used:

*/MD_MaintenanceInformation/maintenanceAndUpdateFrequency = “continual”

*/MD_MaintenanceInformation/userDefinedMaintenanceFrequency = «ISO8801-compliant duration»

This applies to both data and metadata maintenance.

Wikipedia provides a useful resource on ISO 8601: http://en.wikipedia.org/wiki/ISO_8601

Additionally, it is noted that WMO provides and maintains a vocabulary of ‘time ranges’ in

GRIB Code table 4.4 – Indicator of unit time range

[http://www.wmo.int/pages/prog/www/WMOCodes/TDCFtables.html].

http://www.wmo.int/pages/prog/www/WDM/IPET-MDI-I/report/Report_IPETMDI_I_20100503.htm

http://www.wmo.int/pages/prog/www/WDM/IPET-MDI-I/report/Report_IPETMDI_I_20100503.htm




It is anticipated that this will be provided as a web-accessible vocabulary to support future

releases of the WMO Core Metadata Profile and related standards.

B.5.18 MD_SpatialRepresentationTypeCode «CodeList»


1. MD_SpatialRepresentationTypeCode

SpatRepTypCd method used to represent geographic information in the dataset

«deprecated»

8. bitmap 007

9. irregularPoints 008 irregularly-spaced points, such as meteorological stations

Review of common usage of these CodeList entries indicates a mapping to common

parlance used in GIS systems. Given that understanding:

«bitmap» [007] shall be described using «grid» [002]; and

«irregularPoints» [008] shall be described using «vector» [001]

WMO_DataFrequencyCode «CodeList»


1. WMO_DataFrequencyCode

WMODataFreqCd Supplemental CodeList to MD_MaintenanceFrequencyCode reflecting WMO timescales

«deprecated»

2. continuous 001 data is observed, measured or forecasted continuously

3. 1-minute 002 data is observed, measured or forecasted every minute

4. 5-minute 003 data is observed, measured or forecasted every 5 minutes



7. Hourly 006 data is observed, measured or forecasted every hour

8. 3-hourly 007 data is observed, measured or forecasted every 3 hours




12. daily 011 data is observed, measured or forecasted every day

13. weekly 012 data is observed, measured or forecasted every week

14. 10-daily 013 data is observed, measured or forecasted every 10 days

15. fortnightly 014 data is observed, measured or forecasted every 2 weeks

16. monthly 015 data is observed, measured or forecasted every month

17. quarterly 016 data is observed, measured or forecasted every 3 months

18. biannually 017 data is observed, measured or forecasted twice each year

19. annually 018 data is observed, measured or forecasted every year

20. decadally 019 data is observed, measured or forecasted every decade

21. Irregularly 020 data is observed, measured or forecasted irregularly

WMO provides and maintains a vocabulary of ‘time ranges’ in GRIB Code table 4.4 –

Indicator of unit time range [http://www.wmo.int/pages/prog/www/WMOCodes/TDCFtables.html]. As



this CodeList provides a significant overlap with this resource, additional maintenance shall

be avoided. The TDCF Code Tables will take priority.

It is anticipated that GRIB Code table 4.4 – Indicator of unit time range will be provided as a

web-accessible vocabulary to support future releases of the WMO Core Metadata Profile

and related standards.

Where durations are not covered by GRIB Code table 4.4 – Indicator of unit time range, an

ISO 8601-compliant duration should be used. Wikipedia provides a useful resource on this

subject: http://en.wikipedia.org/wiki/ISO_8601.


WM

Annex

O Core

x C – ISO

e Metad

O 19115 M

data Pr

Metadat

rofile v

ta model

version

s

1.2

ISO 19115:2003 Geographic Information – Metadata

Annex A (normative) Metadata Schemas

Copyright

Since this information reproduces parts of the ISO 191xxx series of standards in the WMO

profile, Copyright remains with ISO.

Please note that this content is subject to minor amendments as described in Technical

Corrigendum ISO 19115:2003/Cor. 1:2006. Please refer to ISO 19115:2003/Cor. 1:2006

Annex A for details. (Reproduced as Annex E to this document)

ISO 19115:2003(E)

18 © ISO 2003 — All rights reserved

Annex A (normative)

Metadata schemas

A.1 Metadata UML models

Metadata for describing geographic data is defined using an abstract object model in the Unified Modelling Language (UML). The diagrams in the following subclauses provide “views,” which are portions of the total abstract model for metadata. Each diagram defines a metadata section (UML package) of related entities, elements, data types, and code lists. Related entities, which are defined in another diagram, are shown with elements suppressed and the defining package specified under the entity name in parenthesis. Throughout the following models, entities may have mandatory and/or optional elements and associations. In some cases, optional entities may have mandatory elements; those elements become mandatory only if the optional element is used.

ISO 19115:2003(E)

© ISO 2003 — All rights reserved 19

A.2 Metadata package UML diagrams

A.2.1 Metadata entity set information

Figure A.1 defines the class “MD_Metadata” and shows containment relationships with the other metadata classes which, in aggregate, define metadata for geographic data. The other metadata class diagrams can be found on the following pages. The data dictionary for this diagram is located in B.2.1.

Conditional statements:language: documented if not defined by the encodingstandardcharacterSet: documented if ISO 10646-1 not used andnot defined by the encoding standard

<<Abstract>>MD_SpatialRepresentation

(from Spatial representation information)

MD_ApplicationSchemaInformation(from Application schema information)

MD_PortrayalCatalogueReference(from Portrayal catalogue information)

MD_MetadataExtensionInformation(from Metadata extension information)

<<Abstract>>MD_ContentInformation(from Content information)

MD_ReferenceSystem(from Reference system information)

DQ_DataQuality(from Data quality information)

MD_Distribution(from Distribution information)

MD_MaintenanceInformation(from Maintenance information)

MD_Metadata+ fileIdentifier [0..1] : CharacterString+ language [0..1] : CharacterString+ characterSet [0..1] : MD_CharacterSetCode = "utf8"+ parentIdentifier [0..1] : CharacterString+ hierarchyLevel [0..*] : MD_ScopeCode = "dataset"+ hierarchyLevelName [0..*] : CharacterString+ contact [1..*] : CI_ResponsibleParty+ dateStamp : Date+ metadataStandardName [0..1] : CharacterString+ metadataStandardVersion [0..1] : CharacterString+ dataSetURI [0..1] : CharacterString

+spatialRepresentationInfo

+applicationSchemaInfo

+portrayalCatalogueInfo

+metadataMaintenance

+metadataExtensionInfo

+contentInfo

+referenceSystemInfo

+dataQualityInfo

+distributionInfo

MD_Constraints(from Constraint information)

+metadataConstraints

<<Abstract>>MD_Identification

(from Identification information)

+resourceMaintenance

+identificationInfo

+resourceConstraints

0..* 0..*

0..*

0..1 0..*

0..*

0..1

0..*

1..*

0..*

0..*0..*

0..*

hierarchyLevel: documented if hierarchyLevel not = "dataset" hierarchyLevelName: documented if hierarchyLevel not = "dataset"

Figure A.1 — Metadata entity set information

A.2.2 Identification information

Figure A.2 defines the metadata classes required to identify a resource. It also defines separate specialization sub-classes for identifying data and services. The data dictionary for this diagram is located in B.2.2.

ISO 19115:2003(E)


MD_Usage+ specificUsage : CharacterString+ usageDateTime [0..1] : DateTime+ userDeterminedLimitations [0..1] : CharacterString+ userContactInfo [1..*] : CI_ResponsibleParty

MD_Metadata(from Metadata entity set information) MD_Constraints

(from Constraint information)

MD_BrowseGraphic+ fileName : CharacterString+ fileDescription [0..1] : CharacterString+ fileType [0..1] : CharacterString


+ citation : CI_Citation+ abstract : CharacterString+ purpose [0..1] : CharacterString+ credit [0..*] : CharacterString+ status [0..*] : MD_ProgressCode+ poinOfContact [0..*] : CI_ResponsiblePartyMD_Format

(from Distribution information)

<<CodeList>>MD_KeywordTypeCode+ dicipline+ place+ stratum+ temporal+ theme

MD_Metadata.hierarchyLevel = "dataset" implies count(extent.geographicElement.EX_GeographicBoundingBox) + count(extent.geographicElement.EX_GeographicDescription) >=1

MD_DataIdentification+ spatialRepresentationType [0..*] : MD_SpatialRepresentationTypeCode+ spatialResolution [0..*] : MD_Resolution+ language [1..*] : CharacterString+ characterSet [0..*] : MD_CharacterSetCode = "utf8"+ topicCategory [0..*] : MD_TopicCategoryCode+ environmentDescription [0..1] : CharacterString+ extent [0..*] : EX_Extent+ supplementalInformation [0..1] : CharacterString

<<Union>>MD_Resolution

+ equivalentScale : MD_RepresentativeFraction+ distance : Distance

<<CodeList>>MD_InitiativeTypeCode

+ campaign+ collection+ exercise+ experiment+ investigation+ mission+ sensor+ operation+ platform+ process+ program+ project+ study+ task+ trial

<<CodeList>>DS_AssociationTypeCode+ crossReference+ largerWorkCitation+ partOfSeamlessDatabase+ source+ stereoMate

<<Enumeration>>MD_TopicCategoryCode

+ farming+ biota+ boundaries+ climatologyMeteorologyAtmosphere+ economy+ elevation+ environment+ geoscientificInformation+ health+ imageryBaseMapsEarthCover+ intelligenceMilitary+ inlandWaters+ location+ oceans+ planningCadastre+ society+ structure+ transportation+ utilitiesCommunication

<<CodeList>>MD_SpatialRepresentationTypeCode+ vector+ grid+ textTable+ tin+ stereoModel+ video

<<CodeList>>MD_CharacterSetCode+ ucs2+ ucs4+ utf7+ utf8+ utf16+ 8859part1+ 8859part2+ 8859part3+ 8859part4+ 8859part5+ 8859part6+ 8859part7+ 8859part8+ 8859part9+ 8859part10+ 8859part11+ (reserved for future use)+ 8859part13+ 8859part14+ 8859part15+ 8859part16+ jis+ shiftJIS+ eucJP+ usAscii+ ebcdic+ eucKR+ big5+ GB2312

Either"aggregateDataSetName" or"aggregateDataSetIdentifier"must be documented

<<DataType>>MD_AggregateInformation

+ aggregateDataSetName [0..1] : CI_Citation+ aggregateDataSetIdentifier [0..1] : MD_Identifier+ associationType : DS_AssociationTypeCode+ initiativeType [0..1] : DS_InitiativeTypeCode

MD_Keywords+ keyword [1..*] : CharacterString+ type [0..1] : MD_KeywordTypeCode+ thesaurusName [0..1] : CI_Citation

MD_MaintenanceInformation(from Maintenance information)

MD_ServiceIdentification

<<CodeList>>MD_ProgressCode

+ completed+ historicalArchive+ obsolete+ onGoing+ planned+ required+ underDevelopment

<<DataType>>MD_RepresentativeFraction

+ denominator : Integer

+resourceSpecificUsage

0..* +identificationInfo1..*

+graphicOverview

0..*

0..*+resourceFormat

0..*

0..*

0..*

0..* +resourceMaintenance

aggregationInfo

+descriptiveKeywords

+resourceConstraints

characterSet: documented if ISO 10646-1 is not used

MD_Metadata.hierarchyLevel notEqual "dataset" implies topicCategory is not mandatory

Figure A.2 — Identification information

ISO 19115:2003(E)


A.2.3 Constraint information

Figure A.3 defines the metadata required for managing rights to information including restrictions on access and use. The data dictionary for this diagram is located in B.2.3.


(from Identification information)

MD_Metadata(from Metadata entity set information)

MD_Constraints

+resourceConstraints 0..*

+ useLimitation [0..*] : CharacterString

+ unclassified+ restricted+ confidential+ secret+ topSecret

<<CodeList>>MD_ClassificationCode

+metadataConstraints0..*

MD_LegalConstraints+ accessConstraints [0..*] : MD_RestrictionCode+ useConstraints [0..*] : MD_RestrictionCode+ otherConstraints [0..*] : CharacterString

MD_SecurityConstraints+ classification : MD_ClassificationCode+ userNote [0..1] : CharacterString + classificationSystem [0..1] : CharacterString+ handlingDescription [0..1] : CharacterString

+ copyright+ patent+ patentPending+ trademark+ license+ intellectualPropertyRights+ restricted+ otherRestrictions

<<CodeList>>MD_RestrictionCode

otherConstraints: documented if accessConstraints oruseConstraints = "otherRestrictions"

Figure A.3 — Constraint information

ISO 19115:2003(E)


A.2.4 Data quality information

A.2.4.1 General

Figure A.4 defines the metadata required to give a general assessment of the quality of a resource. The data dictionary for this diagram is located in B.2.4.


DQ_DataQuality

+dataQualityInfo

0..*

+ scope : DQ_Scope

+ directInternal+ directExternal+ indirect

<<CodeList>>MD_EvaluationMethodTypeCode

+report0..*

<<Abstract>>DQ_Element

+ nameOfMeasure [0..*] : CharacterString+ measureIdentification [0..1] : MD_Identifier+ measureDescription [0..1] : CharacterString+ evaluationMethodType [0..1] : DQ_EvaluationMethodTypeCode+ evaluationMethodDescription [0..1] : CharacterString+ evaluationProcedure [0..1] : CI_Citation+ dateTime [0..*] : DateTime+ result [1..2] : DQ_Result

DQ_QuantitativeResult+ valueType [0..1] : RecordType+ valueUnit : UnitOfMeasure+ errorStatistic [0..1] : CharacterString+ value [1..*] : Record

"report" or "linage" role is mandatory ifscope.DQ_Scope.level = 'dataset'

LI_Linage

+linage0..1+ level : MD_ScopeCode+ extent [0..1] : EX_Extent+ levelDescription [0..*] : MD_ScopeDescription

<<DataType>>DQ_Scope

DQ_ConformanceResult+ specification : CI_Citation+ explanation : CharacterString+ pass : Boolean

<<Abstract>>DQ_Result

"levelDescription" ismandatoryif "level"notEqual 'dataset'or 'series'

Figure A.4 — Data quality information

ISO 19115:2003(E)


A.2.4.2 Lineage information

Figure A.5 defines metadata required to describe the sources and production processes used in producing a dataset. The data dictionary for this diagram is located in B.2.4.2.

LI_Lineage

+linage

0..1

+ statement [0..1] : CharacterString

+source 0..*

LI_Source

+ description [0..1] : CharacterString+ scaleDenominator [0..1] : MD_RepresentativeFraction+ sourceReferenceSystem [0..1] : MD_ReferenceSystem+ sourceCitation [0..1] : CI_Citation+ sourceExtent [0..*] : EX_Extent

LI_ProcessStep+ description : CharacterString+ rationale [0..1] : CharacterString+ dateTime [0..1] : DateTime+ processor [0..*] : CI_ResponsibleParty

DQ_DataQuality+ scope : DQ_Scope

If(count(source) + count(processStep) =0) and(DQ_DataQuality.cope.level = 'dataset' or 'series') thenstatement is mandatory

"source" role is mandatory ifLI_Lineage.statement and "processStep"role are not documented

"processStep" role is mandatory ifLI_Lineage.statement and "source" role arenot documented

"description" is mandatory if "soruceExtent" is notdocumented

"sourceExtent" is mandatory if "description" is not documented

+source0..*

0..*+sourceStep

0..*

+processStep

Figure A.5 — Lineage information

ISO 19115:2003(E)


A.2.4.3 Data quality classes and subclasses

Figure A.6 defines the classes and subclasses of data quality used in the data quality diagram. The data dictionary for this diagram is located in B.2.4.3.

+lineage

0..1

0..*

DQ_DataQuality+ scope : DQ_Scope

+reportLI_Lineage

<<Abstract>>DQ_Element

<<Abstract>>DQ_Completeness

<<Abstract>>DQ_LogicalConsistency

<<Abstract>>DQ_PositionalAccuracy

DQ_CompletenessCommission

DQ_CompletenessOmission

DQ_AbsoluteExternalPositionalAccuracyDQ_ConceptualConsistency

DQ_DomainConsistency

DQ_FormatConsistency

DQ_TopologicalConsistency

DQ_GriddedDataPositionalAccuracy

DQ_RelativeInternalPositionalAccuracy

<<Abstract>>DQ_ThematicAccuracy

<<Abstract>>DQ_TemporalAccuracy

DQ_ThematicClassificationCorrectness

DQ_NonQuantitativeAttributeAccuracy

DQ_QuantitativeAttributeAccuracy DQ_TemporalValidity

DQ_TemporalConsistency

DQ_AccuracyOfATimeMeasurement

Figure A.6 — Data quality classes and subclasses

ISO 19115:2003(E)


A.2.5 Maintenance information

Figure A.7 defines the metadata required to describe the maintenance and update practices for information. The data dictionary for this diagram is located in B.2.5.


MD_MaintenanceInformation+ maintenanceAndUpdateFrequency : MD_MaintenanceFrequencyCode+ dateOfNextUpdate [0..1] : Date+ userDefinedMaintenanceFrequency [0..1] : TM_PeriodDuration+ updateScope [0..*] : MD_ScopeCode+ updateScopeDescription [0..*] : MD_ScopeDescription+ maintenanceNote [0..*] : CharacterString+ contact [0..*] : CI_ResponsibleParty

+metadataMaintenance

0..1

+ attribute+ attributeType+ collectionHardware+ collectionSession+ dataset+ series+ nonGeographicDataset+ dimensionGroup+ feature+ featureType+ propertyType+ fieldSession+ software+ service+ model+ tile

<<CodeList>>MD_ScopeCode

+ attributes : Set<GF_AttributeType>+ features : Set<GF_FeatureType>+ featureInstances : Set<GF_FeatureType>+ attributeInstances : Set<GF_AttributeType>+ dataset : CharacterString+ other : CharacterString

<<Union>>MD_ScopeDescription+ continual

+ daily+ weekly+ forthnightly+ monthly+ quarterly+ biannually+ annually+ asNeeded+ irregular+ notPlanned+ unknown

<<CodeList>>MD_MaintenanceFrequencyCode

Figure A.7 — Maintenance information

ISO 19115:2003(E)


A.2.6 Spatial representation information

Figure A.8 defines metadata required to describe the mechanism used to represent spatial information. The data dictionary for this diagram is located in B.2.6.


MD_GridSpatialRepresentation

+spatialRepresentationInfo 0..*

<<Abstract>>MD_SpatialRepresentation

+ numberOfDimensions : Integer+ axisDimensionProperties : Sequence<MD_Dimension>+ cellGeometry : MD_CellGeometryCode+ transformationParameterAvailability : Boolean

MD_VectorSpatialRepresentation+ topologyLevel [0..1] : MD_TopologyLevelCode + geometricObjects [0..*] : MD_GeometricObjects

MD_Georeferenceable+ controlPointAvailability: Boolean+ orientationParameterAvailability : Boolean+ orientationParameterDescription [0..1] : CharacterString+ georeferencedParameters : Record+ parameterCitation [0..*] : CI_Citation

MD_Georectified+ checkPointAvailability: Boolean+ checkPointDescription [0..1] : CharacterString+ cornerPoints : Sequence<GM_Point>+ centerPoint [0..1] : GM_Point+ pointInPixel : MD_PixelOrientationCode+ transformationDimensionDescription [0..1] : CharacterString+ transformationDimensionMapping [0..2] : CharacterString

"checkPointDescription" is mandatory if"checkPointAvaliability" = 1

<<DataType>>MD_Dimension

+ dimensionName : MD_DimensionNameTypeCode+ dimensionSize : Integer+ resolution [0..1] : Measure

<<CodeList>>MD_GeometricObjectTypeCode+ complex+ composite+ curve+ point+ solid+ surface

<<CodeList>>MD_DimensionTypeCode+ row+ column+ vertical+ track+ crossTrack+ line+ sample+ time

<<DataType>>MD_GeometricObjects

+ geometricObjectType : MD_GeometricObjectTypeCode+ geometricObjectCount [0..1] : Integer

<<CodeList>>MD_CellGeometryCode+ point+ area

<<CodeList>>MD_TopologyLevelCode

+ geometryOnly+ topology1D+ planarGraph+ fullPlanarGraph+ surfaceGraph+ fullSurfaceGraph+ topology3D+ fullTopology3D+ abstract

<<Enumeration>>MD_PixelOrientationCode+ center+ lowerLeft+ lowerRight+ upperRight+ upperLeft

Figure A.8 — Spatial representation information

ISO 19115:2003(E)


A.2.7 Reference system information

Figure A.9 defines metadata required to describe the spatial and temporal reference system used. The data dictionary for this diagram is located in B.2.7.


MD_ReferenceSystem

+referenceSystemInfo

0..*

+ referenceSystemIdentifier [0..1] : RS:Identifier

RS_Identifier+ codeSpace [0..1] : CharacterString+ version [0..1] : CharacterString

"referenceSystemIdentifier" ismandatory ifMD_CRS.projection,MD_CRS.ellipsoid andMD_CRS.datum are notdocumented

<<DataType>>MD_Identifier

+ authority [0..1] : CI_Citation+ code : CharacterString

MD_CRS+ projection [0..1] : RS_Identifier+ ellipsoid [0..1] : RS_Identifier+ datum [0..1] : RS_Identifier

<<Abstract>>RS_ReferenceSystem

+ name : RS_Identifier+ domainOfValidity [0..*] : EX_Extent

MD_EllipsoidParameters+ semiMajorAxis : Real+ axisUnits : UomLength+ denominatorOfFlatteningRatio [0..1] : Real

"denominatorOfFlatteningRatio" ismandatory if not a spheroid

MD_ObliqueLineAzimuth+ azimuthAngle : Real+ azimuthMeasurePointLongitude : Real

MD_ObliqueLinePoint+ azimuthLineLatitude : Real+ azimuthLIneLongitude : Real

MD_ProjectionParameters+ zone [0..1] : Integer+ standardParallel [0..2] : Real+ longitudeOfCentralMeridian [0..1] : Real+ latitudeOfProjectionOrigin [0..1] : Real+ falseEasting [0..1] : Real+ falseNorthing [0..1] : Real+ falseEastingNorthingUnits [0..1] : UomLength+ scaleFactorAtEquator [0..1] : Real+ heightOfProspectivePointAboveSurface [0..1] : Real+ longitudeOfProjectionCenter [0..1] : Real+ latitudeOfProjectionCenter [0..1] : Real+ scaleFactorAtCenterLine [0..1] : Real+ straightVerticalLongitudeFromPole [0..1] : Real+ scaleFactorAtProjectionOrigin [0..1] : Real

+obliqueLinePointParameter 0,2

+obliqueLineAzimuthParameter0..1

0..1

+projectionParameters0..1

+ellipsoidParameters

Figure A.9 — Reference system information

ISO 19115:2003(E)


A.2.8 Content information

Figure A.10 defines metadata about the content of a coverage and the feature catalogue(s) used to define features. The data dictionary for this diagram is located in B.2.8.


MD_CoverageDescription

+contentInfo

0..*

<<Abstract>>MD_ContentInformation

+ attributeDescription : RecordType+ contentType : MD_CoverageContentTypeCode

MD_FeatureCatalogueDescription+ complianceCode [0..1] : Boolean+ language [0..*] : CharacterString+ includeWithDataset : Boolean+ featureTypes [0..*] : GenericName+ featureCatalogueCitation [1..*] : CI_Citation

MD_ImageDescription+ illuminationElevationAngel [0..1] : Real+ illuminationAzimuthAngel [0..1] : Real+ imagingCondition [0..1] : MD_ImagingConditionCode+ imageQualityCode [0..1] : MD_Identifier+ cloudCoverPercentage [0..1] : Real+ processingLevelCode [0..1] : MD_Identifer+ compressionGenerationQuantity [0..1] : Integer+ triangulationIndicator [0..1] : Boolean+ radiometricCalibrationDataAvailability [0..1] : Boolean+ cameraCalibrationInformationAvailability [0..1] : Boolean+ filmDistortionInformationAvailability [0..1] : Boolean+ lensDistortionInformationAvailability [0..1] : Boolean

"units" is mandatory if "maxValue" or"minValue" are provided

<<CodeList>>MD_CoverageContentTypeCode+ image+ thematicClassification+ physicalMeasurement

MD_RangeDimension+ sequenceIdentifier [0..1] : MemberName+ descriptor [0..1] : CharacterString

<<CodeList>>MD_ImagingConditionCode+ blurredImage+ cloud+ degradingObliquity+ fog+ heavySmokeOrDust+ night+ rain+ seminDarkness+ shadow+ snow+ terrainMasking

MD_Band+ maxValue [0..1] : Real+ minValue [0..1] : Real+ units [0..1] : UomLength+ peakResponse [0..1] : Real+ bitsPerValue [0..1] : Integer+ toneGradation [0..1] : Integer+ scaleFactor [0..1] : Real+ offset [0..1] : Real

+dimension0..*

Figure A.10 — Content information

ISO 19115:2003(E)


A.2.9 Portrayal catalogue information

Figure A.11 defines metadata about the portrayal catalogue(s) used to display data. The data dictionary for this diagram is located in B.2.9.


MD_PortrayalCatalogueReference

+ portrayalCatalogueCitation [1..*] : CI_Citation

0..*+portrayalCatalogueInfo

Figure A.11 — Portrayal catalogue information

ISO 19115:2003(E)


A.2.10 Distribution information

Figure A.12 defines metadata required for accessing a resource. The data dictionary for this diagram is located in B.2.10.


MD_DigitalTransferOptions

+distributionInfo 0..1

MD_Distribution

+ unitsOfDistribution [0..1] : CharacterString+ transferSize [0..1] : Real+ onLine [0..*] : CI_OnlineResource+ offLine [0..1] : MD_Medium

MD_Format+ name : CharacterString+ version : CharacterString+ amendmentNumber [0..1] : CharacterString+ specification [0..1] : CharacterString+ fileDecompressionTechnique [0..1] : CharacterString

"densityUnits" is mandatory if "density" is provided

<<DataType>>MD_Medium

+transferOptions0..*

count (distributionFormat +distributorFormat) > 0

+distributionFormat

0..*

<<CodeList>>MD_MediumFormatCode

+ cpio+ tar+ highSierra+ iso9660+ iso9660RockRidge+ iso9660AppleHFS

<<CodeList>>MD_MediumNameCode

+ cdRom+ dvd+ dvdRom+ 3halfInchFloppy+ 5quarterInchFloppy+ 7trackTape+ 9trackTape+ 3480Cartridge+ 3490Cartridge+ 3580Cartridge+ 4mmCartridgeTape+ 8mmCartridgeTape+ 1quarterInchCartridgeTape+ digitalLinearTape+ onLine+ satellite+ telephoneLink+ hardcopy

MD_Distributor+ distributorContact : CI_ResponsibleParty

+ name [0..1] : MD_MediumNameCode+ density [0..*] : Real+ densityUnits [0..1] : CharacterString+ volumes [0..1] : Integer+ mediumFormat [0..*] : MD_MediumFormatCode+ mediumName [0..1] : CharacterString

MD_StandardOrderProcess+ fees [0..1] : CharacterString+ plannedAvailableDateTime [0..1] : DateTime+ orderingInstructions [0..1] : CharacterString+ turnaround [0..1] : CharacterString

+distributorFormat0..*

0..*+FormatDistributor

+distributor0..*

+distributorTransferOptions

0..*

+distributionOrderProcess0..*

Figure A.12 — Distribution information

ISO 19115:2003(E)


A.2.11 Metadata extension information

Figure A.13 defines the extended metadata elements. The data dictionary for this diagram is located in B.2.11.


MD_ExtendedElementInformation+ name : CharacterString+ shortName [0..1] : CharacterString+ domainCode [0..1] : Integer+ definition : CharacterString+ obligation [0..1] : MD_ObligationCode+ condition [0..1] : CharacterString+ dataType : MD_DatatypeCode+ maximumOccurence [0..1] : CharacterString+ domainValue [0..1] : CharacterString+ parentEntity [1..*] : CharacterString+ rule : CharacterString+ rationale [0..*] : CharacterString+ source [1..*] : CI_ResponsibleParty

if "dataType" = 'codelistElement' then "domainCode" is mandatory

0..*

+metadataExtentionInfo0..*

<<Enumeration>>MD_ObligationCode

+ mandatory+ optional+ conditional

<<CodeList>>MD_DatatypeCode

+ class+ codelist+ enumeration+ codelistElement+ abstractClass+ aggregateClass+ specifiedClass+ datatypeClass+ interfaceClass+ unionClass+ metaClass+ typeClass+ characterString+ integer+ association

MD_MetadataExtensionInformation+ extensionOnLineResource [0..1] : CI_OnlineResource

+extendedElementInformation

if "dataType" notEqual 'codelistElement' then "shortName" is mandatory

if "dataType" notEqual 'codelist', 'enumeration' or 'codelistElement' then "obligation","maximumOccurence" and "domainValue" are mandatory

if "obligation" = 'conditional' then "condition" is mandatory

Figure A.13 — Metadata extension information

ISO 19115:2003(E)


A.2.12 Application schema information

Figure A.14 defines the application schema used. The data dictionary for this diagram is located in B.2.12.


+applicationSchemaInfo 0..*

MD_ApplicationSchemaInformation+ name : CI_Citation+ schemaLanguage : CharacterString+ constraintLanguage : CharacterString+ schemaAscii [0..1] : CharacterString+ graphicsFile [0..1] : Binary+ softwareDevelopmentFile [0..1] : Binary+ softwareDevelopmentFileFormat [0..1] : CharacterString

Figure A.14 — Application schema information

ISO 19115:2003(E)


A.3 Metadata data types

A.3.1 Extent information

Figure A.15 defines metadata describing the spatial and temporal extent covered by a resource. The data dictionary for this diagram is located in B.3.1.

SC_VerticalDatum(from Spatial Referencing by Coordinates)

EX_GeographicBoundingBoxEX_SpatialTemporalExtent+ westBoundLongitude : Angle

+ eastBoundLongitude : Angle+ southBoundLatitude : Angle+ northBoundLatitude : Angle

<<Abstract>>EX_GeographicExtent +temporalElement

0..*

EX_TemporalExtent+ extent : TM_Primitive

+ extentTypeCode [0..1] : Boolean = "1"

EX_VerticalExtent+ minimumValue : Real+ maximumValue : Real+ unitOfMeasure : UomLength

0..*

<<DataType>>EX_Extent

+ description [0..1] : CharacterString

count(description +geographicElement +temporalElement +verticalElement) > 0

+geographicElement

+spatialExtent1..*

1+verticalDatum

EX_GeographicDescription+ geographicIdentifier : MD_Identifier

EX_BoundingPolygon+ polygon [1..*] : GM_Object

+verticalElement

0..*

Figure A.15 — Extent information

ISO 19115:2003(E)


A.3.2 Citation and responsible party information

Figure A.16 defines metadata describing authoritative reference information, including responsible party and contact information. The data dictionary for this diagram is located in B.3.2.

<<CodeList>>CI_PresentationFormCode+ documentDigital+ documentHardcopy+ imageDigital+ imageHardcopy+ mapDigial+ mapHardcopy+ modelDigital+ modelHardcopy+ profileDigital+ profileHardcopy+ tableDigital+ tableHardcopy+ videoDigital+ videoHardcopy

<<DataType>>CI_Citation

+ title : CharacterString+ alternateTitle [0..*] : CharacterString+ date [1..*] : CI_Date+ edition [0..1] : CharacterString+ editionDate [0..1] : Date+ identifier [0..*] : MD_Identifier+ citedResponsibleParty [0..*] : CI_ResponsibleParty+ presentationForm [0..*] : CI_PresentationFormCode+ series [0..1] : CI_Series+ otherCitationDetails [0..1] : CharacterString+ collectiveTitle [0..1] : CharacterString+ ISBN [0..1] : CharacterString+ ISSN [0..1] : CharacterString

<<DataType>>CI_ResponsibleParty

+ individualName [0..1] : CharacterString+ organisationName [0..1] : CharacterString+ positionName [0..1] : CharacterString+ contactInfo [0..1] : CI_Contact+ role : CI_RoleCode

count of (individualName +organisationName +positionName) > 0

<<DataType>>CI_Contact

+ phone [0..1] : CI_Telephone+ address [0..1] : Address+ onlineResource [0..1] : CI_OnlineResource+ hoursOfService [0..1] : CharacterString+ contactInstructions [0..1] : CharacterString

<<DataType>>CI_OnlineResource

+ linkage : URL+ protocol [0..1] : CharacterString+ applicationProfile [0..1] : CharacterString+ name [0..1] : CharacterString+ description [0..1] : CharacterString+ function [0..1] : CI_OnLineFunctionCode

<<DataType>>CI_Address

+ deliveryPoint [0..*] : CharacterString+ city [0..1] : CharacterString+ adminitrativeArea [0..1] : CharacterString+ postalCode [0..1] : CharacterString+ country [0..1] : CharacterString+ electronicMailAddress [0..*] : CharacterString

<<CodeList>>CI_RoleCode

+ resourceProvider+ custodian+ owner+ user+ distributor+ originator+ pointOfContact+ principalInvestigator+ processor+ publisher+ author

<<DataType>>CI_Telephone

+ voice [0..*] : CharacterString+ facsimile [0..*] : CharacterString

<<CodeList>>CI_OnLineFunctionCode+ download+ information+ offlineAccess+ order+ search

<<CodeList>>CI_DateTypeCode+ creation+ publication+ revision

<<DataType>>CI_Date

+ date : Date+ dateType : CI_DateTypeCode

URL

<<DataType>>CI_Series

+ name [0..1] : CharacterString+ issueIdentification [0..1] : CharacterString+ page [0..1] : CharacterString

Figure A.16 — Citation and responsible party information

WM

Annex

Copyrig

Since th

profile,

O Core

x D – ISO

ght

his informat

Copyright r

e Metad

O 19115 C

tion reprodu

remains wit

data Pr

CodeList

uces parts o

th ISO.

rofile v

ts and En

of the ISO 19

version

numerati

91xxx series

1.2

ions

s of standarrds in the W

WMO

ISO 19115:2003 Geographic Information – Metadata Annex B (normative) Data dictionary for geographic metadata

B.5 CodeLists and enumerations

B.5.1 Introduction

The stereotype classes «CodeList» and «Enumeration» can be found below. These two

stereotype classes do not contain “obligation / condition”, “maximum occurrence”, “data

type” and “domain” attributes. The two stereotype classes also do not contain any “other”

values as «Enumeration»s are closed (not extendable) and «CodeList»s are extendable.

Note the additional element for CodeList B.5.2 CI_DateTypeCode «CodeList» to support the

WMO Core Metadata Profile:


1. CI_DateTypeCode DateTypCd identification of when a given event occurred

5. reference 004 date identifies when the resource was referenced or accessed

Online resources describing ISO 19115 and ISO 19115‐2 CodeLists can be found at the

National Geophysical Data Centre GEO‐IDE Guidelines and Best Practices Wiki:

https://nosc.ngdc.noaa.gov/dmc/swg/wiki/index.php?title=ISO_19115_and_19115‐2_CodeList_Dictionaries

3

ISO 19115 code lists and enumeration including proposed extensions

B.5.2 CI_DateTypeCode <<CodeList>>

Name Domain code Definition 1. CI_DateTypeCode DateTypCd identification of when a given event occurred 2. creation 001 date identifies when the resource was brought into existence 3. publication 002 date identifies when the resource was issued 4. revision 003 date identifies when the resource was examined or reexamined and

improved or amended Additional entries 5. reference 004 date identifies when the resource was referenced or accessed

B.5.3 CI_OnLineFunctionCode <<CodeList>>

Name Domain code Definition 1. CI_OnLineFunction

Code OnFunctCd function performed by the resource

2. download 001 online instructions for transferring data from one storage device or system to another

3. information 002 online information about the resource 4. offlineAccess 003 online instructions for requesting the resource from the provider 5. order 004 online order process for obtaining the resource 6. search 005 online search interface for seeking out information about the resource

B.5.4 CI_PresentationFormCode <<CodeList>>

Name Domain code Definition 1. CI_PresentationFor

mCode PresFormCd mode in which the data is represented

2. documentDigital 001 digital representation of a primarily textual item (can contain illustrations also)

3. documentHardcopy 002 representation of a primarily textual item (can contain illustrations also) on paper, photographic material, or other media

4. imageDigital 003 likeness of natural or manmade features, objects, and activities acquired through the sensing of visual or any other segment of the electromagnetic spectrum by sensors, such as thermal infrared, and high resolution radar and stored in digital format

5. imageHardcopy 004 likeness of natural or manmade features, objects, and activities acquired through the sensing of visual or any other segment of the electromagnetic spectrum by sensors, such as thermal infrared, and high resolution radar and reproduced on paper, photographic material, or other media for use directly by the human user

6. mapDigital 005 map represented in raster or vector form 7. mapHardcopy 006 map printed on paper, photographic material, or other media for use

directly by the human user 8. modelDigital 007 multidimensional digital representation of a feature, process, etc. 9. modelHardcopy 008 3dimensional, physical model 10. profileDigital 009 vertical crosssection in digital form 11. profileHardcopy 010 vertical crosssection printed on paper, etc. 12. tableDigital 011 digital representation of facts or figures systematically displayed,

especially in columns 13. tableHardcopy 012 representation of facts or figures systematically displayed, especially in

columns, printed on paper, photographic material, or other media 14. videoDigital 013 digital video recording 15. videoHardcopy 014 video recording on film

4

B.5.5 CI_RoleCode <<CodeList>>

Name Domain code Definition 1. CI_RoleCode RoleCd function performed by the responsible party 2. resourceProvider 001 party that supplies the resource 3. custodian 002 party that accepts accountability and responsibility for the data and

ensures appropriate care and maintenance of the resource 4. owner 003 party that owns the resource 5. user 004 party who uses the resource 6. distributor 005 party who distributes the resource 7. originator 006 party who created the resource 8. pointOfContact 007 party who can be contacted for acquiring knowledge about or acquisition

of the resource 9. principalInvestigator 008 key party responsible for gathering information and conducting research 10. processor 009 party who has processed the data in a manner such that the resource has

been modified 11. publisher 010 party who published the resource 12. author 011 party who authored the resource

B.5.6 DQ_EvaluationMethodTypeCode <<CodeList>>

Name Domain code Definition 1. DQ_EvaluationMeth

odTypeCode EvalMethTypeCd type of method for evaluating an identified data quality measure

2. directInternal 001 method of evaluating the quality of a dataset based on inspection of items within the dataset, where all data required is internal to the dataset being evaluated

3. directExternal 002 method of evaluating the quality of a dataset based on inspection of items within the dataset, where reference data external to the dataset being evaluated is required

4. indirect 003 method of evaluating the quality of a dataset based on external knowledge

B.5.7 DS_AssociationTypeCode <<CodeList>>

Name Domain code Definition 1. DS_AssociationTyp

eCode AscTypeCd justification for the correlation of two datasets

2. crossReference 001 reference from one dataset to another 3. largerWorkCitation 002 reference to a master dataset of which this one is a part 4. partOfSeamlessDat

abase 003 part of same structured set of data held in a computer

5. source 004 mapping and charting information from which the dataset content originates

6. stereoMate 005 part of a set of imagery that when used together, provides three dimensional images

B.5.8 DS_InitiativeTypeCode <<CodeList>>

Name Domain code Definition 1. DS_InitiativeTypeCo

de InitTypCd type of aggregation activity in which datasets are related

2. campaign 001 series of organized planned actions 3. collection 002 accumulation of datasets assembled for a specific purpose 4. exercise 003 specific performance of a function or group of functions 5. experiment 004 process designed to find if something is effective or valid 6. investigation 005 search or systematic inquiry 7. mission 006 specific operation of a data collection system 8. sensor 007 device or piece of equipment which detects or records 9. operation 008 action that is part of a series of actions

5

Name Domain code Definition 10. platform 009 vehicle or other support base that holds a sensor 11. process 010 method of doing something involving a number of steps 12. program 011 specific planned activity 13. project 012 organized undertaking, research, or development 14. study 013 examination or investigation 15. task 014 piece of work 16. trial 015 process of testing to discover or demonstrate something

B.5.9 MD_CellGeometryCode <<CodeList>>

Name Domain code Definition 1. MD_CellGeometryC

ode CellGeoCd code indicating whether grid data is point or area

2. point 001 each cell represents a point 3. area 002 each cell represents an area

B.5.10 MD_CharacterSetCode <<CodeList>>

Name Domain code Definition 1. MD_CharacterSetC

ode CharSetCd name of the character coding standard used for the resource

2. ucs2 001 16bit fixed size Universal Character Set, based on ISO/IEC 10646 3. ucs4 002 32bit fixed size Universal Character Set, based on ISO/IEC 10646 4. utf7 003 7bit variable size UCS Transfer Format, based on ISO/IEC 10646 5. utf8 004 8bit variable size UCS Transfer Format, based on ISO/IEC 10646 6. utf16 005 16bit variable size UCS Transfer Format, based on ISO/IEC 10646 7. 8859part1 006 ISO/IEC 88591, Information technology – 8bit singlebyte coded graphic

character sets – Part 1: Latin alphabet No. 1 8. 8859part2 007 ISO/IEC 88592, Information technology – 8bit singlebyte coded graphic



character sets – Part 4: Latin alphabet No. 4 11. 8859part5 010 ISO/IEC 885951, Information technology – 8bit singlebyte coded

graphic character sets – Part 5: Latin/Cyrillic alphabet 12. 8859part6 011 ISO/IEC 88596, Information technology – 8bit singlebyte coded graphic

character sets – Part 6: Latin/Arabic alphabet 13. 8859part7 012 ISO/IEC 88597, Information technology – 8bit singlebyte coded graphic

character sets – Part 7: Latin/Greek alphabet 14. 8859part8 013 ISO/IEC 88598, Information technology – 8bit singlebyte coded graphic

character sets – Part 8: Latin/Hebrew alphabet 15. 8859part9 014 ISO/IEC88599, Information technology – 8bit singlebyte coded graphic

character sets – Part 9: Latin alphabet No. 5 16. 8859part10 015 ISO/IEC 885910, Information technology – 8bit singlebyte coded

graphic character sets – Part 10: Latin alphabet No. 6 17. 8859part11 016 ISO/IEC 885911, Information technology – 8bit singlebyte coded

graphic character sets – Part 11: Latin/Thai alphabet 18. (reserved for future

use) 017 a future ISO/IEC 8bit singlebyte coded graphic character set (e.g.

possibly ISO/IEC 885912 19. 8859part13 018 ISO/IEC 885913, Information technology – 8bit singlebyte coded


graphic character sets – Part 14: Latin alphabet No. 8 (Celtic) 21. 8859part15 020 ISO/IEC 885915, Information technology – 8bit singlebyte coded


graphic character sets – Part 16: Latin alphabet No. 10 23. jis 022 japanese code set used for electronic transmission 24. shiftJIS 023 japanese code set used on MSDOS based machines 25. eucJP 024 japanese code set used on UNIX based machines 26. usAscii 025 united states ASCII code set (ISO 646 US)

6

Name Domain code Definition 27. ebcdic 026 ibm mainframe code set 28. eucKR 027 korean code set 29. big5 028 traditional Chinese code set used in Taiwan, Hong Kong of China and

other areas 30. GB2312 029 simplified Chinese code set

B.5.11 MD_ClassificationCode <<CodeList>>

Name Domain code Definition 1. MD_ClassificationC

ode ClassificationCd name of the handling restrictions on the dataset

2. unclassified 001 available for general disclosure 3. restricted 002 not for general disclosure 4. confidential 003 available for someone who can be entrusted with information 5. secret 004 kept or meant to be kept private, unknown, or hidden from all but a select

group of people 6. topSecret 005 of the highest secrecy

B.5.12 MD_CoverageContentTypeCode <<CodeList>>

Name Domain code Definition 1. MD_CoverageConte

ntTypeCode ContentTypCd specific type of information represented in the cell

2. image 001 meaningful numerical representation of a physical parameter that is not the actual value of the physical parameter

3. thematicClassificatio n

002 code value with no quantitative meaning, used to represent a physical quantity

4. physicalMeasureme nt

003 value in physical units of the quantity being measured

B.5.13 MD_DatatypeCode <<CodeList>>

Name Domain code Definition 1. MD_DatatypeCode DatatypeCd datatype of element or entity

2. class 001 descriptor of a set of objects that share the same attributes, operations, methods, relationships, and behavior

3. codelist 002 flexible enumeration useful for expressing a long list of values, can be extended

4. enumeration 003 data type whose instances form a list of named literal values, not extendable

5. codelistElement 004 permissible value for a codelist or enumeration 6. abstractClass 005 class that cannot be directly instantiated 7. aggregateClass 006 class that is composed of classes it is connected to by an aggregate

relationship 8. specifiedClass 007 subclass that may be substituted for its superclass 9. datatypeClass 008 class with few or no operations whose primary purpose is to hold the

abstract state of another class for transmittal, storage, encoding or persistent storage

10. interfaceClass 009 named set of operations that characterize the behavior of an element 11. unionClass 010 class describing a selection of one of the specified types 12. metaClass 011 class whose instances are classes 13. typeClass 012 class used for specification of a domain of instances (objects), together

with the operations applicable to the objects. A type may have attributes and associations

14. characterString 013 free text field 15. integer 014 numerical field 16. association 015 semantic relationship between two classes that involves connections

among their instances

7

B.5.14 MD_DimensionNameTypeCode <<CodeList>>

Name Domain code Definition 1. MD_DimensionNam

eTypeCode DimNameTypCd name of the dimension

2. row 001 ordinate (y) axis 3. column 002 abscissa (x) axis 4. vertical 003 vertical (z) axis 5. track 004 along the direction of motion of the scan point 6. crossTrack 005 perpendicular to the direction of motion of the scan point 7. line 006 scan line of a sensor 8. sample 007 element along a scan line 9. time 008 duration

B.5.15 MD_GeometricObjectTypeCode <<CodeList>>

Name Domain code Definition 1. MD_GeometricObje

ctTypeCode GeoObjTypCd name of point or vector objects used to locate zero, one, two, or three

dimensional spatial locations in the dataset 2. complex 001 set of geometric primitives such that their boundaries can be represented

as a union of other primitives 3. composite 002 connected set of curves, solids or surfaces 4. curve 003 bounded, 1dimensional geometric primitive, representing the continuous

image of a line 5. point 004 zerodimensional geometric primitive, representing a position but not

having an extent 6. solid 005 bounded, connected 3dimensional geometric primitive, representing the

continuous image of a region of space 7. surface 006 bounded, connected 2dimensional geometric primitive, representing the

continuous image of a region of a plane

B.5.16 MD_ImagingConditionCode <<CodeList>>

Name Domain code Definition 1. MD_ImagingConditi

onCode ImgCondCd code which indicates conditions which may affect the image

2. blurredImage 001 portion of the image is blurred 3. cloud 002 portion of the image is partially obscured by cloud cover 4. degradingObliquity 003 acute angle between the plane of the ecliptic (the plane of the Earth’s

orbit) and the plane of the celestial equator 5. fog 004 portion of the image is partially obscured by fog 6. heavySmokeOrDust 005 portion of the image is partially obscured by heavy smoke or dust 7. night 006 image was taken at night 8. rain 007 image was taken during rainfall 9. semiDarkness 008 image was taken during semidark conditions—twilight conditions 10. shadow 009 portion of the image is obscured by shadow 11. snow 010 portion of the image is obscured by snow 12. terrainMasking 011 the absence of collection data of a given point or area caused by the

relative location of topographic features which obstruct the collection path between the collector(s) and the subject(s) of interest

B.5.17 MD_KeywordTypeCode <<CodeList>>

Name Domain code Definition 1. MD_KeywordTypeC

ode KeyTypCd methods used to group similar keywords

2. discipline 001 keyword identifies a branch of instruction or specialized learning 3. place 002 keyword identifies a location 4. stratum 003 keyword identifies the layer(s) of any deposited substance

8

Name Domain code Definition 5. temporal 004 keyword identifies a time period related to the dataset 6. theme 005 keyword identifies a particular subject or topic

B.5.18 MD_MaintenanceFrequencyCode <<CodeList>>

Name Domain code Definition 1. MD_MaintenanceFr

equencyCode MaintFreqCd frequency with which modifications and deletions are made to the data

after it is first produced 2. continual 001 data is repeatedly and frequently updated 3. daily 002 data is updated each day 4. weekly 003 data is updated on a weekly basis 5. fortnightly 004 data is updated every two weeks 6. monthly 005 data is updated each month 7. quarterly 006 data is updated every three months 8. biannually 007 data is updated twice each year 9. annually 008 data is updated every year 10. asNeeded 009 data is updated as deemed necessary 11. irregular 010 data is updated in intervals that are uneven in duration 12. notPlanned 011 there are no plans to update the data 13. unknown 012 frequency of maintenance for the data is not known Additional entries 14. hourly 013 data is updated hourly 15. 3hourly 014 data is updated every 3 hours 16. 6hourly 015 data is updated every 6 hours 17. 12hourly 016 data is updated every 12 hours

B.5.19 MD_MediumFormatCode <<CodeList>>

Name Domain code Definition 1. MD_MediumFormat

Code MedFormCd method used to write to the medium

2. cpio 001 CoPy In / Out (UNIX file format and command) 3. tar 002 Tape ARchive 4. highSierra 003 high sierra file system 5. iso9660 004 information processing – volume and file structure of CDROM 6. iso9660RockRidge 005 rock ridge interchange protocol (UNIX) 7. iso9660AppleHFS 006 hierarchical file system (Macintosh)

B.5.20 MD_MediumNameCode <<CodeList>>

Name Domain code Definition 1. MD_MediumNameC

ode MedNameCd name of the medium

2. cdRom 001 readonly optical disk 3. dvd 002 digital versatile disk 4. dvdRom 003 digital versatile disk, read only 5. 3halfInchFloppy 004 3.5 inch magnetic disk 6. 5quarterInchFloppy 005 5.25 inch magnetic disk 7. 7trackTape 006 7 track magnetic tape 8. 9trackTape 007 9 track magnetic tape 9. 3480Cartridge 008 3480 cartridge tape drive 10. 3490Cartridge 009 3490 cartridge tape drive 11. 3580Cartridge 010 3580 cartridge tape drive 12. 4mmCartridgeTape 011 4 millimetre magnetic tape 13. 8mmCartridgeTape 012 8 millimetre magnetic tape 14. 1quarterInchCartridg

eTape 013 0.25 inch magnetic tape

15. digitalLinearTape 014 half inch cartridge streaming tape drive 16. onLine 015 direct computer linkage

9

Name Domain code Definition 17. satellite 016 linkage through a satellite communication system 18. telephoneLink 017 communication through a telephone network 19. hardcopy 018 pamphlet or leaflet giving descriptive information

B.5.21 MD_ObligationCode <<Enumeration>>

Name Domain code Definition 1. MD_ObligationCode ObCd obligation of the element or entity 2. mandatory 001 element is always required 3. optional 002 element is not required 4. conditional 003 element is required when a specific condition is met

B.5.22 MD_PixelOrientationCode <<Enumeration>>

Name Domain code Definition 1. MD_PixelOrientation

Code PixOrientCd point in a pixel corresponding to the Earth location of the pixel

2. center 001 point halfway between the lower left and the upper right of the pixel 3. lowerLeft 002 the corner in the pixel closest to the origin of the SRS; if two are at the

same distance from the origin, the one with the smallest xvalue 4. lowerRight 003 next corner counterclockwise from the lower left 5. upperRight 004 next corner counterclockwise from the lower right 6. upperLeft 005 next corner counterclockwise from the upper right

B.5.23 MD_ProgressCode <<CodeList>>

Name Domain code Definition 1. MD_ProgressCode ProgCd status of the dataset or progress of a review 2. completed 001 production of the data has been completed 3. historicalArchive 002 data has been stored in an offline storage facility 4. obsolete 003 data is no longer relevant 5. onGoing 004 data is continually being updated 6. planned 005 fixed date has been established upon or by which the data will be created

or updated 7. required 006 data needs to be generated or updated 8. underDevelopment 007 data is currently in the process of being created

B.5.24 MD_RestrictionCode <<CodeList>>

Name Domain code Definition 1. MD_RestrictionCod

e RestrictCd limitation(s)placed upon the access or use of the data

2. copyright 001 exclusive right to the publication, production, or sale of the rights to a literary, dramatic, musical, or artistic work, or to the use of a commercial print or label, granted by law for a specified period of time to an author, composer, artist, distributor

3. patent 002 government has granted exclusive right to make, sell, use or license an invention or discovery

4. patentPending 003 produced or sold information awaiting a patent 5. trademark 004 a name, symbol, or other device identifying a product, officially registered

and legally restricted to the use of the owner or manufacturer 6. license 005 formal permission to do something 7. intellectualProperty

Rights 006 rights to financial benefit from and control of distribution of nontangible

property that is a result of creativity 8. restricted 007 withheld from general circulation or disclosure 9. otherRestrictions 008 limitation not listed

10

B.5.25 MD_ScopeCode <<CodeList>>

Name Domain code Definition 1. MD_ScopeCode ScopeCd class of information to which the referencing entity applies 2. attribute 001 information applies to the attribute class 3. attributeType 002 information applies to the characteristic of a feature 4. collectionHardware 003 information applies to the collection hardware class 5. collectionSession 004 information applies to the collection session 6. dataset 005 information applies to the dataset 7. series 006 information applies to the series

Note: "series" applies to any DS_Aggregate 8. nonGeographicData

set 007 information applies to nongeographic data

9. dimensionGroup 008 information applies to a dimension group 10. feature 009 information applies to a feature 11. featureType 010 information applies to a feature type 12. propertyType 011 information applies to a property type 13. fieldSession 012 information applies to a field session 14. software 013 information applies to a computer program or routine 15. service 014 information applies to a capability which a service provider entity makes

available to a service user entity through a set of interfaces that define a behaviour, such as a use case

16. model 015 information applies to a copy or limitation of an existing or hypothetical object

17. tile 016 information applies to a tile, a spatial subset of geographic data

B.5.26 MD_SpatialRepresentationTypeCode <<CodeList>>

Name Domain code Definition 1. MD_SpatialReprese

ntationTypeCode SpatRepTypCd method used to represent geographic information in the dataset

2. vector 001 vector data is used to represent geographic data 3. grid 002 grid data is used to represent geographic data 4. textTable 003 textual or tabular data is used to represent geographic data 5. tin 004 triangulated irregular network 6. stereoModel 005 threedimensional view formed by the intersecting homologous rays of an

overlapping pair of images 7. video 006 scene from a video recording Additional entries 8. bitmap 007 a spatially mapped array of bits 9. irregularPoints 008 Irregularlyspaced points, such as meteorological stations

B.5.27 MD_TopicCategoryCode <<Enumeration>>

Name Domain code Definition 1. MD_TopicCategory

Code TopicCatCd highlevel geographic data thematic classification to assist in the grouping

and search of available geographic data sets. Can be used to group keywords as well. Listed examples are not exhaustive. NOTE It is understood there are overlaps between general categories and the user is encouraged to select the one most appropriate.

2. farming 001 rearing of animals and/or cultivation of plants Examples: agriculture, irrigation, aquaculture, plantations, herding, pests and diseases affecting crops and livestock

3. biota 002 flora and/or fauna in natural environment Examples: wildlife, vegetation, biological sciences, ecology, wilderness, sealife, wetlands, habitat

4. boundaries 003 legal land descriptions Examples: political and administrative boundaries

11

Name Domain code Definition 5. climatologyMeteorol

ogyAtmosphere 004 processes and phenomena of the atmosphere

Examples: cloud cover, weather, climate, atmospheric conditions, climate change, precipitation

6. economy 005 economic activities, conditions and employment Examples: production, labour, revenue, commerce, industry, tourism and ecotourism, forestry, fisheries, commercial or subsistence hunting, exploration and exploitation of resources such as minerals, oil and gas

7. elevation 006 height above or below sea level Examples: altitude, bathymetry, digital elevation models, slope, derived products

8. environment 007 environmental resources, protection and conservation Examples: environmental pollution, waste storage and treatment, environmental impact assessment, monitoring environmental risk, nature reserves, landscape

9. geoscientificInformat ion

008 information pertaining to earth sciences Examples: geophysical features and processes, geology, minerals, sciences dealing with the composition, structure and origin of the earth’s rocks, risks of earthquakes, volcanic activity, landslides, gravity information, soils, permafrost, hydrogeology, erosion

10. health 009 health, health services, human ecology, and safety Examples: disease and illness, factors affecting health, hygiene, substance abuse, mental and physical health, health services

11. imageryBaseMapsE arthCover

010 base maps Examples: land cover, topographic maps, imagery, unclassified images, annotations

12. intelligenceMilitary 011 military bases, structures, activities Examples: barracks, training grounds, military transportation, information collection

13. inlandWaters 012 inland water features, drainage systems and their characteristics Examples: rivers and glaciers, salt lakes, water utilization plans, dams, currents, floods, water quality, hydrographic charts

14. location 013 positional information and services Examples: addresses, geodetic networks, control points, postal zones and services, place names

15. oceans 014 features and characteristics of salt water bodies (excluding inland waters) Examples: tides, tidal waves, coastal information, reefs

16. planningCadastre 015 information used for appropriate actions for future use of the land Examples: land use maps, zoning maps, cadastral surveys, land ownership

17. society 016 characteristics of society and cultures Examples: settlements, anthropology, archaeology, education, traditional beliefs, manners and customs, demographic data, recreational areas and activities, social impact assessments, crime and justice, census information

18. structure 017 manmade construction Examples: buildings, museums, churches, factories, housing, monuments, shops, towers

19. transportation 018 means and aids for conveying persons and/or goods Examples: roads, airports/airstrips, shipping routes, tunnels, nautical charts, vehicle or vessel location, aeronautical charts, railways

20. utilit iesCommunicati on

019 energy, water and waste systems and communications infrastructure and services Examples: hydroelectricity, geothermal, solar and nuclear sources of energy, water purification and distribution, sewage collection and disposal, electricity and gas distribution, data communication, telecommunication, radio, communication networks

B.5.28 MD_TopologyLevelCode <<CodeList>>

Name Domain code Definition 1. MD_TopologyLevel

Code TopoLevCd degree of complexity of the spatial relationships

2. geometryOnly 001 geometry objects without any additional structure which describes topology

12

Name Domain code Definition 3. topology1D 002 1dimensional topological complex – commonly called “chainnode”

topology 4. planarGraph 003 1dimensional topological complex that is planar. (A planar graph is a

graph that can be drawn in a plane in such a way that no two edges intersect except at a vertex.)

5. fullPlanarGraph 004 2dimensional topological complex that is planar. (A 2dimensional topological complex is commonly called “full topology” in a cartographic 2D environment.)

6. surfaceGraph 005 1dimensional topological complex that is isomorphic to a subset of a surface. (A geometric complex is isomorphic to a topological complex if their elements are in a onetoone, dimensionaland boundrypreserving correspondence to one another.)

7. fullSurfaceGraph 006 2dimensional topological complex that is isomorphic to a subset of a surface

8. topology3D 007 3dimensional topological complex. (A topological complex is a collection of topological primitives that are closed under the boundary operations.)

9. fullTopology3D 008 complete coverage of a 3D Euclidean coordinate space 10. abstract 009 topological complex without any specified geometric realisation

WMO_CommunityTopicCategoryCode <<CodeList>>

Name Domain code Definition 1. WMO_TopicCategor

yCode CommunityTopic

CatCd List of categories in the meteorological community for classification to assist in the grouping and search of meteorological data sets. IPETMIIII recommended that at least one entry of this list should be used as keyword.

2. weatherObservatio ns

001 weather observations

3. weatherForecasts 002 weather forecasts 4. meteorology 003 meteorology 5. hydrology 004 hydrology 6. climatology 005 climatology 7. landMeteorologyCl

imate 006 land meteorology climate

8. synopticMeteorolo gy

007 synoptic meteorology

9. marineMeteorolog y

008 marine meteorology

10. agriculturalMeteor ology

009 agricultural meteorology

11. aerology 010 aerology 12. marineAerology 011 marine aerology 13. oceanography 012 oceanography 14. landHydrology 013 land hydrology 15. rocketSounding 014 rocket sounding 16. pollution 015 pollution 17. waterPollution 016 water pollution 18. landWaterPollution 017 land water pollution 19. seaPollution 018 sea pollution 20. landPollution 019 land pollution 21. airPollution 020 air pollution 22. glaciology 021 glaciology 23. actinometry 022 actinometry 24. satelliteObservatio

n 023 satellite observation

25. airplaneObservatio n

024 airplane observation

26. observationPlatfor m

025 observation platform

WM

Annex

O Core

x E – ISO

e Metad

O 19115 C

data Pr

Corrigend

rofile v

dum 1 Ta

version

able of c

1.2

changes

ISO 19115:2003 Cor. 1 Geographic Information –

Metadata – Technical Corrigendum 1

Annex A (informative) Table of changes

Copyright

Since this information reproduces parts of the ISO 191xxx series of standards in the WMO

profile, Copyright remains with ISO.

ISO 19115:2003/Cor. 1:2006

© ISO 2006 – All rights reserved 31

Annex A (informative)

Table of changes

Clause No./ Subclause No./

Annex

Paragraph/ Figure/Table/

Note Changes made

5.5 Lines CC, CV, FC, FE, FT, GR, PF, PS, SI, TP, TS are removed.

6.2 2nd and 4th sentences

The wording in the 2nd and 4th sentences has been clarified.

6.2 Figure 3 The association between DS_Aggregation and DS_DataSet is dual, and the arrowhead is removed.

DS_Series is defined as an abstract stereotype.

6.3.2.2 Last paragraph MD_DateIdentification is corrected to MD_DataIdentification.

6.3.2.7 Overlap with ISO 19111. The first sentence is slightly changed and the rest of the paragraph removed.

A.2.1 Figure A.1 Added attribute “locale(0..*): PT_Locale” to Class MD_Metadata.

Added to the constraint of MD_Metadata: “parentIdentifier: documented if the hierarchy of a higher level exists”.

A.2.2 Figure A.2 Corrected misspelling of attribute "discipline" in MD_KeywordTypeCode.

Changed "MD_IntiativeTypeCode" to "DS_IntiativeTypeCode".

Removed stereotype <<DataType>> from MD_AggregateInformation.

Clarified last wording in last sentence of the condition statement.

Changed "MD_ServiceIdentification" to "SV_ServiceIdentification" and added (from Service Metadata).

A.2.4.1 Figure A.4 Corrected spelling of Class name "LI_Lineage".

Corrected spelling of role name "+lineage".

Corrected spelling of "lineage" in constraint box.

Changed class "DQ_Result" to italic.

A.2.4.2 Figure A.5 Corrected spelling of role name "+lineage".

Corrected spelling of "scope" in the constraint of LI_Lineage to "DQ_DataQuality.scope.level"

Corrected spelling of "sourceExtent" in the constraint of LI_Source.

A.2.4.3 Figure A.6 Changed "DQ_Completeness", DQ_LogicalConsistency", "DQ_PositionalAccuracy", "DQ_ThematicAccuracy" and "DQ_TemporalAccuracy" to italic.

A.2.5 Figure A.7 Added class MD_Identification and role resourceMaintenance.

Added note box to MD_ScopeDescription.

A.2.6 Figure A.8 Corrected spelling of attribute "checkPointAvailability" in MD_Georectified.

Changed "MD_DimensionTypeCode" to "MD_DimensionNameTypeCode".

ISO 19115:2003/Cor. 1:2006

32 © ISO 2006 – All rights reserved


Annex


Note Changes made

A.2.7 Figure A.9 New Figure according to ISO 19111 added. The following classes and related associations and note boxes are deleted: “MD_CRS”, “MD_EllipsoidParameters”, “MD_ProjectionParameters”, “MD_ObliqueLineAzimuth”, “MD_ObliqueLinePoint”.

A.2.8 Figure A.10 Changed "MD_ContentInformation" to italic.

Corrected spelling of attribute "includedWithDataset" in MD_FeatureCatalogue_Description.

Corrected spelling of attribute "semiDarkness" in MD_ImageConditionCode.

Corrected spelling of attributes "illuminationElevationAngle" and "illuminationAzimuthAngle" in MD_ImageDescription.

A.2.10 Figure A.12 Added class MD_Identification and role resourceFormat.

Corrected role name "+formatDistributor".

Corrected attribute in MD_Medium from "mediumName" to "mediumNote".

A.2.11 Figure A.13 Corrected spelling of role name "metadataExtensionInfo".

A.3.1 Figure A.15 Changed attributes of EX_ GeographicBoundingBox" from datatype "angle" to "decimal".

Deleted attribute "unitOfMeasure" from EX_VeritcalExtent".

Changed role name "verticalDatum" to "verticalCRS"

Changed class "SC_VerticalDatum" to "SC_CRS".

A.3.2 Figure A.16 Corrected spelling of attribute "administrativeArea" in CI_Address.

Corrected class name in attribute "address" in CI_Contact to "CI_Address".

B.2.1 Row 5 Changed Obligation/Condition in row 5 from " C/ hierarchyLevel is not equal to “dataset”?" to " C/ If there is an upper hierarchy level".

B.2.1 Row 11 Changed Definition from "version (profile) of the metadata standard used" to "version of the metadata standard (version of the profile) used".

B.2.1 Row 11.2 Added new row 11.2 "locate".

B.2.2.1 Row 47 Added correct class name: "SV_ServiceIdentification".

B.2.5.2 Row 150 Clarified wording of Definition from "attributes to which the information applies" to "instances of attribute types to which the information applies".

B.2.5.2 Row 151 Clarified wording of Definition from "features to which the information applies" to "instances of features types to which the information applies".

B.2.6.1 Row 165 Added sentence at the end of Definition "The first corner point corresponds to the origin of the grid." to clarify the definition.

B.2.7.1 Table The table has been replaced with changes described for rows 187 and 189-194 below.

B.2.7.1 Row 187 Obligation/Condition changed.

B.2.7.1 Rows 189-194 Content of rows deleted due to overlap with ISO 19111.

B.2.7.2 Rows 201-204 The table has been replaced. Contents of rows deleted due to overlap with ISO 19111.

B.2.7.3 Row 205 Added <<DataType>> to name of class MD_Identifier.

B.2.7.4 Rows 209-211 The table has been replaced. Content of rows deleted due to overlap with ISO 19111.

ISO 19115:2003/Cor. 1:2006

© ISO 2006 – All rights reserved 33


Annex


Note Changes made



B.2.8.1 Row 243 Clarified by changing Obligation/Condition from "0" to "Use obligation/condition from referencing object".

B.2.10.5 Row 295 Corrected Domain from ">0.0" to ">0".

B.3.1.2 Row 342 Corrected Domain from "GM_Object (B.4.6) -90 to 90 latitude -180 to 360 longitude" to "GM_Object (B.4.6)".

B.3.1.2 Row 344 Added missing Data type "Decimal" and removed "Angle" from Domain.

B.3.1.2 Row 345 Corrected Data type to "Decimal" and removed "Angle" from Domain.



B.3.1.4 Row 357 Content of row deleted due to overlap with ISO 19111.

B.3.1.4 Row 358 Role name changed from "verticalDatum" to verticalCRS".

Short name changed from "vertDatum" to "vertCRS".

Changed Definition from " provides information about the origin from which the maximum and minimum elevation values are measured" to "provides information about the vertical coordinate reference system to which the maximum and minimum elevation values are measured. The CRS identification includes unit of measure."

B.3.2.2 Row 385 Removed unnecessary restriction to ISO 3166-3 and changed Domain to "Free text".

B.4.9 Replaced start of sentence from "SC_VerticalDatum:" to "SC_CRS:".

B.5.10 Row 18 Corrected "8859 part 12" to "ISO/IEC 8859-12" in Definition.

B.5.25 Row 2 Changed "attribute class" to "attribute value" in Definition.

B.5.25 Row 7 Added note in Definition to clarify use of "series".

E.2 Figure E.1 Corrected spelling of "Maintenance information" in the class MD_MaintenanceInformation.

Added sub-class relationship from MD_Identification to MD_DataIdentification.

Changed MD_ContentInformation to italic.

Changed MD_SpatialRepresentation to italic.

F.4 III) Corrected spelling "Go to Stage 9".

F.10 Bullet list Changed the order of the last two bullets.

I.2 The order of the elements "dateType" and "date" has been changed throughout the example.

I.3 Figure I.1 Corrected spelling of attribute "place" in MD_Keywords (modified).

I.4 Identification Reference

Added "CI_Citation" in Domain.

1.4 Role name: theVouchers

Added "vouchers used" in Obligation/Condition.

ISO 19115:2003/Cor. 1:2006

34 © ISO 2006 – All rights reserved


Annex


Note Changes made

I.4 Vouchers Changed from "C/ vouchers used" to "Use obligation/condition from referencing object" in Obligation/Condition.

I.4 HierarchicalClass DataType changed from "Character String" to "Class"

Domain changed from "Free Text" to "Taxonomic Classification".

WMO Core Metadata Profile ii Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"

xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:dcterms="http://purl.org/dc/terms/"

xmlns:skos="http://www.w3.org/2004/02/skos/core#">

<skos:ConceptScheme rdf:about="http://wis.wmo.int">

<dc:title>WMO_DataFrequencyCode</dc:title>

<dc:description>WMO thesaurus for temporal values reflecting WMO time scales</dc:description>

<dc:creator>

<foaf:Organization>

<foaf:name>WMO</foaf:name>

</foaf:Organization>

</dc:creator>

<dc:uri>http://www.wmo.int/pages/prog/wis/2010/thesauri</dc:uri>

<dc:rights>http://www.wmo.int/pages/prog/www/WIS/metadata_en.html</dc:rights>

<dcterms:issued>2010-11-02</dcterms:issued>

<dcterms:modified>2010-11-02</dcterms:modified>

</skos:ConceptScheme>

<skos:Concept rdf:about="http://www.wmo.int/pages/prog/wis/2008/catalogues/draft_version_1-

1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_continuous">

<skos:prefLabel xml:lang="en">continuous</skos:prefLabel>

<skos:prefLabel xml:lang="fr">continuous</skos:prefLabel>

<skos:prefLabel xml:lang="es">continuous</skos:prefLabel>

<skos:prefLabel xml:lang="zh">连续</skos:prefLabel>

<skos:prefLabel xml:lang="ru">continuous</skos:prefLabel>

<skos:prefLabel xml:lang="ar">continuous</skos:prefLabel>

<skos:prefLabel xml:lang="de">kontinuierlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">連続的</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted continuously</skos:definition>

</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_1-minute">

<skos:prefLabel xml:lang="en">1-minute</skos:prefLabel>

<skos:prefLabel xml:lang="fr">1-minute</skos:prefLabel>

<skos:prefLabel xml:lang="es">1-minute</skos:prefLabel>

<skos:prefLabel xml:lang="zh">每分钟</skos:prefLabel>

<skos:prefLabel xml:lang="ru">1-minute</skos:prefLabel>

<skos:prefLabel xml:lang="ar">1-minute</skos:prefLabel>

<skos:prefLabel xml:lang="de">minütlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">毎分</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every minute</skos:definition>

</skos:Concept>






<skos:prefLabel xml:lang="zh">每5分钟</skos:prefLabel>


WMO Core Metadata Profile iii Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material


<skos:prefLabel xml:lang="de">5-minütlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">5分毎</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every 5 minutes</skos:definition>

</skos:Concept>









<skos:prefLabel xml:lang="de">10-minütlich</skos:prefLabel>



</skos:Concept>









<skos:prefLabel xml:lang="de">halbstündlich</skos:prefLabel>



</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_hourly">

<skos:prefLabel xml:lang="en">hourly</skos:prefLabel>

<skos:prefLabel xml:lang="fr">hourly</skos:prefLabel>

<skos:prefLabel xml:lang="es">hourly</skos:prefLabel>

<skos:prefLabel xml:lang="zh">每小时</skos:prefLabel>

<skos:prefLabel xml:lang="ru">hourly</skos:prefLabel>

<skos:prefLabel xml:lang="ar">hourly</skos:prefLabel>

<skos:prefLabel xml:lang="de">stündlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">毎時</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every hour</skos:definition>

</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_3-hourly">

<skos:prefLabel xml:lang="en">3-hourly</skos:prefLabel>

<skos:prefLabel xml:lang="fr">3-hourly</skos:prefLabel>

<skos:prefLabel xml:lang="es">3-hourly</skos:prefLabel>

<skos:prefLabel xml:lang="zh">每3小时</skos:prefLabel>

<skos:prefLabel xml:lang="ru">3-hourly</skos:prefLabel>

<skos:prefLabel xml:lang="ar">3-hourly</skos:prefLabel>

WMO Core Metadata Profile iv Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

<skos:prefLabel xml:lang="de">3-stündlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">3時間毎</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every 3 hours</skos:definition>

</skos:Concept>












</skos:Concept>












</skos:Concept>






<skos:prefLabel xml:lang="zh">每半天</skos:prefLabel>



<skos:prefLabel xml:lang="de">halbtäglich</skos:prefLabel>



</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_daily">

<skos:prefLabel xml:lang="en">daily</skos:prefLabel>

<skos:prefLabel xml:lang="fr">daily</skos:prefLabel>

<skos:prefLabel xml:lang="es">daily</skos:prefLabel>

<skos:prefLabel xml:lang="zh">每天</skos:prefLabel>

<skos:prefLabel xml:lang="ru">daily</skos:prefLabel>

<skos:prefLabel xml:lang="ar">daily</skos:prefLabel>

<skos:prefLabel xml:lang="de">täglich</skos:prefLabel>

WMO Core Metadata Profile v Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

<skos:prefLabel xml:lang="ja">毎日</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every day</skos:definition>

</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_weekly">

<skos:prefLabel xml:lang="en">weekly</skos:prefLabel>

<skos:prefLabel xml:lang="fr">weekly</skos:prefLabel>

<skos:prefLabel xml:lang="es">weekly</skos:prefLabel>

<skos:prefLabel xml:lang="zh">每周</skos:prefLabel>

<skos:prefLabel xml:lang="ru">weekly</skos:prefLabel>

<skos:prefLabel xml:lang="ar">weekly</skos:prefLabel>

<skos:prefLabel xml:lang="de">wöchentlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">毎週</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every week</skos:definition>

</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_irregularly">

<skos:prefLabel xml:lang="en">10-daily</skos:prefLabel>

<skos:prefLabel xml:lang="fr">10-daily</skos:prefLabel>

<skos:prefLabel xml:lang="es">10-daily</skos:prefLabel>

<skos:prefLabel xml:lang="zh">每10天</skos:prefLabel>

<skos:prefLabel xml:lang="ru">10-daily</skos:prefLabel>

<skos:prefLabel xml:lang="ar">10-daily</skos:prefLabel>

<skos:prefLabel xml:lang="de">10-täglich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">10日毎</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every 10 days</skos:definition>

</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_fortnightly">

<skos:prefLabel xml:lang="en">fortnightly</skos:prefLabel>

<skos:prefLabel xml:lang="fr">fortnightly</skos:prefLabel>

<skos:prefLabel xml:lang="es">fortnightly</skos:prefLabel>

<skos:prefLabel xml:lang="zh">每两个星期</skos:prefLabel>

<skos:prefLabel xml:lang="ru">fortnightly</skos:prefLabel>

<skos:prefLabel xml:lang="ar">fortnightly</skos:prefLabel>

<skos:prefLabel xml:lang="de">zweiwöchentlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">2週間毎</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every 2 weeks</skos:definition>

</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_monthly">

<skos:prefLabel xml:lang="en">monthly</skos:prefLabel>

<skos:prefLabel xml:lang="fr">monthly</skos:prefLabel>

<skos:prefLabel xml:lang="es">monthly</skos:prefLabel>

<skos:prefLabel xml:lang="zh">每月</skos:prefLabel>

<skos:prefLabel xml:lang="ru">monthly</skos:prefLabel>

<skos:prefLabel xml:lang="ar">monthly</skos:prefLabel>

<skos:prefLabel xml:lang="de">monatlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">毎月</skos:prefLabel>

WMO Core Metadata Profile vi Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

<skos:definition>Data is observed, measured, or forecasted every month</skos:definition>

</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_quartely">

<skos:prefLabel xml:lang="en">quartely</skos:prefLabel>

<skos:prefLabel xml:lang="fr">quartely</skos:prefLabel>

<skos:prefLabel xml:lang="es">quartely</skos:prefLabel>

<skos:prefLabel xml:lang="zh">每季度</skos:prefLabel>

<skos:prefLabel xml:lang="ru">quartely</skos:prefLabel>

<skos:prefLabel xml:lang="ar">quartely</skos:prefLabel>

<skos:prefLabel xml:lang="de">vierteljährlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">毎四半期</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every 3 months</skos:definition>

</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_biannually">

<skos:prefLabel xml:lang="en">biannually</skos:prefLabel>

<skos:prefLabel xml:lang="fr">biannually</skos:prefLabel>

<skos:prefLabel xml:lang="es">biannually</skos:prefLabel>

<skos:prefLabel xml:lang="zh">两次一年</skos:prefLabel>

<skos:prefLabel xml:lang="ru">biannually</skos:prefLabel>

<skos:prefLabel xml:lang="ar">biannually</skos:prefLabel>

<skos:prefLabel xml:lang="de">halbjährlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">6か月毎</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every 6 months</skos:definition>

</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_annually">

<skos:prefLabel xml:lang="en">annually</skos:prefLabel>

<skos:prefLabel xml:lang="fr">annually</skos:prefLabel>

<skos:prefLabel xml:lang="es">annually</skos:prefLabel>

<skos:prefLabel xml:lang="zh">每年</skos:prefLabel>

<skos:prefLabel xml:lang="ru">annually</skos:prefLabel>

<skos:prefLabel xml:lang="ar">annually</skos:prefLabel>

<skos:prefLabel xml:lang="de">jährlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">毎年</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every year</skos:definition>

</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_decadally">

<skos:prefLabel xml:lang="en">decadally</skos:prefLabel>

<skos:prefLabel xml:lang="fr">decadally</skos:prefLabel>

<skos:prefLabel xml:lang="es">decadally</skos:prefLabel>

<skos:prefLabel xml:lang="zh">每10年</skos:prefLabel>

<skos:prefLabel xml:lang="ru">decadally</skos:prefLabel>

<skos:prefLabel xml:lang="ar">decadally</skos:prefLabel>

<skos:prefLabel xml:lang="de">zehnjährlich</skos:prefLabel>

<skos:prefLabel xml:lang="ja">10年毎</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted every decade</skos:definition>

WMO Core Metadata Profile vii Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

</skos:Concept>


1/WMO_Codelists_ver1_1.xml#WMO_DataFrequencyCode_irregularly">

<skos:prefLabel xml:lang="en">irregularly</skos:prefLabel>

<skos:prefLabel xml:lang="fr">irregularly</skos:prefLabel>

<skos:prefLabel xml:lang="es">irregularly</skos:prefLabel>

<skos:prefLabel xml:lang="zh">不时</skos:prefLabel>

<skos:prefLabel xml:lang="ru">irregularly</skos:prefLabel>

<skos:prefLabel xml:lang="ar">irregularly</skos:prefLabel>

<skos:prefLabel xml:lang="de">irregulär</skos:prefLabel>

<skos:prefLabel xml:lang="ja">不定期</skos:prefLabel>

<skos:definition>Data is observed, measured, or forecasted irregularly</skos:definition>

</skos:Concept>

</rdf:RDF>

WMO Core Metadata Profile ii Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

<?xml version="1.0" encoding="UTF-8"?>



<gmx:CT_CodelistCatalogue

xmlns:gco="http://www.isotc211.org/2005/gco"

xmlns:gmd="http://www.isotc211.org/2005/gmd"

xmlns:xlink="http://www.w3.org/1999/xlink"

xmlns:gml="http://www.opengis.net/gml"

xmlns:gmx="http://www.isotc211.org/2005/gmx"

xmlns:gts="http://www.isotc211.org/2005/gts"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.isotc211.org/2005/gmi http://www.ngdc.noaa.gov/metadata/published/xsd/schema.xsd">

<gmx:name>

<gco:CharacterString>WMOCodelists</gco:CharacterString>

</gmx:name>

<gmx:scope>

<gco:CharacterString>Codelists for description of metadata datasets compliant with the WMO Core Metadata Profile

version 1.2 (derived from ISO/TC 211 19115:2003 and 19139)</gco:CharacterString>

</gmx:scope>

<gmx:fieldOfApplication>

<gco:CharacterString>WMO Core Metadata Profile</gco:CharacterString>

</gmx:fieldOfApplication>

<gmx:versionNumber>

<gco:CharacterString>0.1</gco:CharacterString>

</gmx:versionNumber>

<gmx:versionDate>

<gco:Date>2010-11-12</gco:Date>

</gmx:versionDate>

<gmx:language>

<gmd:LanguageCode


l#LanguageCode" codeListValue="eng">eng</gmd:LanguageCode>

</gmx:language>

<gmx:characterSet>



l#MD_CharacterSetCode" codeListValue="utf8">UTF 8</gmd:MD_CharacterSetCode>

</gmx:characterSet>









<gmx:codelistItem>

<gmx:CodeListDictionary gml:id="CI_DateTypeCode">

<gml:description>identification of when a given event occurred</gml:description>

<gml:identifier codeSpace="ISOTC211/19115">CI_DateTypeCode</gml:identifier>

<gmx:codeEntry>

WMO Core Metadata Profile iii Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

<gmx:CodeDefinition gml:id="CI_DateTypeCode_creation">

<gml:description>date identifies when the resource was brought into existence</gml:description>

<gml:identifier codeSpace="ISOTC211/19115">creation</gml:identifier>

</gmx:CodeDefinition>

</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="CI_DateTypeCode_publication">

<gml:description>date identifies when the resource was issued</gml:description>

<gml:identifier codeSpace="ISOTC211/19115">publication</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="CI_DateTypeCode_revision">

<gml:description>date identifies when the resource was examined or re-examined and imporved or

amended</gml:description>

<gml:identifier codeSpace="ISOTC211/19115">revision</gml:identifier>


</gmx:codeEntry>



<gmx:codeEntry>

<gmx:CodeDefinition gml:id="CI_DateTypeCode_reference">

<gml:description>date identifies when the resource was referenced or accessed</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">revision</gml:identifier>


</gmx:codeEntry>

</gmx:CodeListDictionary>

</gmx:codelistItem>

<gmx:codelistItem>

<gmx:CodeListDictionary gml:id="WMO_DataLicenseCode">

<gml:description>WMO Data License applied to the data resource – derived from WMO Resolution 25 and

Resolution 40 (http://www.wmo.int/pages/about/exchangingdata_en.html)</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">WMO_DataLicenseCode</gml:identifier>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_DataLicenseCode_essential">

<gml:description>WMO Essential Data: free and unrestricted international exchange of basic meteorological

data and products</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">essential</gml:identifier>

<gml:name>WMO Essential</gml:name>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_DataLicenseCode_additional">

<gml:description>WMO Additional Data: free and unrestricted access to data and products exchanged under

the auspices of WMO to the research and education communities for non-commercial activities</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">essential</gml:identifier>

<gml:name>WMO Essential</gml:name>


</gmx:codeEntry>


</gmx:codelistItem>

WMO Core Metadata Profile iv Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

<gmx:codelistItem>

<gmx:CodeListDictionary gml:id="WMO_GTSProductCategoryCode">

<gml:description>Product category used for prioritising messages on the WMO Global Telecommunications System

(GTS)</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">WMO_GTSProductCategoryCode</gml:identifier>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_GTSProductCategoryCode_1">

<gml:description>GTS Category 1 – highest priority products</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">1</gml:identifier>

<gml:name>GTS Category 1</gml:name>


</gmx:codeEntry>

<gmx:codeEntry>


<gml:description>GTS Category 2</gml:description>




</gmx:codeEntry>

<gmx:codeEntry>






</gmx:codeEntry>

<gmx:codeEntry>






</gmx:codeEntry>


</gmx:codelistItem>

<gmx:codelistItem>

<gmx:CodeListDictionary gml:id="WMO_CategoryCode">

<gml:description>Additional topic categories for WMO community</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">WMO_CategoryCode</gml:identifier>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_weatherObservations">

<gml:description>Weather Observations</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">weatherObservations</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_weatherForecasts">

<gml:description>Weather Forecasts</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">weatherForecasts</gml:identifier>


WMO Core Metadata Profile v Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_meteorology">

<gml:description>Meteorology</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">meteorology</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_hydrology">

<gml:description>Hydrology</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">hydrology</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_climatology">

<gml:description>Climatology</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">climatology</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_landMeteorologyClimate">

<gml:description>Land Meteorology Climate</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">landMeteorologyClimate</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_synopticMeteorology">

<gml:description>Synoptic Meteorology</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">synopticMeteorology</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_marineMeteorology">

<gml:description>Marine Meteorology</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">marineMeteorology</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_agriculturalMeteorology">

<gml:description>Agricultural Meteorology</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">agriculturalMeteorology</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_aerology">

<gml:description>Aerology</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">aerology</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

WMO Core Metadata Profile vi Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

<gmx:CodeDefinition gml:id="WMO_CategoryCode_marineAerology">

<gml:description>Marine Aerology</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">marineAerology</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_oceanography">

<gml:description>Oceanography</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">oceanography</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_landHydrology">

<gml:description>Land Hydrology</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">landHydrology</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_rocketSounding">

<gml:description>Rocket Sounding</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">rocketSounding</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_pollution">

<gml:description>Pollution</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">pollution</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_waterPollution">

<gml:description>Water Pollution</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">waterPollution</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_landWaterPollution">

<gml:description>Land Water Pollution</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">landWaterPollution</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_seaPollution">

<gml:description>Sea Pollution</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">seaPollution</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_landPollution">

<gml:description>Land Pollution</gml:description>

WMO Core Metadata Profile vii Guidelines on the use of Metadata for WIS © WMO 2010 – noting rights of source material

<gml:identifier codeSpace="WMO Core Metadata Profile">landPollution</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_airPollution">

<gml:description>Air Pollution</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">airPollution</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_glaciology">

<gml:description>Glaciology</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">glaciology</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_actinometry">

<gml:description>Actinometry</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">actinometry</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_satelliteObservation">

<gml:description>Satellite Observation</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">satelliteObservation</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_airplaneObservation">

<gml:description>Airplane Observation</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">airplaneObservation</gml:identifier>


</gmx:codeEntry>

<gmx:codeEntry>

<gmx:CodeDefinition gml:id="WMO_CategoryCode_observationPlatform">

<gml:description>Observation Platform</gml:description>

<gml:identifier codeSpace="WMO Core Metadata Profile">observationPlatform</gml:identifier>


</gmx:codeEntry>


</gmx:codelistItem>

</gmx:CT_CodelistCatalogue>

WMO Core Metadata Profile version 1 - WIS browsingwis.wmo.int/2010/metadata/version_1-2/WMO Core...

Documents

Transcript of WMO Core Metadata Profile version 1 - WIS browsingwis.wmo.int/2010/metadata/version_1-2/WMO Core...